Role-based access control
Cisco Cloud Control uses role-based access control (RBAC) to control what you can view and do across Cisco Cloud Control.
Access roles and permissions
Two-layer access control model
Your Cisco Cloud Control role and your role in each integrated product work together to determine what you can view and do:
-
Cisco Cloud Control role: Controls access to the Cisco Cloud Control portal, account settings, and cross-product navigation. It also controls access to the data displayed in Cisco Cloud Control platform services such as Inventory, Topology, and Actions.
-
Product role: Controls access to features and actions in the integrated product and helps determine which product data, assets, and scopes are available in Cisco Cloud Control.
A Cisco Cloud Control role does not automatically grant you administrative access to every integrated product. You must have explicit permissions at both levels to perform all functions. If you do not have permission to access a feature, Cisco Cloud Control either hides the option or displays an access denied message.
How RBAC controls access
These stages describe how Cisco Cloud Control uses roles and source-product permissions to control access.
-
Cisco Cloud Control retrieves user roles from the Cisco User Identity service.
-
Cisco Cloud Control includes those roles in the user access token.
-
Cisco Cloud Control uses the roles to control access to pages, menu items, data, and actions.
-
For integrated products, Cisco Cloud Control respects the permissions that a user has in the source product.
This source-product permission check provides more granular control over which assets and services are visible in Cisco Cloud Control.
Supported roles
Cisco Cloud Control supports these roles. Each role determines which features, views, and actions are available to users:
-
Member: Configured for all Cisco Cloud Control users by default.
Members can view data for products for which they have permissions, but they cannot manage Cisco Cloud Control environment settings.
-
Environment Admin: Can configure and manage all environment settings.
-
Environment Viewer: Can view all environment settings, but cannot change them.
-
Integration Admin: Can manage cross-product and third-party integrations in Cisco Cloud Control, but has no platform administration rights.
A user can have both the Environment Viewer and Integration Admin roles.
Frequently asked questions
-
Why can’t I sign in to Cisco Cloud Control?
Some common causes include:
-
Your organization is not set up: If you get this message, contact your account team to learn how to get started.
Cisco Cloud Control isn’t set up for your organization yet.
If you’re interested and want to learn more, schedule a demo, or get started with the setup, contact your account team or fill out the form below and our Sales team will be in touch shortly.
-
No integrated product: The organization does not have a Cisco Cloud Control environment. An Environment Admin must complete the integration first.
-
No integrated-product access: The user must have access to at least one product connected to a Cisco Cloud Control environment.
-
Identity or SSO configuration issue: A domain, identity provider (IdP), or routing rule might block sign-in. In Admin Console, go to Settings to review the configuration.
-
-
What is the difference between the Environment Viewer role and read-only access in an integrated product?
Environment Viewer access in Cisco Cloud Control is platform-wide. Read-only access in an integrated product is product-specific and limits your permissions to the features and APIs of that service.
-
Can a user have multiple Cisco Cloud Control roles?
Yes. A user can be assigned multiple roles. For example, a user can have both the Environment Viewer and Integration Admin roles.
-
How can I provide Admin Console access without making a user a product administrator?
Ensure that the product is integrated with Cisco Cloud Control and that the user can sign in with the Member role. Then assign that user a Cisco Cloud Control role, such as Environment Admin or Environment Viewer. These roles control platform-level access and do not automatically grant administrative access to an individual integrated product.
-
What happens when a user is removed from Cisco Cloud Control?
Removing a user from Cisco Cloud Control revokes their access to the platform and to integrated products managed through the platform. The user can no longer sign in or view data through the Cisco Cloud Control portal. This does not change the permissions assigned to the user in the source product.
Integrated-product access
You can access only the assets and services that your source-product permissions allow. Here are a couple of examples that illustrate this behavior:
-
If you are an administrator in Intersight but do not have administrative access in Meraki, you can access Intersight assets through Cisco Cloud Control, but not Meraki assets.
-
The currently selected environment contains three Meraki tenants, and you have access to only two. You can view data for only those two Meraki tenants.
This behavior helps maintain consistent access enforcement between Cisco Cloud Control and the integrated products it manages.
User role management for integrated products
Cisco Cloud Control unifies user management and role assignment for supported integrations. Administrators can manage user roles for integrated products, such as Nexus Dashboard, from Users in Cisco Cloud Control instead of switching to separate management consoles. This includes assigning and revoking Nexus Dashboard roles for Cisco Cloud Control users.
RBAC-controlled areas
RBAC controls access to these areas in Cisco Cloud Control:
-
Pages and menu items
-
Administrative actions
-
Alert and inventory data
-
Topology
-
Actions
These sections describe how RBAC controls access in each area.
Pages and menu items
Your role determines which pages and menu items you can access. Examples include Admin Console and Topology.
Administrative actions
Only users with the required administrative privileges can perform sensitive operations, such as exporting inventory data and deleting configurations.
Read-only users can view information but cannot edit it or perform administrative actions.
Inventory and alert data
Visibility is strictly scoped to the specific product tenants a user can access within the active environment.
Topology access
Topology access is role-based. Depending on your role, you can have one of these topology access levels:
-
Environment Admin: Full access to topology features, including adding, editing, and deleting scopes and sites.
-
Environment Viewer: View-only access to Topology, device details, and site information.
-
Member: Filtered view-only access, showing only the sites, devices, and connections that your product and asset permissions allow. Objects you cannot access are hidden.
-
Integration Admin: No access to Topology. Topology is hidden, and direct URL access is denied.
Actions access
Your role determines whether you can view and execute these tasks in Actions.
| Task | Environment Admin | Member | Environment Viewer | Integration Admin |
|---|---|---|---|---|
|
View Actions |
Yes: all actions across all integrated products |
Yes: only the products you can access through underlying RBAC |
Yes: all actions across all integrated products |
No |
|
Acknowledge, dismiss, or resolve an action |
Yes: gated by your permissions in the underlying controller
This option is unavailable if you don’t have controller access. |
Yes: gated by your permissions in the underlying controller |
No |
No |
|
Run workflows |
Yes |
Yes: gated by your permissions in the underlying controller |
No |
No |
|
Assign an action |
Yes |
Yes: gated by your permissions in the underlying controller |
No |
No |
|
Act on correlated alerts |
Yes: blocked if you are missing permissions on any alert in the group |
Yes: blocked if you are missing permissions on any alert in the group |
No |
No |
|
Audit logging |
Yes: all actions are logged with user identity and timestamp |
Yes: all actions are logged with user identity and timestamp |
Yes: all actions are logged with user identity and timestamp |
No |
-
Actions on correlated alerts follow the weakest-link rule. If you lack permission on any single alert in a correlated group, the action is blocked for the entire group.
-
If you have the Environment Viewer role, you cannot run actions, even if you have member or administrator rights in an underlying product. To act on that product, go to the underlying product directly.
-
If you have both the Integration Admin role and the Member role, you keep access to Actions. Your permissions come from the Member role and the underlying product permissions attached to it.