Role-based access control

IBM® Cloud Private supports several roles. Your role determines the actions that you can do.

Kubernetes offers role-based access control (RBAC) authorization mechanisms, which has been extended on IBM Cloud Private where the users of the cluster platform can be grouped into teams and have namespaces dedicated to teams. With IBM Cloud Private, you can create a team and add users, user groups, and resources to the team. All users in a team have access to the team resources. A user, user group, or resource can be assigned to multiple teams.

IBM Cloud Private has one cluster administrator who has cluster wide access while other users can be classified to various roles, such as Administrator, Editor, Operator, Auditor, and Viewer to various namespaces they have access to. Based on the role assigned to user/user group the level of access to each logical resource on the cluster is defined.

Cluster administrator role and actions

IBM Cloud Private supports the cluster administrator role. The cluster administrator has complete access to the IBM Cloud Private platform.

The following actions can be completed by the cluster administrator:

• Connect to an LDAP directory
• Create teams, add users, and assign them the IAM roles
• Manage workloads, infrastructure, and applications across all namespaces
• Create namespaces
• Assign quotas
• Add pod security policies
• Add an internal Helm repository
• Delete an internal Helm repository
• Add Helm charts to the internal Helm repository
• Remove Helm charts from the internal Helm repository
• Synchronize internal and external Helm repositories
• Manage storage classes and persistent volumes across all namespaces
• Add, remove, and update image security enforcement policies
• Add, remove, and update service IDs in the cluster
• Register and add Service Broker to fetch ClusterServiceClasses and ClusterServicePlans
• Deploy Service Broker chart to fetch ClusterServiceClasses and ClusterServicePlans

For more information about adding pod security policies, see Creating pod security policies.

IAM roles and actions

You can assign an IAM role to users or user groups when you add them to a team. Within a team, each user or user group can have only one role. However, a user might have multiple roles within a team when you add a user individually and also as a member of a team's group. If so, the user can act based on the highest role that is assigned to the user. For example, if you add the user as an administrator and you assign a Viewer role to the user's group, the user can act as an administrator for the team.

A user or user group can be a member of multiple teams and have different roles on each team.

An IAM role defines the actions that a user can do on the team resources.

IBM Cloud Private supports these IAM roles:

Note: Only the Cluster Administrator and Administrator can manage teams, users, and roles. The Administrator cannot assign the Cluster Administrator role to any user or group.

Note: Viewers and editors cannot view logs on any of the IBM Cloud Private management console pages.

RBAC for catalog and Helm resources

X - Operation is supported

* - Deploying and upgrading Helm releases is not supported for charts that remove resources by using hooks or jobs. For more information, see the chart readme file or documentation.

RBAC for Key Management Service (KMS) resources

X - Operation is supported

For a detailed description of each action in table 3, see Key Management Service APIs.

RBAC for Kubernetes resources

The IAM role that you assign to a user also defines the actions that the user can do on the Kubernetes resources that are assigned to the team. For example, if user1 is an operator in team1, and team1 has namespace1 resource, then user1 can view and update namespace1 information. User1 can also create resources, for example pods, in namespace1. If you remove user1 from team1, you remove user1's role binding for the resources in team1. If user1 is part of another team, say team2, that has the same namespace, then user1's role binding to the namespace in team2 is not affected when you remove the user from team1.

RBAC for IAM resources

Note: A user can create Service ID policies with the same level of access that the user has. The user cannot create or assign policies with a higher role to a service ID.