Menu Close
Chapter 1. Security
Manage your security and role-based access control (RBAC) of Red Hat Advanced Cluster Management for Kubernetes components. Govern your cluster with defined policies and processes to identify and minimize risks. Use policies to define rules and set controls.
Prerequisite: 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 OpenShift Container Platform documentation.
Review the following topics to learn more about securing your cluster:
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.
View the following sections for details of supported RBAC by component:
1.1.1. Overview of roles
Some product resources are cluster-wide and some are namespace-scoped. You must apply cluster rolebindings and namespace rolebindings 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:
Table 1.1. Role definition table
Role | Definition |
---|---|
cluster-admin |
A user with cluster-wide binding to the |
open-cluster-management:cluster-manager-admin |
A user with cluster-wide binding to the |
open-cluster-management:managed-cluster-x (admin) |
A user with cluster binding to the |
open-cluster-management:managed-cluster-x (viewer) |
A user with cluster-wide binding to the |
open-cluster-management:subscription-admin |
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 |
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 visible. The cluster name is displayed with the following symbol:
-
.
1.1.2. RBAC implementation
RBAC is validated at the console level and the API level. Actions in the console can be enabled or disabled based on user access role permissions. View the following sections for more information on RBAC for specific lifecyles in the product.
1.1.2.1. Cluster lifecycle RBAC
View the following cluster lifecycle RBAC operations.
To create and administer all managed clusters:
Create a cluster role binding to the cluster role
open-cluster-management:cluster-manager-admin
by entering the following command:oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:cluster-manager-admin
This role is a super user, which has access to all resources and actions. This role allows you to create cluster-scoped
managedcluster
resources, the namespace for the resources that manage the managed cluster, and the resources in the namespace. This role also allows access to provider connections and to bare metal assets that are used to create managed clusters.
To administer a managed cluster named cluster-name
:
Create a cluster role binding to the cluster role
open-cluster-management:admin:<cluster-name>
by entering the following command:oc create clusterrolebinding (role-binding-name) --clusterrole=open-cluster-management:admin:<cluster-name>
This role allows read and write access to the cluster-scoped
managedcluster
resource. This is needed because themanagedcluster
is a cluster-scoped resource and not a namespace-scoped resource.Create a namespace role binding to the cluster role
admin
by entering the following command:oc create rolebinding <role-binding-name> -n <cluster-name> --clusterrole=admin
This role allows read and write access to the resources in the namespace of the managed cluster.
To view a managed cluster named cluster-name
:
Create a cluster role binding to the cluster role
open-cluster-management:view:<cluster-name>
by entering the following command:oc create clusterrolebinding <role-binding-name> --clusterrole=open-cluster-management:view:<cluster-name>
This role allows read access to the cluster-scoped
managedcluster
resource. This is needed because themanagedcluster
is a cluster-scoped resource and not a namespace-scoped resource.Create a namespace role binding to the cluster role
view
by entering the following command:oc create rolebinding <role-binding-name> -n <cluster-name> --clusterrole=view
This role allows read-only access to the resources in the namespace of the managed cluster.
See ManagedClusterSets to learn about managing ManagedClusterSet
resources.
View the following console and API RBAC tables for cluster lifecycle:
Table 1.2. Console RBAC table for Cluster lifecycle
Action | Admin | Edit | View |
---|---|---|---|
Clusters | read, update, delete | read, update | read |
Provider connections | create, read, update, and delete | create, read, update, and delete | read |
Bare metal asset | create, read, update, delete | read, update | read |
Table 1.3. API RBAC table for Cluster lifecycle
API | Admin | Edit | View |
---|---|---|---|
manageclusters.cluster.open-cluster-management.io | create, read, update, delete | read, update | read |
baremetalassets.inventory.open-cluster-management.io | create, read, update, delete | read, update | read |
klusterletaddonconfigs.agent.open-cluster-management.io | create, read, update, delete | read, update | read |
managedclusteractions.action.open-cluster-management.io | create, read, update, delete | read, update | read |
managedclusterviews.view.open-cluster-management.io | create, read, update, delete | read, update | read |
managedclusterinfos.internal.open-cluster-management.io | create, read, update, delete | read, update | read |
manifestworks.work.open-cluster-management.io | create, read, update, delete | read, update | read |
1.1.2.2. Application lifecycle RBAC
When you create an application, the subscription
namespace is created and the configuration map is created in the subscription
namespace. When you want to apply a subscription, you must be a subscription administrator. For more information on managing applications, see Creating and managing subscriptions.
To perform Application lifecycle tasks, users with the admin
role must have access to the namespace where the application is created and to the managedcluster
namespace. For example, the required access to create applications in namespace "N" is a namespace-scoped binding to the admin
role for namespace "N".
View the following console and API RBAC tables for Application lifecycle:
Table 1.4. Console RBAC table for Application lifecycle
Action | 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 |
Table 1.5. API RBAC table for Application lifecycle
API | Admin | Edit | View |
---|---|---|---|
applications.app.k8s.io | create, read, update, delete | create, read, update, delete | read |
channels.apps.open-cluster-management.io | create, read, update, delete | create, read, update, delete | read |
deployables.apps.open-cluster-management.io | create, read, update, delete | create, read, update, delete | read |
helmreleases.apps.open-cluster-management.io | create, read, update, delete | create, read, update, delete | read |
placementrules.apps.open-cluster-management.io | create, read, update, delete | create, read, update, delete | read |
subscriptions.apps.open-cluster-management.io | create, read, update, delete | create, read, update, delete | read |
configmaps | create, read, update, delete | create, read, update, delete | read |
secrets | create, read, update, delete | create, read, update, delete | read |
namespaces | create, read, update, delete | create, read, update, delete | read |
1.1.2.3. Governance lifecycle RBAC
To perform Governance lifecycle operations, users must have access to the namespace where the policy is created, along with access to the managedcluster
namespace where the policy is applied.
View the following examples:
To view policies in namespace "N" the following role is required:
-
A namespace-scoped binding to the
view
role for namespace "N".
-
A namespace-scoped binding to the
To create a policy in namespace "N" and apply it on
managedcluster
"X", the following roles are required:-
A namespace-scoped binding to the
admin
role for namespace "N". -
A namespace-scoped binding to the
admin
role for namespace "X".
-
A namespace-scoped binding to the
View the following console and API RBAC tables for Governance lifecycle:
Table 1.6. Console RBAC table for Governance lifecycle
Action | Admin | Edit | View |
---|---|---|---|
Policies | create, read, update, delete | read, update | read |
PlacementBindings | create, read, update, delete | read, update | read |
PlacementRules | create, read, update, delete | read, update | read |
Table 1.7. API RBAC table for Governance lifecycle
API | Admin | Edit | View |
---|---|---|---|
policies.policy.open-cluster-management.io | create, read, update, delete | read, update | read |
placementbindings.policy.open-cluster-management.io | create, read, update, delete | read, update | read |
1.1.2.4. Observability RBAC
To use the observability features, you must be assigned the cluster-admin
or the open-cluster-management:cluster-manager-admin
role. View the following list of observability features:
- Access managed cluster metrics.
- Search for resources.
- Use the Visual Web Terminal if you have access to the managed cluster.
To create, update, and delete the MultiClusterObservability custom resource. View the following RBAC table:
Table 1.8. API RBAC table for observability
API | Admin | Edit | View |
multiclusterobservabilities.observability.open-cluster-management.io | create, read, update, and delete | - | - |
To continue to learn more about securing your cluster, see Security.
1.2. Certificates
Various certificates are created and used throughout Red Hat Advanced Cluster Management for Kubernetes.
You can bring your own certificates. You must create a Kubernetes TLS Secret for your certificate. After you create your certificates, you can replace certain certificates that are created by the Red Hat Advanced Cluster Management installer.
Required access: Cluster administrator or team administrator.
Note: Replacing certificates is supported only on native Red Hat Advanced Cluster Management installations.
All certificates required by services that run on Red Hat Advanced Cluster Management are created during the installation of Red Hat Advanced Cluster Management. Certificates are created and managed by the Red Hat Advanced Cluster Management Certificate manager (cert-manager
) service. The Red Hat Advanced Cluster Management Root Certificate Authority (CA) certificate is stored within the Kubernetes Secret multicloud-ca-cert
in the hub cluster namespace. The certificate can be imported into your client truststores to access Red Hat Advanced Cluster Management Platform APIs.
See the following topics to replace certificates:
1.2.1. List certificates
You can view a list of certificates that use cert-manager
internally by running the following command:
oc get certificates.certmanager.k8s.io -n open-cluster-management
Note: If observability is enabled, there are additional namespaces where certificates are created.
1.2.2. Refresh a certificate
You can refresh a certificate by running the command in the Section 1.2.1, “List certificates” section. When you identify the certificate that you need to refresh, delete the secret that is associated with the certificate. For example, you can delete a secret by running the following command:
oc delete secret grc-0c925-grc-secrets -n open-cluster-management
1.2.3. Refresh certificates for Red Hat Advanced Cluster Management for Kubernetes
You can refresh all certificates that are issued by the Red Hat Advanced Cluster Management CA. During the refresh, the Kubernetes secret that is associated with each cert-manager
certificate is deleted. The service restarts automatically to use the certifcate. Run the following command:
oc delete secret -n open-cluster-management $(oc get certificates.certmanager.k8s.io -n open-cluster-management -o wide | grep multicloud-ca-issuer | awk '{print $3}')
The Red Hat OpenShift Container Platform certificate is not included in the Red Hat Advanced Cluster Management for Kubernetes management ingress. For more information, see the Security known issues. Use the certificate policy controller to create and manage certificate policies on managed clusters. See Policy controllers to learn more about controllers. Return to the Security page for more information.
1.2.4. Replacing the root CA certificate
You can replace the root CA certificate.
1.2.4.1. Prerequisites for root CA certificate
Verify that your Red Hat Advanced Cluster Management for Kubernetes cluster is running.
Back up the existing Red Hat Advanced Cluster Management for Kubernetes certificate resource by running the following command:
oc get cert multicloud-ca-cert -n open-cluster-management -o yaml > multicloud-ca-cert-backup.yaml
1.2.4.2. Creating the root CA certificate with OpenSSL
Complete the following steps to create a root CA certificate with OpenSSL:
Generate your certificate authority (CA) RSA private key by running the following command:
openssl genrsa -out ca.key 4096
Generate a self-signed CA certificate by using your CA key. Run the following command:
openssl req -x509 -new -nodes -key ca.key -days 400 -out ca.crt -config req.cnf
Your
req.cnf
file might resemble the following file:[ req ] # Main settings default_bits = 4096 # Default key size in bits. prompt = no # Disables prompting for certificate values so the configuration file values are used. default_md = sha256 # Specifies the digest algorithm. distinguished_name = dn # Specifies the section that includes the distinguished name information. x509_extensions = v3_ca # The extentions to add to the self signed cert [ dn ] # Distinguished name settings C = US # Country ST = North Carolina # State or province L = Raleigh # Locality O = Red Hat Open Shift # Organization OU = Red Hat Advanced Container Management # Organizational unit CN = www.redhat.com # Common name. [ v3_ca ] # x509v3 extensions basicConstraints=critical,CA:TRUE # Indicates whether the certificate is a CA certificate during the certificate chain verification process.
1.2.4.3. Replacing root CA certificates
Create a new secret with the CA certificate by running the following command:
kubectl -n open-cluster-management create secret tls byo-ca-cert --cert ./ca.crt --key ./ca.key
Edit the CA issuer to point to the BYO certificate. Run the following commnad:
oc edit issuer -n open-cluster-management multicloud-ca-issuer
-
Replace the string
mulicloud-ca-cert
withbyo-ca-cert
. Save your deployment and quit the editor. Edit the management ingress deployment to reference the Bring Your Own (BYO) CA certificate. Run the following command:
oc edit deployment management-ingress-435ab
-
Replace the
multicloud-ca-cert
string with thebyo-ca-cert
. Save your deployment and quit the editor. - Validate the custom CA is in use by logging in to the console and view the details of the certificate being used.
1.2.4.4. Refreshing cert-manager certificates
After the root CA is replaced, all certificates that are signed by the root CA must be refreshed and the services that use those certificates must be restarted. Cert-manager creates the default Issuer from the root CA so all of the certificates issued by cert-manager
, and signed by the default ClusterIssuer must also be refreshed.
Delete the Kubernetes secrets associated with each cert-manager
certificate to refresh the certificate and restart the services that use the certificate. Run the following command:
oc delete secret -n open-cluster-management $(oc get cert -n open-cluster-management -o wide | grep multicloud-ca-issuer | awk '{print $3}')
1.2.4.5. Restoring root CA certificates
To restore the root CA certificate, update the CA issuer by completing the following steps:
Edit the CA issuer. Run the following command:
oc edit issuer -n open-cluster-management multicloud-ca-issuer
-
Replace the
byo-ca-cert
string withmulticloud-ca-cert
in the editor. Save the issuer and quit the editor. Edit the management ingress depolyment to reference the original CA certificate. Run the following command:
oc edit deployment management-ingress-435ab
-
Replace the
byo-ca-cert
string with themulticloud-ca-cert
string. Save your deployment and quit the editor. Delete the BYO CA certificate. Run the following commnad:
oc delete secret -n open-cluster-management byo-ca-cert
Refresh all cert-manager
certificates that use the CA. For more information, see the forementioned section, Refreshing cert-manager certificates.
See Certificates for more information about certificates that are created and managed by Red Hat Advanced Cluster Management for Kubernates.
1.2.5. Replacing the management ingress certificates
You can replace management ingress certificates. If you replace the default ingress certificate for OpenShift Container Platform, you need to make modifications to the management ingress. For more information see, 500 Internal error during login to the console in the Security known issues.
1.2.5.1. Prerequisites to replace management ingress certificate
Prepare and have your management-ingress
certificates and private keys ready. If needed, you can generate a TLS certificate by using OpenSSL. Set the common name parameter,CN
, on the certificate to manangement-ingress
. If you are generating the certificate, include the following settings:
Include the following IP addresses and domain names in your certificate Subject Alternative Name (SAN) list:
-
The service name for the management ingress:
management-ingress
. Include the route name for Red Hat Advanced Cluster Management for Kubernetes. Recieve the route name by running the following command:
oc get route -n open-cluster-management
You might receieve the following response:
multicloud-console.apps.grchub2.dev08.red-chesterfield.com
-
Add the localhost IP address:
127.0.0.1
. -
Add the localhost entry:
localhost
.
-
The service name for the management ingress:
1.2.5.1.1. Example configuration file for generating a certificate
The following example configuration file and OpenSSL commands provide an example for how to generate a TLS certificate by using OpenSSL. View the following csr.cnf
configuration file, which defines the configuration settings for generating certificates with OpenSSL.
[ req ] # Main settings default_bits = 2048 # Default key size in bits. prompt = no # Disables prompting for certificate values so the configuration file values are used. default_md = sha256 # Specifies the digest algorithm. req_extensions = req_ext # Specifies the configuration file section that includes any extensions. distinguished_name = dn # Specifies the section that includes the distinguished name information. [ dn ] # Distinguished name settings C = US # Country ST = North Carolina # State or province L = Raleigh # Locality O = Red Hat Open Shift # Organization OU = Red Hat Advanced Container Management # Organizational unit CN = management-ingress # Common name. [ req_ext ] # Extensions subjectAltName = @alt_names # Subject alternative names [ alt_names ] # Subject alternative names DNS.1 = management-ingress DNS.2 = multicloud-console.apps.grchub2.dev08.red-chesterfield.com DNS.3 = localhost DNS.4 = 127.0.0.1 [ v3_ext ] # x509v3 extensions authorityKeyIdentifier=keyid,issuer:always # Specifies the public key that corresponds to the private key that is used to sign a certificate. basicConstraints=CA:FALSE # Indicates whether the certificate is a CA certificate during the certificate chain verification process. #keyUsage=keyEncipherment,dataEncipherment # Defines the purpose of the key that is contained in the certificate. extendedKeyUsage=serverAuth # Defines the purposes for which the public key can be used. subjectAltName=@alt_names # Identifies the subject alternative names for the identify that is bound to the public key by the CA.
Note: Be sure to update the SAN labeled, DNS.2
with the correct hostname for your management ingress.
1.2.5.1.2. OpenSSL commands for generating a certificate
The following OpenSSL commands are used with the preceding configuration file to generate the required TLS certificate.
Generate your certificate authority (CA) RSA private key:
openssl genrsa -out ca.key 4096
Generate a self-signed CA certificate by using your CA key:
openssl req -x509 -new -nodes -key ca.key -subj "/C=US/ST=North Carolina/L=Raleigh/O=Red Hat OpenShift" -days 400 -out ca.crt
Generate the RSA private key for your certificate:
openssl genrsa -out ingress.key 4096
Generate the Certificate Signing request (CSR) by using the private key:
openssl req -new -key ingress.key -out ingress.csr -config csr.cnf
Generate a signed certificate by using your CA certificate and key and CSR:
openssl x509 -req -in ingress.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out ingress.crt -sha256 -days 300 -extensions v3_ext -extfile csr.cnf
Examine the certificate contents:
openssl x509 -noout -text -in ./ingress.crt
1.2.5.2. Replace the Bring Your Own (BYO) ingress certificate
Complete the following steps to replace your BYO ingress certificate:
Create the
byo-ingress-tls
secret by using your certificate and private key. Run the following command:kubectl -n open-cluster-management create secret tls byo-ingress-tls-secret --cert ./ingress.crt --key ./ingress.key
Verify that the secret is created in the correct namespace.
kubectl get secret -n open-cluster-management | grep byo-ingress | grep tls
Create a secret containing the CA certificate by running the following command:
kubectl -n open-cluster-management create secret tls byo-ca-cert --cert ./ca.crt --key ./ca.key
Edit the management ingress deployment. Get the name of the deployment. Run the following commands:
export MANAGEMENT_INGRESS=`oc get deployment -o custom-columns=:.metadata.name | grep management-ingress` oc edit deployment $MANAGEMENT_INGRESS -n open-cluster-management
-
Replace the
multicloud-ca-cert
string withbyo-ca-cert
. -
Replace the
$MANAGEMENT_INGRESS-tls-secret
string withbyo-ingress-tls-secret
. - Save your deployment and close the editor. The management ingress automatically restarts.
-
Replace the
- After the management ingress pod has restarted, navigate to the Red Hat Advanced Cluster Management for Kubernetes console from your browser. Verify that the current certificate is your certificate, and that all console access and login functionality remain the same.
1.2.5.3. Restore the default self-signed certificate for management ingress
Edit the management ingress deployment. Replace the string
multicloud-ca-cert
withbyo-ca-cert
. Get the name of the deployment. Run the following commands:export MANAGEMENT_INGRESS=`oc get deployment -o custom-columns=:.metadata.name | grep management-ingress` oc edit deployment $MANAGEMENT_INGRESS -n open-cluster-management
-
Replace the
byo-ca-cert
string withmulticloud-ca-cert
. -
Replace the
byo-ingress-tls-secret
string with the$MANAGEMENT_INGRESS-tls-secret
. - Save your deployment and close the editor. The management ingress automatically restarts.
-
Replace the
- After all pods are restarted, navigate to the Red Hat Advanced Cluster Management for Kubernetes console from your browser. Verify that the current certificate is your certificate, and that all console access and login functionality remain the same.
Delete the Bring Your Own (BYO) ingress secret and ingress CA certificate by running the following commands:
oc delete secret -n open-cluster-management byo-ingress-tls-secret oc delete secret -n open-cluster-management byo-ca-cert
See Certificates for more information about certificates that are created and managed by Red Hat Advanced Cluster Management for Kubernates. Return to the Security page for more information on securing your cluster.