Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

このコンテンツは選択した言語では利用できません。

Chapter 4. Reissuing internal certificates

Each component of Red Hat Advanced Cluster Security for Kubernetes uses an X.509 certificate to authenticate itself to other components. These certificates have expiration dates, and you must reissue, or rotate, certificates before they expire. You can view the certificate expiration dates by selecting Platform Configuration Clusters in the RHACS portal and viewing the Credential Expiration column.

4.1. Reissuing internal certificates for Central services
リンクのコピー

The Central services contain the Central, Central DB, Scanner, and Scanner V4 components. The Central services use a built-in server certificate for authentication when communicating with other Red Hat Advanced Cluster Security for Kubernetes (RHACS) services. This certificate is unique to your Central service installation. The RHACS portal shows an informational banner when a Central service certificate is about to expire.

Note

The informational banner only appears 15 days before the certificate expiration date.

Beginning with RHACS 4.3.4, the Operator automatically rotates the service transport layer security (TLS) certificates for all of the Central components 6 months before they expire.

Important
  • The automated rotation of the TLS certificates applies only to Operator-based installations. For all other installation methods, you must manually rotate the TLS certificates.
  • The rotation of the TLS certificates within the secrets does not automatically trigger the components to reload them. If the corresponding pods are not restarted at least every 6 months, you must manually restart the pods to load the new certificates before the old ones expire.
  • Certificate authority (CA) certificates are not updated. They are valid for 5 years.

4.1.1. Reissuing internal certificates for Central
リンクのコピー

You can maintain a secure communication between Central and other Red Hat Advanced Cluster Security for Kubernetes (RHACS) components by reissuing the internal certificates.

Prerequisites

  • You have write permission for the Administration resource.

Procedure

  1. In the RHACS portal, click the link in the banner that announces the certificate expiration to download a YAML configuration file, which contains a new secret. The secret includes the certificate and key values.

  2. To apply the new YAML configuration file to the cluster where you have installed Central, run the following command: 

    $ oc apply -f <secret_file.yaml>
    Copy to Clipboard Toggle word wrap
  3. To apply the changes, restart Central.

4.1.1.1. Restarting the Central container
リンクのコピー

You can restart the Central container by deleting the Central pod.

Note

If you use Kubernetes, enter kubectl instead of oc.

Procedure

  • To delete the Central pod, run the following command: 

    $ oc -n stackrox delete pod -lapp=central
    Copy to Clipboard Toggle word wrap

4.1.2. Reissuing internal certificates for Central DB
リンクのコピー

You can maintain a secure communication between Central DB and other Red Hat Advanced Cluster Security for Kubernetes (RHACS) components by reissuing the internal certificates.

Prerequisites

  • You have write permission for the Administration resource.

Procedure

  1. In the RHACS portal, click the link in the banner that announces the certificate expiration to download a YAML configuration file, which contains a new secret. The secret includes the certificate and key values.

  2. To apply the new YAML configuration file to the cluster where you have installed Central DB, run the following command: 

    $ oc apply -f <secret_file.yaml>
    Copy to Clipboard Toggle word wrap
  3. To apply the changes, restart Central DB.

4.1.2.1. Restarting the Central DB container
リンクのコピー

You can restart the Central DB container by deleting the Central DB pod.

Note

If you use Kubernetes, enter kubectl instead of oc.

Procedure

  • To delete the Central DB pod, run the following command: 

    $ oc -n stackrox delete pod -lapp=central-db
    Copy to Clipboard Toggle word wrap

4.1.3. Reissuing internal certificates for Scanner
リンクのコピー

You can maintain a secure communication between Scanner and other Red Hat Advanced Cluster Security for Kubernetes (RHACS) components by reissuing the internal certificates.

Prerequisites

  • You have write permission for the Administration resource.

Procedure

  1. Click the link in the banner to download a YAML configuration file, which contains a new OpenShift Container Platform secret, including the certificate and key values.

  2. To apply the new YAML configuration file to the cluster where you have installed Scanner, run the following command: 

    $ oc apply -f <secret_file.yaml>
    Copy to Clipboard Toggle word wrap
  3. To apply the changes, restart Scanner.

4.1.3.1. Restarting the Scanner and Scanner DB containers
リンクのコピー

You can restart the Scanner and Scanner DB containers by deleting the pods.

Note

If you use Kubernetes, enter kubectl instead of oc.

Procedure

  • To delete the Scanner pods, run the following command: 

    $ oc delete pod -n stackrox -l app=scanner
    Copy to Clipboard Toggle word wrap

  • To delete the Scanner DB pods, run the following command: 

    $ oc -n stackrox delete pod -l app=scanner-db
    Copy to Clipboard Toggle word wrap

4.1.4. Reissuing internal certificates for Scanner V4
リンクのコピー

You can maintain a secure communication between Scanner V4 and other Red Hat Advanced Cluster Security for Kubernetes (RHACS) components by reissuing the internal certificates.

Prerequisites

  • You have write permission for the Administration resource.

Procedure

  1. Click the link in the banner to download a YAML configuration file, which contains a new OpenShift Container Platform secret, including the certificate and key values.

  2. To apply the new YAML configuration file to the cluster where you have installed Scanner V4, run the following command: 

    $ oc apply -f <secret_file.yaml>
    Copy to Clipboard Toggle word wrap
  3. To apply the changes, restart Scanner V4.

