Fleet privileges should not cascade into Silos

[davepacheco]

See #1340. This change makes it so that having privileges at the Fleet level does not mean you can see anything at all inside any Silo. You can read, modify, and delete Silos, but not list children or create children. One motivation for this change is that it means a security team wanting to audit a Silo can limit the search to users in the Silo's IdP, knowing that nobody else is able to do anything within the Silo.

Right now, Fleet administrators can still read and update the Silo's IAM policy. I'm not sure if that's right, since in principle they could update the policy to include themselves (although they wouldn't have a way to access any siloed resources if they were in a different Silo, per RFD 297). Tangentially, with this change in place, there's no reason any Silo's role assignments should ever refer to a silo user or group from another Silo. We could enforce this. That would satisfy the goal above (because it would still be true that only users in the Silo's IdP could actually do anything). However, it would still let a Fleet admin grant a role to someone inside a Silo, which seems not what we want. I think to prevent this, we'd have to actually separate the Read/ReadPolicy actions (which are currently identical) and the Modify/ModifyPolicy actions (same) so that we can grant "read" and "modify" here but not "ReadPolicy" or "ModifyPolicy".

If folks think this is a good idea, I can do this in a follow-on change.

CC @kc8apf

[plotnick]

I think this is a pretty unambiguous improvement to the overall Silo functionality; previously, the fleet-admin was a kind of enormous loop-hole in the whole Silo concept. But I do think the follow-up to separate read/read-policy and modify/modify-policy is also important, primarily to patch the "fleet admin can modify the silo policy to include themselves" hole, which seems like a serious one.

That said, we are going to have to very carefully document the distinction between a fleet admin and a silo admin. I could see operators being confused about why, say, a fleet admin can't modify a VPC on racks that they are nominally administering. I don't think that's a reason not to make this change, I just think the user-facing documentation will have to spell it out explicitly.

[davepacheco]

Thanks! I've added some items to #849 around this:

• Enforce that Silo, Organization, and Project policies cannot refer to identities outside the Silo.
• Disallow fleet administrators from reading or modifying the policy on the Silo.

[david-crespo]

Agreed on splitting read/write from read policy/write policy.

[smklein]

As a heads up, this PR seems to have broken the process for adding an IdP, at least according to our demo flow: https://github.com/oxidecomputer/meta/blob/master/engineering/remote-access-preview-demo-setup.adoc#setting-up-a-new-silo-with-saml-authentication

With this PR:

$ oxide api /silos/mercury/saml-identity-providers <arguments>
403 Forbidden Forbidden

After reverting this PR:

$ oxide api /silos/mercury/saml-identity-providers <arguments>
<JSON indicating success>

Are there additional arguments I should be using to set up the demo flow?

[davepacheco]

Do you have any of the logs from that failure? I would want to go through this with them to confirm exactly what check was failing. At first glance, I see that Fleet Admins still have privileges to modify the Silo, but not create a child:
https://github.com/oxidecomputer/omicron/blob/main/nexus/tests/output/authz-roles.out#L103-L107
But I thought we had integration tests that create IdPs...

[davepacheco]

Ah, I think I updated the tests to grant "Silo Admin" to the "test-privileged" user on the newly-created Silos. I wonder if the better fix is to treat this as a "modify" operation on the Silo...but I'll file a separate issue to discuss this.

[davepacheco]

See also #1681.