Users who have the silo admin role can create, update and delete all projects and their resources.
Silo admin users may grant project access to groups and users in two different ways:
Silo-level access: Assign the group or user the
admin,collaboratororviewerrole to access all projects in the siloProject-level access: Assign the group or user one of the three IAM roles only in specific projects
Project admin users also have the ability to configure the IAM roles for their projects. The scope of the three built-in IAM roles are described in details in the IAM Policy section.
viewer role granted to all users (e.g. via an everyone group in the IdP). This combination of role permissions allows users to see all projects in the silo and locate the individual projects from the list. Without the silo viewer role, users can still access individual projects by referencing their direct end points using the project name or UUID.Related API Reference
Accessible by fleet administrator only:
Managing Users and Groups
Identity Provider (IdP) Users
User information, including group memberships, is not modifiable in the rack because the IdP is the source of truth. The only data maintained in the rack locally is the SSH keys to be used in virtual machine instances.
Every time a user authenticates to the rack, their profile information is automatically imported or updated in the rack.
When a user is removed or deactivated in the IdP, they will no longer have access to the rack. The user record will however remain in the rack database.
Local Users
Local users can be created, modified, and deleted via API for silos configured with the local_user identity mode. The ability to manage local users is currently restricted to operators who have the fleet-admin IAM role.
End-users do not have the ability to set their own passwords at this time. Fleet administrators will set the user password during account creation, and use the set/invalidate user password API to make password changes as needed.
Groups
Groups are replicated into the Oxide rack from the identity provider during user import. They are used only for configuring roles in IAM policies and cannot be modified in the rack. The IdP is the only place in which group membership information is maintained.
Group membership is a useful mechanism for granting IAM roles for the following reasons:
Group members get the necessary project and resource access as soon as they are authenticated to the system.
User project memberships or role changes are reflected in the Oxide rack once they log into the console again.
Related API Reference
Accessible by fleet administrator only: