want way to delegate Fleet access

[davepacheco]

Right now, I believe the user that gets created in the recovery Silo during rack setup gets the "fleet admin" role. That user should have the privilege to grant "fleet admin" to anybody else (including users/groups in other Silos), but they have no way of knowing the identity of a user or group in another Silo. (And it's not clear that they should. See #1340.)

However we do it, we want some way of having this user delegate "Fleet Admin" to users or groups in other Silos. That way operators don't need to use the recovery Silo (which bypasses their IdP) to manage the rack.

[davepacheco]

Idea 1: Expose users/groups across Silos.

If we create an API for suitably privileged users to list the users and groups in another Silo, then this can work just like any other part of IAM: you can update the fleet policy to add/remove role assignments for whatever user/group you want. This sounds appealing, but has two potentially big downsides:

1. It's conceptually confusing to expose users/groups across Silos. "bob" in silo1 is not the same as "bob" in silo2. So things that a client might otherwise think of as a primary key needs to be part of a tuple that includes the silo id.
2. It means that people at the fleet level can see into the users/groups inside the Silos. This has downsides mentioned in Strong silo isolation #1340.

Idea 2: Define fleet-level privileges for a Silo's initial admin group when creating the Silo

We could add a new property to params::SiloCreate like initial_admin_group_fleet_role: Option<FleetRoles>. This is intended to be used with admin_group_name. If the caller has appropriate privileges, then when we create the initial admin group, we'd create a role assignment granting the new group the specified fleet role.

Note that this would not be a property of the Silo. It's just a create-time property that controls what we do during creation. It has no meaning after the Silo is created.

Downsides:

• It doesn't support granting fleet admin to some other group later. If you forget at silo create time, that's it.
• It doesn't support revoking fleet admin from a user or group. (You can sort of do it, in that you'll see the role assignment when you fetch the fleet policy, and you can remove it. But the policy just has opaque ids -- you won't know whose role assignment you're removing unless you can figure out some other way.)
• It might be confusing to people that this only applies to the group that gets autocreated when the Silo gets created. If you change which group has "silo admin" later, it will not change who has "fleet admin". You will need an existing fleet administrator to do that.

Idea 3: As a Fleet-level admin, you can configure which Silo roles confer which Fleet roles

One reading of #1340 is that there's an underlying principle that's something like: people outside a Silo ought not to be able to see the users and groups in that Silo. Or, if that seems draconian, one could think of it as: people outside a Silo ought not need to know about all the specific users and groups within a Silo in order to delegate privileges to the Silo. Instead, maybe they could express to the system something more like "I trust this Silo" rather than individual users and groups. Of course, they don't trust the whole Silo. Presumably they trust the administrators of the Silo. So maybe we could add a new property (or properties) to the Silo itself that specify which Silo roles confer which Fleet roles.

1. In the simplest case, imagine a Silo property called silo_admin_is_fleet_admin: bool. You could specify this at create-time or modify it later (assuming we support PUTs to the Silo resource, which I think we don't yet, but we could). This means "anybody who has the 'Silo Admin' role in this Silo also gets the 'Fleet Admin' role."
2. A little more flexible would be something like: fleet_roles_for_silo_admin: Vec<FleetRoles>. Here, you'd be saying "anybody who has the 'Silo Admin' role in this Silo also gets these roles on the Fleet".
3. Most flexible would be something like: fleet_roles: BTreeMap<SiloRoles, Vec<FleetRoles>>. Here, you'd be providing a bunch of rules like "anybody who has this role in this Silo gets these roles on the Fleet". This would let you say something like: silo admins can administer the Fleet, and anybody else in the Silo can view the Fleet.

This seems pretty appealing to me if we're on board with the initial principle that the Fleet Admin's responsibility isn't to know about the users and groups inside other Silos. But I'm a little worried this is overengineering things for what we need now.

In terms of implementation: I hope that we can do this by putting this property into the authz::Silo object that we expose to Oso and then write a policy rule for has_role(actor, role, fleet: Fleet) that evaluates whether the user has some corresponding role on any Silo. I'm not yet sure what this would look like.

[mx-shift]

I prefer option 3 precisely because it does attempt to maintain knowledge of users/groups solely within a Silo.

Option 1 would be difficult to implement in practice due to JIT user/group provisioning. A user would need to log in to a Silo before they could be granted fleet roles.

Stepping back a bit, this all highlights a rough edge with our model of IdPs being strongly associated with Silos. While user accounts exist in Silos, users exist in IdPs. Same applies for groups. With our current model and option 3, fleet roles would be attached not only to a specific user, but to a specific user logged into a designated Silo. That's awkward for a role that, by definition, exists above the concept of Silos.

[davepacheco]

I also got feedback in favor of option 3 from a few others so that's what I did in #3349.

[davepacheco]

With our current model and option 3, fleet roles would be attached not only to a specific user, but to a specific user logged into a designated Silo. That's awkward for a role that, by definition, exists above the concept of Silos.

@mx-shift I don't quite follow this. With option 3, there is never a need to directly attach Fleet roles to any user or group. Instead, you would set this policy on the Silo saying "for this Silo, people with the Admin role also get the Fleet Admin role". In #3349 I have even modified the behavior of rack initialization so that even the initial user in the recovery Silo doesn't get the "Fleet Admin" role assigned to them directly. Instead, the recovery Silo uses this Silo-level policy to confer Fleet-level Admin role to any administrators of the recovery Silo.

Or are you saying that it's awkward that we would even indirectly grant this role to any Silo user, rather than only granting it to some kind of account that exists outside of a Silo? I don't follow this objection. One of the primary purposes of a Silo is to be a realm of user accounts. Whatever identity that gets these roles has to come from some IdP, and we happen to have called the nexus of IdP configuration a "Silo". Is the confusion that a Silo can also be a container for other resources? That's fair, but this was discussed under RFD 297. We could still make changes here (i.e., create "operations-only" Silos).

Sorry if I'm misunderstanding -- I've obviously tried to infer what you meant but I probably should have just asked!