Skip to content

Strong silo isolation #1340

@mx-shift

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions