Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

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
Copia collegamento

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
Copia collegamento

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:

Expand
Table 1.1. Role definition table
RoleDefinition

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
Copia collegamento

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
Copia collegamento

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
    Copy to Clipboard Toggle word wrap

    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>
    Copy to Clipboard Toggle word wrap

    This role allows read and write access to the cluster-scoped managedcluster resource. This is needed because the managedcluster 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
    Copy to Clipboard Toggle word wrap

    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>
    Copy to Clipboard Toggle word wrap

    This role allows read access to the cluster-scoped managedcluster resource. This is needed because the managedcluster 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
    Copy to Clipboard Toggle word wrap

    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:

Expand
Table 1.2. Console RBAC table for Cluster lifecycle
ActionAdminEditView

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

Expand
Table 1.3. API RBAC table for Cluster lifecycle
APIAdminEditView

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
Copia collegamento

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:

Expand
Table 1.4. Console RBAC table for Application lifecycle
ActionAdminEditView

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

Expand
Table 1.5. API RBAC table for Application lifecycle
APIAdminEditView

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
Copia collegamento

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:

Expand
Table 1.6. Console RBAC table for Governance lifecycle
ActionAdminEditView

Policies

create, read, update, delete

read, update

read

PlacementBindings

create, read, update, delete

read, update

read

PlacementRules

create, read, update, delete

read, update

read

Expand
Table 1.7. API RBAC table for Governance lifecycle
APIAdminEditView

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
Copia collegamento

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:

Expand
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
Copia collegamento

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
Copia collegamento

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
Copy to Clipboard Toggle word wrap

Note: If observability is enabled, there are additional namespaces where certificates are created.

1.2.2. Refresh a certificate
Copia collegamento

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
Copy to Clipboard Toggle word wrap

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}')
Copy to Clipboard Toggle word wrap

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
Copia collegamento

You can replace the root CA certificate.

1.2.4.1. Prerequisites for root CA certificate
Copia collegamento

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
Copy to Clipboard Toggle word wrap

1.2.4.2. Creating the root CA certificate with OpenSSL
Copia collegamento

Complete the following steps to create a root CA certificate with OpenSSL:

  1. Generate your certificate authority (CA) RSA private key by running the following command: 

    openssl genrsa -out ca.key 4096
    Copy to Clipboard Toggle word wrap

  2. 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
    Copy to Clipboard Toggle word wrap

    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.
    Copy to Clipboard Toggle word wrap

1.2.4.3. Replacing root CA certificates
Copia collegamento

  1. 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
    Copy to Clipboard Toggle word wrap

  2. Edit the CA issuer to point to the BYO certificate. Run the following commnad: 

    oc edit issuer -n open-cluster-management multicloud-ca-issuer
    Copy to Clipboard Toggle word wrap
  3. Replace the string mulicloud-ca-cert with byo-ca-cert. Save your deployment and quit the editor.

  4. Edit the management ingress deployment to reference the Bring Your Own (BYO) CA certificate. Run the following command: 

    oc edit deployment management-ingress-435ab
    Copy to Clipboard Toggle word wrap
  5. Replace the multicloud-ca-cert string with the byo-ca-cert. Save your deployment and quit the editor.
  6. 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
Copia collegamento

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}')
Copy to Clipboard Toggle word wrap

1.2.4.5. Restoring root CA certificates
Copia collegamento

To restore the root CA certificate, update the CA issuer by completing the following steps:

  1. Edit the CA issuer. Run the following command: 

    oc edit issuer -n open-cluster-management multicloud-ca-issuer
    Copy to Clipboard Toggle word wrap
  2. Replace the byo-ca-cert string with multicloud-ca-cert in the editor. Save the issuer and quit the editor.

  3. Edit the management ingress depolyment to reference the original CA certificate. Run the following command: 

    oc edit deployment management-ingress-435ab
    Copy to Clipboard Toggle word wrap
  4. Replace the byo-ca-cert string with the multicloud-ca-cert string. Save your deployment and quit the editor.

  5. Delete the BYO CA certificate. Run the following commnad: 

    oc delete secret -n open-cluster-management byo-ca-cert
    Copy to Clipboard Toggle word wrap

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
Copia collegamento

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
Copia collegamento

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
      Copy to Clipboard Toggle word wrap

      You might receieve the following response: 

      multicloud-console.apps.grchub2.dev08.red-chesterfield.com
      Copy to Clipboard Toggle word wrap
    • 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
Copia collegamento

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.
Copy to Clipboard Toggle word wrap

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
Copia collegamento

The following OpenSSL commands are used with the preceding configuration file to generate the required TLS certificate.

  1. Generate your certificate authority (CA) RSA private key: 

    openssl genrsa -out ca.key 4096
    Copy to Clipboard Toggle word wrap

  2. 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
    Copy to Clipboard Toggle word wrap

  3. Generate the RSA private key for your certificate: 

    openssl genrsa -out ingress.key 4096
    Copy to Clipboard Toggle word wrap

  4. Generate the Certificate Signing request (CSR) by using the private key: 

    openssl req -new -key ingress.key -out ingress.csr -config csr.cnf
    Copy to Clipboard Toggle word wrap

  5. 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
    Copy to Clipboard Toggle word wrap

  6. Examine the certificate contents: 

    openssl x509  -noout -text -in ./ingress.crt
    Copy to Clipboard Toggle word wrap

1.2.5.2. Replace the Bring Your Own (BYO) ingress certificate
Copia collegamento

Complete the following steps to replace your BYO ingress certificate:

  1. 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
    Copy to Clipboard Toggle word wrap

  2. Verify that the secret is created in the correct namespace. 

    kubectl get secret -n open-cluster-management | grep byo-ingress | grep tls
    Copy to Clipboard Toggle word wrap

  3. 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
    Copy to Clipboard Toggle word wrap

  4. 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
    Copy to Clipboard Toggle word wrap
    • 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.
  5. 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
Copia collegamento

  1. 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
    Copy to Clipboard Toggle word wrap
    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.
  2. 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.

  3. 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
    Copy to Clipboard Toggle word wrap

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.

Torna in cima
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2025 Red Hat