Objects and permissions of multi-tenancy
4 minute read
Group and admin permissions
Group permissions govern which users can see and manage servers and resources, and deploy to specific environments. They keep that role when multi-tenancy is enabled.
Multi-tenancy adds finer-grained permissions to the Super Admin global role. This lets you grant users access to manage a subset of admin objects, but only within their tenant.
For a complete multi-tenancy setup, use both group permissions and admin permissions. See Admin roles.
Global roles
In addition to group and admin permissions, Cloud Management Platform (CMP) has several global roles. The three global roles (Super Admin, Devops Admin, and Global Viewer) apply across tenants and should not be granted to tenant-specific users. Reserve them for users who are expected to work across all tenants.
Tenantized objects
CMP supports associating certain objects with tenants, and lets tenant administrators list, view, create, modify, and delete them. These are referred to as tenantized objects.
The complete set of objects you can associate with a tenant is:
- resource handlers
- configuration managers
- OS builds
- applications
- networks
- IPAMs
- preconfigurations
- SSH keys
- environments
- container orchestrators
- users
- resource pools
Branded portals
Portals can be assigned to tenants from the tenant’s details page, but they are not considered tenantized objects, because admin roles cannot grant access to see and manage them.
Images and templates
Images and templates are specific to tenants, but only indirectly, via their resource handler. For example, if an image is imported for a resource handler in a tenant, only users in that tenant ever see that image.
Global and tenant-specific objects
Setting the tenant on an object
When a user who belongs to a tenant and has tenant permissions creates a tenantized object, that user’s tenant is automatically set as the object’s tenant. This prevents users in any other tenant from seeing it.
Super Admins can see and manage objects in any tenant and should take care not to relate objects from different tenants. For example, if a Super Admin adds an environment belonging to “Tenant A” to a group representing “Tenant B”, users in Tenant B could see and deploy resources to Tenant A’s environment.
Creating new tenantized objects
When Super Admins create new tenantized objects, they can choose a tenant for the object. This lets Super Admins help tenant administrators during setup.
Once an object is created, its tenant cannot be changed. To move one, delete the tenantized object and recreate it in its new tenant.
Global objects with no tenant
Global objects (those that do not belong to a tenant) are usable by tenants as normal. They do not appear in the list view as tenant-specific admin roles, and tenant-specific admin roles cannot manage them.
Global OS builds with tenant-specific images
Global OS builds behave differently from other global objects. Because Super Admins typically want to make specific blueprints available across tenants, any such blueprint that contains server tiers must use a global (not tenant-specific) OS build. To deploy that global OS build to a tenant-specific environment, tenants must use an image from a tenant-specific resource handler. Therefore, tenant-specific admin roles need a way to associate tenant-specific images with global OS builds.
To allow this, global OS builds appear on the OS build list page for a tenant-specific admin role (unlike other admin list pages). A tenant-specific admin role can open a global OS build to view its details, but not the full details a Super Admin sees; images from other tenants associated with the OS build are hidden.
The only change a tenant-specific admin role can make to a global OS build is to add its own tenant-specific image, which lets it deploy blueprints that use that OS build to its tenant-specific environments.
Tenant-specific Unassigned groups and environments
When CMP runs a Sync VMs job and finds new VMs, it puts the newly discovered server records into a group called Unassigned and an environment called Unassigned (unless it can determine a single environment the server belongs in, in which case it uses that environment). A user with permissions to the Unassigned group reassigns those servers to the appropriate group and environment.
Servers discovered by the Sync VMs job
When a new tenant is created, CMP automatically creates a new “Unassigned for <Tenant Name>” group and environment, and places all discovered servers within the tenant’s resource handler into that group and environment. Each tenant therefore reassigns its own discovered servers.
CMP manages user permissions on these special Unassigned groups, automatically granting reassignment permissions to any user assigned to the tenant (and revoking them if the user is removed from the tenant).
These groups and environments are not shown in the UI. To see all VMs in one of them:
- Go to Resources > Servers, select Show Filters, set the Group and/or Environment filter, and select Apply.
Let us know at support@cloudbolt.io if there are other object types you would like admin roles to manage.