Bootstrapping issue with silo creation outside of RSS

[askfongjojo]

Operator cannot realistically create another silo because they can't access the certificate endpoint for the silo. When a silo is first created, it gets the DNS record but its console endpoint is not accessible until there is a valid TLS certificate.

As a fleet-admin (e.g. recovery user), I was able to add a user to the new silo and grant the user the silo admin role. But then this silo admin user is unable to create a device token (in order to use the API to insert a TLS certificate).

Another minor inconvenience is not being able to list silo users as the fleet admin. After adding the user, I need to ensure to capture the user uuid returned in the API response. If I had lost that information, I would have been unable to pass it into the identity_id field for the update silo IAM API. One way to fix this without exposing more permission to the fleet admin is to allow identity_id to take both name and id as input.

[davepacheco]

Can you say more about how you were doing this? If I'm understanding right, the API accepts TLS certificates in the "create Silo" request for exactly this reason. We use this during the Dogfood deploy process to create the second Silo. Is it that the CLI or web console don't let you supply the certificate?

Another minor inconvenience is not being able to list silo users as the fleet admin.

This is by design (but not set in stone) -- see #1681. If we stick with the current intent that Fleet Admins aren't supposed to be able to list users in other Silos, I don't think we should probably allow them to assign roles, even by id.

[askfongjojo]

Sorry I was looking at an outdated API doc (or just cross-eyed). I did recall that tls cert should have been added to the create silo request.

If we stick with the current intent that Fleet Admins aren't supposed to be able to list users in other Silos, I don't think we should probably allow them to assign roles, even by id.

If we don't allow fleet-admin to update silo policies, I'm not sure who can assign the IAM role to the very first user in the silo, unless (similar to create silo having the tls cert input) we include IAM role in the create user API request payload.

[davepacheco]

If we stick with the current intent that Fleet Admins aren't supposed to be able to list users in other Silos, I don't think we should probably allow them to assign roles, even by id.

If we don't allow fleet-admin to update silo policies, I'm not sure who can assign the IAM role to the very first user in the silo, unless (similar to create silo having the tls cert input) we include IAM role in the create user API request payload.

For Silos using IdPs, this is what "admin_group_name" is for. I think you're right that for local-only (password) Silos, you'd need a way to create an initial admin user in the Silo.

[askfongjojo]

We can actually assign fleet and silo admin privileges to any user as the recovery user. I've tried them out and documented those steps in https://docs.oxide.computer/guides/system/completing-rack-config#_create_local_users.