Orgnanizational access and email being unique user key

[pbasov]

So when I read this: https://www.deploykf.org/guides/platform/deploykf-profiles/, what I understand is that even if I connect an external IdP that has some groups setup, I still need to know every email in that group.

I want to give demo access to our installation for the whole company, that has 500+ users. Is that literally not possible without dumping the full list of emails into deploykf_profiles_generator?

Seems a bit crazy to do that, sure I can generate a list like that, but still.

I'd be happy, for example, for users to share a single "company-employee" KF user entity. Then they would get access by having some other key defined in IdP like a group or GitHub org.

[thesuperzapper]

@pbasov this is an interesting use-case, but you are correct that right now deployKF needs to be told about who is in what group. This is because some resources (like secrets) need to be provisioned before the user logs in.

For the real world, this is usually fine because giving someone more than read access to deployKF does confer some significant trust (e.g. they can run arbitrary code in Notebooks or Pipelines). If you are doing a basic demo and having security/audit-trail is not a concern, you could make a few Static User/Password Combinations for each team while you are testing rather than generating profiles for each one.

NOTE: at a certain scale you might run into Kubernetes issues because so many resource would need to be generated, so if you end up doing a crazy scale deployment, I would be very interested to know if anything does not scale properly.

NOTE 2: Automatically syncing users from external systems (other than just via values) is something on the roadmap, but as it's not a blocker for most organizations, so it's not top priority right now.

---

Regarding your idea for a non-email field to be used as an identifier (specifically groups), I have also though about this, but it raises a lot of questions about which group should be used to determine the users identity/access. There would probably need to be some kind of priority order, and that might be different for each profile (e.g. you give group_1 access to team-1 profile, and group_2 acess to the team-2 profile, but the user might be a member of both).