Read group permission for fleet users

[augustuswm]

When a silo is created we accept a SiloCreate struct that defines an optional admin_group_name:

omicron/nexus/types/src/external_api/params.rs

Lines 301 to 308 in ecb6214

	/// If set, this group will be created during Silo creation and granted the
	/// "Silo Admin" role. Identity providers can assert that users belong to
	/// this group and those users can log in and further initialize the Silo.
	///
	/// Note that if configuring a SAML based identity provider,
	/// group_attribute_name must be set for users to be considered part of a
	/// group. See `SamlIdentityProviderCreate` for more information.
	pub admin_group_name: Option<String>,

This group is created at silo creation time as described in the comment. We do not store this value though outside of the group instantiation. This makes it particularly difficult to debug silo IdP connections as groups are not visible to fleet viewers/admins. We've run in to this a few times internally on the preview rack as well as externally.

While we could store this value, it is really only useful for initial silo configuration, and not very useful in the long usage of the silo. Instead should we consider that silo groups be visible to users with fleet level permissions? We already allow for fleet permissions to list cross silo users, and view the opaque group ids via the policy endpoints. Is there a reason to prevent viewing the group display names?

[dwradcliffe]

While we're brainstorming, I think it would make more sense to move that param to the IDP setup step, since it doesn't make sense without IDP. Also it's more likely that someone is configuring the groups in IDP at that point rather than the initial silo create.

So really there are 2 parts here, the visibility of groups for fleet admins, and also the UX flow of setting up the initial group.

[davepacheco]

We can always revisit things, but just noting here that the lack of visibility into silo groups from outside the silo was an explicit (security) design goal. I'm not sure where we wrote this down but there are some related notes in #1340, #1681, and RFD 297.

This makes it particularly difficult to debug silo IdP connections as groups are not visible to fleet viewers/admins.

Can you say more about the types of problems we've run into? The obvious one we were worried about is a mismatch between the admin group name that the user configures here and the actual group name in the IdP. We're relying on people to get that right, and if they get it wrong, it just won't work and it won't be obvious why. We've discussed streamlined flows to make it harder to get this wrong. For example, during silo setup, after you configure the IdP, maybe we could have you (in another browser session?) log into the new Silo, and the first screen you get shows you the groups that we found, and you can pick which one you want to be the admin group. Or maybe we don't do anything special in that second session, but we create those groups like we always do, and then you can see those in your first session (the one creating the silo) and then you can pick one there. I imagine there are lots of ways to make this better but it depends on how things are going wrong.

[dwradcliffe]

I'm not sure I understand the concern with giving a fleet admin visibility into the IdP/group configuration of the other silos. The fleet admin is the role that is allowed to create the configuration, and also the only logical (and possible) choice for who can debug/fix any auth issues with a silo.

You mentioned the obvious problem which is what I ran into, but I can imagine that over time something could change on the SAML provider side and we need to confirm or change the IdP or group configuration.

There must be a way to view or edit the config for a silo if the IdP is broken and there's no way to login to the given silo. (This is also blending into #3125)

[davepacheco]

I'm not sure I understand the concern with giving a fleet admin visibility into the IdP/group configuration of the other silos. The fleet admin is the role that is allowed to create the configuration, and also the only logical (and possible) choice for who can debug/fix any auth issues with a silo.

Totally -- fleet administrators definitely need to be able to debug and fix problems with a silo's IdP configuration. At the very least, they need to be able to establish an IdP configuration that allows a silo administrator to log in and make any other changes that are needed. #3125 is important here so that DNS names, IP addresses, keys, and certificates can be changed (both by silo admins and also from outside the silo by a fleet administrator) for cases where an IdP is migrated or certificates get rotated, etc. But there are a couple of reasons it'd be nice if we can limit the privileges that are required to get a silo admin to be able to log in:

• When fleet admins can see and do things inside the silo, that's a sort of side door into the silo that makes it harder for people to audit who has access to the silo. A similar question comes up for the use case where a fleet administrator wants to help a silo administrator with something that the silo admin technically has the privileges to do but just wants help with. Our thinking on this has been that if you want to do that, you'd be better off creating a separate identity for the fleet administrator in the silo's IdP and use that. This is more transparent about who has access to what silos -- it allows security teams to tell just from the IdP who has access to a silo. We know this isn't a complete answer. It obviously doesn't work for repairing the IdP config. And RFD 309 describes a lot of cases where fleet admins probably want a holistic view of the system, but that's hard to do if you have lots of silos and you need to use separate identities to gather information from each one. But the nice thing about this approach is that it's much more transparent about what's going on. That's why we've gone down this path even though it results in treating silo setup a little specially.
• One of the intended use cases for silos is delegated administration where the fleet admin may not have access to the silo's IdP or anything inside the silo. In this situation, exposing the list of groups does leak information that they might not otherwise have access to (the group names themselves, but also the groups whose members have logged into the silo). Again, they need to be able to fix config, but if we can do that without exposing the list of groups, that'd be nice.

These are goals, not constraints, and it's okay if the answer is that we should just directly expose the list of silo groups to fleet admins anyway. But that's why I was asking the question, since in at least some of these cases, there seem to be alternatives that provide a better experience while also avoiding exposing that information.