Use RBAC and portals with multi-tenancy

Multi-tenancy allows a single CMP instance to serve multiple organizations while keeping each organization’s data and resources private. Administrators set global policies, automations, blueprints, and actions, and report on usage across all customers, while each tenant gets a tailored hybrid cloud experience.

Multi-tenancy is especially useful for large companies with different lines of business that should not see each other’s servers, blueprints, and environments.

It also suits managed service providers (MSPs) that provide cloud services to external customers, ensuring that customers (internal or external) can access only the resources they are permitted to and cannot interfere with each other’s operations.

Role-based access control (RBAC)

CMP’s role-based access control features a group tree that lets administrators model different internal and external customers. Each group can be assigned a set of group administrators who can further subdivide the group into subgroups.

For example, if Katsumi is a member of the Wealth Management group but not the Bonds group, they cannot see any servers, services, blueprints, reports, or other data for Bonds.

The built-in roles of Viewer, Requestor, Group Admin, Resource Admin, and Approver can be edited to fit an organization’s needs. You can also create entirely new roles using fine-grained permissions, including access to specific server and resource actions.

SSO and LDAP integration

While CMP’s native RBAC provides the framework for multi-tenancy, it is best practice to leverage your existing group structure and authentication mechanisms with a single user directory source.

CMP supports several forms of integration with external authentication and directory services. Generally, it is preferable to use delegated authentication (where CMP does not store passwords but instead queries an identity provider to determine whether a user can log in) and to synchronize a user’s group from a directory source.

Together, these integrations enable external credential management and allow administrators of those identity providers to manage CMP permissions based on group memberships. This is important for large, multi-tenant deployments that require centralized management of authentication and authorization.

CMP supports LDAP as an authentication and group-mapping source, as well as a number of SSO endpoints. It integrates with Active Directory, Okta, Azure LDAP/SSO, PingOne, ADFS, G Suite, and custom SAML-based identity providers (IdPs).

CMP also exposes trigger points in the external user sync and SSO user update processes, so you can add custom business logic to derive a user’s entitlements.

Per-group customized order form

Each group can decide which questions users are asked when ordering servers, the options and constraints for those questions, which attributes are set on servers without asking the user, and which networks are available.

For example, a group can predefine the hostname template and power schedule, allow the expiration date to be set up to 30 days from order time, constrain the server size to small and medium, and require a quantity between 1 and 5. This data-driven order form provides a tailored user experience.

You can also assign additional parameters to groups that do not appear on the order form. For example, a VM provisioned in AWS that must be tagged with a specific cost center code can have that value stored as a group parameter and applied using the bi-directional tagging capabilities.

Branded portals

CMP allows customization of the UI’s look and feel based on the URL used to access the instance. For example, an MSP that uses a single CMP instance as the portal for multiple external customers can assign each customer a different URL, so the UI appears tailored to each customer.

Each portal can have a different set of authentication methods, so tenants see only their own domains as options on the login page.

Per-group catalog items (blueprints)

Anyone in a group who has the blueprint.manage permission can create blueprints and share them with others in their group. This lets each organization build its own service catalog and automate the deployments and tasks most important to it.

Access to blueprints is defined on the Groups tab of each blueprint. Note the distinction between being able to deploy (order) a blueprint and manage (edit) it.