Strong silo isolation

[mx-shift]

Recent conversations have been asking whether a user from silo A would have any reason to look at users or resources in silo B. While general sentiment is that cross-silo access to resources (instances, VPCs, etc) can be omitted for v1, users isn't quite so clear.

At a minimum, we need to handle the initial setup case. Assume a fresh rack where RSS has created an initial silo R that uses local authentication only and has a single user provisioned, user R_admin (_ notation for clarity and conciseness). User R_admin is granted CRUD permissions on silos themselves with the intent that this silo is primarily used for initial setup and recovery purposes. User R_admin creates a new silo, A, with an IdP configuration to allow login via SSO and JIT account provisioning. At this point silo A contains no user accounts as no logins via SSO have occurred. So how does user R_admin designate a user in silo A as a Silo Administrator?

One option is to have someone login to silo A via SSO which causes their account to be created as user A_user1. User R_admin can now see that account when the list the user accounts in silo A (note the cross-silo access here). R_admin can now assign the Silo Administrator role to A_user1. This has a few disadvantages:

• Users with Silo CRUD permissions are implicitly given access to at least list users and modify ACLs in all silos
• If R_admin != A_user1, the process need to be passed back and forth between them
• If A_user1 accidentally removes their Silo Admin role, only R_admin can recover it
• Every role assignment would need to be made individually after each user has logged in

Alternatively, Silo configuration could specify a SAML assertion key that contains group membership provided by the IdP as well as a mapping of group identifiers to role assignments that define "default" role assignments. For example, a SAML assertion might say user B_user1 is part of IdP groups B_IDP_DOMAIN_ADMINS and B_IDP_IT while silo B's configuration says B_IDP_DOMAIN_ADMINS grants Silo Administrator and B_IDP_ENGINEERING grants Collaborator. This can all be set up before any users log into silo B. When a user does login to silo B via SSO, Nexus would extract the groups from the SAML assertion, translate them to roles, and apply those roles to the user. Since this happens on each login, even if B_user1 removes their Silo Administrator role by accident, logging out and back in would restore it.

[davepacheco]

For further reference, this was discussed at some length in the second half hour of today's "operator api" meeting. I think proposals included:

• having privileges above the Silo (i.e., at fleet level) do not confer any privileges (even read privileges) on anything within the Silo -- only the ability to manipulate the config of the Silo (which might include IdP config, which might include which IdP groups get which roles within the Silo)
• I think there was a second thing?

[zephraph]

The second thing is somewhat articulated here: #1329 (comment)

The TL;DR is we don't have a clear definition of what is a global resource vs what is a silo scoped resource in the API. The separation is mildly muddled. This is just an ergonomic API thing, but I talked through the options in the comment above.

[david-crespo]

I don’t think there’s anything left here that we want to to. Reopen if that’s not true.

[davepacheco]

I think any remaining work is covered under #1681. (edit: wrong link the first time)