Security levels in the C3 Agentic AI Platform
Security levels establish a hierarchical framework of access control and privileges within the C3 Agentic AI Platform. These levels are integral to managing the permissions and capabilities of users, roles, and user groups within the C3 AI Platform.
SecurityLevel is an enumerated Type associated with roles within the C3 Agentic AI Platform that defines their relative hierarchy and access privileges. Security levels are designed to prevent unauthorized access or modification of critical data and functionalities by enforcing a structured permission system based on the assigned level.
A User cannot create or provision Roles with higher security level than their own.
Application of security levels
Roles: A role can have a security level, which dictates its permissions and its ability to interact with other roles. Roles with a specified security level cannot modify roles with a numerically lower security level (higher priority or more privileged roles). This ensures that sensitive or critical functionalities are protected from unauthorized changes.
- Nested Roles: While roles can include other roles (nested roles), a role with a security level cannot have nested roles that also have security levels. This restriction prevents the circumvention of the hierarchical security model by nesting privileged roles within less privileged ones.
Users: Users are entities in the C3 Agentic AI Platform assigned with various roles, directly or using user groups, which in turn define their access and privileges. Users' capabilities are determined by the roles and, implicitly, the security levels of those roles. Regular security level restrictions apply, ensuring that users cannot exceed their permissions by inheriting roles or being part of user groups with higher privileges than allowed.
User Groups: These are collections of users, often reflecting group assignments from an Identity Provider (IdP). Each user group is associated with a specific role, and by extension, inherits the permissions and security level of that role. User groups must comply with security level restrictions, meaning they cannot grant users access or privileges beyond what their security levels permit.
Enforcement and restrictions
Security Levels are numerical values associated with certain roles within the platform, known as SecurityLevel roles. These levels define a relative hierarchy or ranking among roles, where a lower numerical value indicates a higher security status. Roles with assigned security levels are restricted in specific ways:
Modification Restriction: A role with a specific security level cannot modify, or directly alter, roles with a lower numerical security level (for example, higher security status).
Nested Roles Restriction: Roles cannot have nested roles that are SecurityLevel roles. This means a role with a designated security level cannot be a nested role within another role.
Inheritance and Permissions: While roles can inherit permissions and data permissions from their nested roles (if not SecurityLevel roles), the inheritance respects the security level constraints to prevent escalation of privileges.
Example
Let's create a hypothetical scenario to illustrate how security levels might be utilized within this platform, based on the provided documentation:
Roles Definition:
- C3.ClusterAdmin Role: Assigned a SecurityLevel of
1. This role has the highest security level, implying it has comprehensive access across the platform. - C3.EnvAdmin Role: Assigned a SecurityLevel of
2. This role manages environment-specific configurations and settings. - C3.AppAdmin Role: Assigned a SecurityLevel of
3. This role is responsible for application-level configurations and management. - Developer Role: Not explicitly assigned a security level in your example, but for the sake of illustration, let's say it has a SecurityLevel of
7, designated for more granular, development-specific permissions without the broader access of the roles above.
Security Level Restrictions in Action:
- An C3.EnvAdmin cannot modify the C3.ClusterAdmin role or assign the C3.ClusterAdmin role to any user or group because the C3.ClusterAdmin role has a lower numerical security level (higher hierarchy).
- A Developer cannot be given the C3.AppAdmin role as a nested role because it violates the security level hierarchy. Developers work under the umbrella of application management but cannot inherit the C3.AppAdmin's permissions directly.
- If there's an attempt to create a new role that tries to nest an C3.EnvAdmin role within a Developer role, the C3 Agentic AI Platform throws an error, respecting the rule that SecurityLevel roles cannot be nested.
This framework ensures that administrative capabilities are clearly delineated and protected from unauthorized modifications, enforcing a secure and orderly management of platform roles and permissions.