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 `cluster-admin` role is an OpenShift Container Platform super user, who has all access.
open-cluster-management:cluster-manager-admin	A user with cluster-wide binding to the `cluster-manager-admin` role is a Red Hat Advanced Cluster Management for Kubernetes super user, who has all access.
open-cluster-management:managed-cluster-x (admin)	A user with cluster binding to the `managed-cluster-x` role has administrator access to `managedcluster “X”` resource.
open-cluster-management:managed-cluster-x (viewer)	A user with cluster-wide binding to the `managed-cluster-x` role has view access to `managedcluster “X”` resource.
open-cluster-management:subscription-admin	A user with the `subscription-admin` role can create Git subscriptions that deploy resources to multiple namespaces. The resources are specified in Kubernetes resource YAML files in the subscribed Git repository. Note: When an non-subscription-admin user creates a subscription, all resources are deployed into the subscription namespace regardless of specified namespaces in the resources. For more information, see the Application lifecycle RBAC section.
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 `open-cluster-management` resources in a specific namespace, while cluster-wide binding to the same roles gives access to all of the `open-cluster-management` resources cluster-wide.

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

To perform cluster lifecycle operations, users must have access to both the managedcluster custom resource and namespace, for consistent role behavior from the console.

View the following examples:

To view managedcluster x cluster information, the following roles are required:
- A cluster-wide binding to the role `open-cluster-management:view:X `.
- A namespace-scoped binding to the view role for namespace "X".
A user that has access to only the cluster namespace and not the custom resource can see the cluster, but is not permitted to perform any actions on the managed cluster.
To perform an upgrade to managedcluster x, the following roles are required:
- A cluster-wide binding to the role open-cluster-management:admin:X.
- A namespace-scoped binding to the admin role for namespace "X".
Learn about creating ManagedClusterSet resources to group clusters, see Creating a ManagedClusterSet.

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".
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".

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 with byo-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 the byo-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 with multicloud-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 the multicloud-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.

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 with byo-ca-cert.
- Replace the $MANAGEMENT_INGRESS-tls-secret string with byo-ingress-tls-secret.
- Save your deployment and close the editor. The management ingress automatically restarts.
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 with byo-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
```
1. Replace the byo-ca-cert string with multicloud-ca-cert.
2. Replace the byo-ingress-tls-secret string with the $MANAGEMENT_INGRESS-tls-secret.
3. Save your deployment and close the editor. The management ingress automatically restarts.
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.