4.1.4.1. Restarting the Scanner V4 containers
リンクのコピー

You can restart the Scanner V4 Matcher, Indexer and DB containers by deleting their corresponding pods.

Note

If you use Kubernetes, enter kubectl instead of oc.

Procedure

  • To delete the Scanner V4 Matcher pod, run the following command: 

    $ oc delete pod -n stackrox -l app=scanner-v4-matcher
    Copy to Clipboard Toggle word wrap

  • To delete the Scanner V4 Indexer pod, run the following command: 

    $ oc delete pod -n stackrox -l app=scanner-v4-indexer
    Copy to Clipboard Toggle word wrap

  • To delete the Scanner V4 DB pod, run the following command: 

    $ oc delete pod -n stackrox -l app=scanner-v4-db
    Copy to Clipboard Toggle word wrap

4.2. Reissuing internal certificates for secured clusters
リンクのコピー

Secured clusters contain the Collector, Sensor, Admission Control, and local Scanner components. These components communicate with each other, and with Central by using certificates.

Choose the appropriate method to reissue the internal certificates:

  • Use the automatic certificate renewal feature. This is the recommended method for Operator and Helm deployments. It is the only supported method for installations if you used a cluster registration secret (CRS) to set up communication between Central and secured clusters.
  • Generate, download, and install an init bundle on the secured cluster. You must have the Admin user role to generate an init bundle. This method is only recommended for Operator and Helm deployments if the certificates have already expired and the secured cluster can no longer connect to Central.
  • Use the automatic upgrades feature, which is only available for static manifest deployments by using the roxctl CLI. This method is only recommended if you have a specific installation requirement that necessitates the use of this method.

4.2.1. Reissuing internal certificates for secured clusters by using automatic certificate renewal
リンクのコピー

Secured clusters contain the Collector, Sensor, Admission Control, and local Scanner components. You can reissue internal certificates for these components by using automatic certificate renewal.

TLS certificates are automatically renewed several months in advance but are only loaded when RHACS pods restart, for example, during an upgrade.

4.2.1.1. Verifying the status of automatic certificate renewal
リンクのコピー

By viewing the Clusters page, you can verify that the automatic certificate renewal is active.

Procedure

  1. In the RHACS portal, click Platform Configuration Clusters.
  2. Verify that Auto-refresh enabled appears in the Credential Expiration column.
Important

If a secured cluster displays a warning about soon-to-expire credentials even though auto-refresh is enabled, you must manually restart the pods of the affected cluster to apply the latest certificates and prevent downtime.

For more information, see "Applying the latest internal certificates".

4.2.1.2. Applying the latest internal certificates
リンクのコピー

By manually restarting the pods of the affected cluster, you can apply the latest certificates and prevent downtime.

Note

If you use Kubernetes, use kubectl instead of oc.

Prerequisites

  • You have write permission for the Administration resource.

Procedure

  • To manually restart the pods of the affected cluster, run the following command: 

    $ oc -n <namespace> delete pods --all
    Copy to Clipboard Toggle word wrap

    where:

    <namespace>
    Specifies the namespace where you installed the secured cluster. For example, stackrox.

4.2.2. Reissuing internal certificates for secured clusters by using init bundles
リンクのコピー

Secured clusters contain the Collector, Sensor, Admission Control, and local Scanner components. These components use a built-in server certificate for authentication when communicating with other Red Hat Advanced Cluster Security for Kubernetes (RHACS) components.

The RHACS portal shows an information banner when the Central certificate is about to expire.

Note

The information banner only appears 15 days before the certificate expiry date.

Prerequisites

  • You have write permission for the Administration resource.
  • You have the Admin user role to create init bundles.
Important

Store the init bundle securely because it contains secrets. You can use the same bundle to set up more than one secured cluster.

Procedure

  1. Generate an init bundle by using the RHACS portal or by using the roxctl CLI, and then apply the bundle to the secured cluster. For more information, see "Generating and applying a cluster registration secret or an init bundle for RHACS on Red Hat OpenShift" or "Generating and applying a cluster registration secret or an init bundle for RHACS on other platforms".

4.2.3. Reissuing internal certificates for secured clusters by using automatic upgrades
リンクのコピー

Secured clusters contain the Collector, Sensor, Admission Control, and local Scanner components. You can reissue internal certificates for these components by using automatic upgrades.

Important

Automatic upgrades are only applicable to static manifest-based deployments by using the roxctl CLI.

For more information, see "Install Central using the roxctl CLI".

Prerequisites

  • You have enabled automatic upgrades for all the clusters.
  • You have write permission for the Administration resource.

Procedure

  1. In the RHACS portal, click Platform Configuration Clusters.
  2. Select a cluster to view its details.

  3. From the cluster details panel, select the link to Apply credentials by using an automatic upgrade.

    Note

    When you apply an automatic upgrade, Red Hat Advanced Cluster Security for Kubernetes (RHACS) creates new credentials in the selected cluster. However, you continue to see a notification. The notification disappears when each RHACS service uses the new credentials after the service restarts.

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2026 Red Hatトップに戻る