Chapter 1. Access control
Access control might need to manually be created and managed. You must configure authentication service requirements for Red Hat Advanced Cluster Management for Kubernetes to onboard workloads to Identity and Access Management (IAM). For more information see, Understanding authentication in Understanding authentication in the OpenShift Container Platform documentation.
Role-based access control and authentication identifies the user associated roles and cluster credentials. See the following files for information about access and credentials.
Required access: Cluster administrator
1.1. Role-based access control
Red Hat Advanced Cluster Management for Kubernetes supports role-based access control (RBAC). Your role determines the actions that you can perform. RBAC is based on the authorization mechanisms in Kubernetes, similar to Red Hat OpenShift Container Platform. For more information about RBAC, see the OpenShift RBAC overview in the OpenShift Container Platform documentation.
Note: Action buttons are disabled from the console if the user-role access is impermissible.
1.1.1. Overview of roles
Some product resources are cluster-wide and some are namespace-scoped. You must apply cluster role bindings and namespace role bindings to your users for consistent access controls. View the table list of the following role definitions that are supported in Red Hat Advanced Cluster Management for Kubernetes:
Role | Definition |
|
This is an OpenShift Container Platform default role. A user with cluster binding to the |
|
A user with cluster binding to the |
|
A user with cluster binding to the |
|
A user with cluster binding to the |
|
A user with cluster binding to the |
|
A user with cluster binding to the |
|
A user with the |
admin, edit, view |
Admin, edit, and view are OpenShift Container Platform default roles. A user with a namespace-scoped binding to these roles has access to |
|
A user with the |
Important:
- Any user can create projects from OpenShift Container Platform, which gives administrator role permissions for the namespace.
-
If a user does not have role access to a cluster, the cluster name is not displayed. The cluster name might be displayed with the following symbol:
-
.
See Implementing role-based access control for more details.
1.2. Implementing role-based access control
Red Hat Advanced Cluster Management for Kubernetes RBAC is validated at the console level and at the API level. Actions in the console can be enabled or disabled based on user access role permissions.
The multicluster engine operator is a prerequisite and the cluster lifecycle function of Red Hat Advanced Cluster Management. To manage RBAC for clusters with the multicluster engine operator, use the RBAC guidance from the cluster lifecycle multicluster engine for Kubernetes operator Role-based access control documentation.
View the following sections for more information on RBAC for specific lifecycles for Red Hat Advanced Cluster Management:
1.2.1. Application lifecycle RBAC
When you create an application, the subscription
namespace is created and the configuration map is created in the subscription
namespace. You must also have access to the channel
namespace. When you want to apply a subscription, you must be a subscription administrator. For more information on managing applications, see Creating an allow and deny list as subscription administrator.
View the following application lifecycle RBAC operations:
Create and administer applications on all managed clusters with a user named
username
. You must create a cluster role binding and bind it tousername
. Run the following command:oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:cluster-manager-admin --user=<username>
This role is a super user, which has access to all resources and actions. You can create the namespace for the application and all application resources in the namespace with this role.
Create applications that deploy resources to multiple namespaces. You must create a cluster role binding to the
open-cluster-management:subscription-admin
cluster role, and bind it to a user namedusername
. Run the following command:oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:subscription-admin --user=<username>
Create and administer an application named
application-name
in thecluster-name
managed cluster, with theusername
user. You must create a cluster role binding to theopen-cluster-management:admin:<cluster-name>
cluster role and bind it tousername
by entering the following command:oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:admin:<cluster-name> --user=<username>
This role has read and write access to all
application
resources on the managed cluster,cluster-name
. Repeat this if access for other managed clusters is required.Create a namespace role binding to the
application
namespace using theadmin
role and bind it tousername
by entering the following command:oc create rolebinding <role-binding-name> -n <application-namespace> --clusterrole=admin --user=<username>
This role has read and write access to all
application
resources in theapplication
namspace. Repeat this if access for other applications is required or if the application deploys to multiple namespaces.You can create applications that deploy resources to multiple namespaces. Create a cluster role binding to the
open-cluster-management:subscription-admin
cluster role and bind it tousername
by entering the following command:oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:subscription-admin --user=<username>
To view an application on a managed cluster named
cluster-name
with the user namedusername
, create a cluster role binding to theopen-cluster-management:view:
cluster role and bind it tousername
. Enter the following command:oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:view:<cluster-name> --user=<username>
This role has read access to all
application
resources on the managed cluster,cluster-name
. Repeat this if access for other managed clusters is required.Create a namespace role binding to the
application
namespace using theview
role and bind it tousername
. Enter the following command:oc create rolebinding <role-binding-name> -n <application-namespace> --clusterrole=view --user=<username>
This role has read access to all
application
resources in theapplication
namspace. Repeat this if access for other applications is required.
1.2.1.1. Console and API RBAC table for application lifecycle
View the following console and API RBAC tables for Application lifecycle:
Resource | Admin | Edit | View |
---|---|---|---|
Application | create, read, update, delete | create, read, update, delete | read |
Channel | create, read, update, delete | create, read, update, delete | read |
Subscription | create, read, update, delete | create, read, update, delete | read |
Placement rule | create, read, update, delete | create, read, update, delete | read |
API | Admin | Edit | View |
---|---|---|---|
| create, read, update, delete | create, read, update, delete | read |
| create, read, update, delete | create, read, update, delete | read |
| create, read, update, delete | create, read, update, delete | read |
| create, read, update, delete | create, read, update, delete | read |
| create, read, update, delete | create, read, update, delete | read |
| create, read, update, delete | create, read, update, delete | read |
| create, read, update, delete | create, read, update, delete | read |
| create, read, update, delete | create, read, update, delete | read |
| create, read, update, delete | create, read, update, delete | read |
| create, read, update, delete | create, read, update, delete | read |
1.2.2. Governance lifecycle RBAC
When a policy is created, the policy is created in the cluster. Roles for the governance lifecycle are namespace-scoped. A user must also have access to the managed cluster.
To perform governance lifecycle operations, users must have access to the namespace where the policy is created, along with access to the managed cluster where the policy is applied.
View the following operations:
To create a policy in the
policy
namespace and apply it in a managed cluster namedcluster-name
, create a namespace role binding to thepolicy
namespace using theopen-cluster-management:admin:<cluster-name>
cluster role. Run the following command:oc create rolebinding <role-binding-name> -n <policy-namespace> --clusterrole=open-cluster-management:admin:<cluster-name> --user=<username>
To view a policy in a managed cluster, create a cluster role binding to
open-cluster-management:view:<cluster-name>
cluster role and bind it to theview
role with the following command:oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:view:<cluster-name> --user=<username>
1.2.2.1. Console and API RBAC table for governance lifecycle
View the following console and API RBAC tables for governance lifecycle:
Resource | Admin | Edit | View |
---|---|---|---|
Policies | create, read, update, delete | read, update | read |
PlacementBindings | create, read, update, delete | read, update | read |
Placements | create, read, update, delete | read, update | read |
PlacementRules | create, read, update, delete | read, update | read |
PolicyAutomations | create, read, update, delete | read, update | read |
API | Admin | Edit | View |
---|---|---|---|
| create, read, update, delete | read, update | read |
| create, read, update, delete | read, update | read |
| create, read, update, delete | read, update | read |
1.2.3. Observability RBAC
To view the observability metrics for a managed cluster, you must have view
access to that managed cluster on the hub cluster. View the following list of observability features:
Access managed cluster metrics.
Users are denied access to managed cluster metrics, if they are not assigned to the
view
role for the managed cluster on the hub cluster. Run the following command to verify if a user has the authority to create amanagedClusterView
role in the managed cluster namespace:oc auth can-i create ManagedClusterView -n <managedClusterName> --as=<user>
As a cluster administrator, create a
managedClusterView
role in the managed cluster namespace. Run the following command:oc create role create-managedclusterview --verb=create --resource=managedclusterviews -n <managedClusterName>
Then apply and bind the role to a user by creating a role bind. Run the following command:
oc create rolebinding user-create-managedclusterview-binding --role=create-managedclusterview --user=<user> -n <managedClusterName>
Search for resources.
To verify if a user has access to resource types, use the following command:
oc auth can-i list <resource-type> -n <namespace> --as=<rbac-user>
Note:
<resource-type>
must be plural.To view observability data in Grafana, you must have a
RoleBinding
resource in the same namespace of the managed cluster.View the following
RoleBinding
example:kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: <replace-with-name-of-rolebinding> namespace: <replace-with-name-of-managedcluster-namespace> subjects: - kind: <replace with User|Group|ServiceAccount> apiGroup: rbac.authorization.k8s.io name: <replace with name of User|Group|ServiceAccount> roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: view
See Role binding policy for more information. See Customizing observability to configure observability.
1.2.3.1. Console and API RBAC table for observability lifecycle
To manage components of observability, view the following API RBAC table:
API | Admin | Edit | View |
| create, read, update, and delete | read, update | read |
| create, get, list, watch, update, delete, patch | - | - |
| get, list, watch | get, list, watch | get, list, watch |
Continue to learn about securing your cluster, see Risk and compliance.