Chapter 3. 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
3.1. Reissuing internal certificates for Central Copy linkLink copied to clipboard!
Central uses a built-in server certificate for authentication when communicating with other Red Hat Advanced Cluster Security for Kubernetes services. This certificate is unique to your Central installation. The RHACS portal shows an information banner when the Central certificate is about to expire.
The information banner only appears 15 days before the certificate expiration date.
For Operator-based installations, beginning with RHACS version 4.3.4, the Operator will automatically rotate all Central components' service transport layer security (TLS) certificates 6 months before they expire. The following conditions apply:
-
The rotation of certificates in the secrets does not trigger the components to automatically reload them. However, reloads typically occur when the pod is replaced as part of an RHACS upgrade or as a result of node reboots. If neither of those events happens at least every 6 months, you must restart the pods before the old (in-memory) service certificates expire. For example, you can delete the pods with an
app
label that contains one of the values ofcentral
,central-db
,scanner
, orscanner-db
. - CA certificates are not updated. They are valid for 5 years.
For non-Operator based installations, you must manually rotate TLS certificates. Instructions for manually rotating certificates are included in the following section.
Prerequisites
-
To reissue, or rotate, certificates, you must have
write
permission for theAdministration
resource.
Procedure
- In the RHACS portal, click on 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.
Apply the new YAML configuration file to the cluster where you have installed Central by running the following command:
oc apply -f <secret_file.yaml>
$ oc apply -f <secret_file.yaml>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Restart Central to apply the changes.
3.1.1. Restarting the Central container Copy linkLink copied to clipboard!
You can restart the Central container by killing the Central container or by deleting the Central pod.
Procedure
Run the following command to kill the Central container:
NoteYou must wait for at least 1 minute, until OpenShift Container Platform propagates your changes and restarts the Central container.
oc -n stackrox exec deploy/central -c central -- kill 1
$ oc -n stackrox exec deploy/central -c central -- kill 1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Or, run the following command to delete the Central pod:
oc -n stackrox delete pod -lapp=central
$ oc -n stackrox delete pod -lapp=central
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2. Reissuing internal certificates for Scanner Copy linkLink copied to clipboard!
Scanner has a built-in certificate that it uses to communicate with Central.
The RHACS portal shows an information banner when the Scanner certificate is about to expire.
The information banner only appears 15 days before the certificate expiry date.
Prerequisites
-
To reissue certificates, you must have
write
permission for theAdministration
resource.
Procedure
- Click on 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.
Apply the new YAML configuration file to the cluster where you installed Scanner.
oc apply -f <secret_file.yaml>
$ oc apply -f <secret_file.yaml>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Restart Scanner to apply the changes.
3.2.1. Restarting the Scanner and Scanner DB containers Copy linkLink copied to clipboard!
You can restart the Scanner and Scanner DB container by deleting the pods.
Procedure
To delete the Scanner and Scanner DB pods, run the following command:
On OpenShift Container Platform:
oc delete pod -n stackrox -l app=scanner; oc -n stackrox delete pod -l app=scanner-db
$ oc delete pod -n stackrox -l app=scanner; oc -n stackrox delete pod -l app=scanner-db
Copy to Clipboard Copied! Toggle word wrap Toggle overflow On Kubernetes:
kubectl delete pod -n stackrox -l app=scanner; kubectl -n stackrox delete pod -l app=scanner-db
$ kubectl delete pod -n stackrox -l app=scanner; kubectl -n stackrox delete pod -l app=scanner-db
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3. Reissuing internal certificates for secured clusters Copy linkLink copied to clipboard!
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.
-
Create, download, and install an init bundle on the secured cluster. You must have the
Admin
user role to create 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.
3.3.1. Reissuing internal certificates for secured clusters by using automatic certificate renewal Copy linkLink copied to clipboard!
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.
3.3.1.1. Verifying the status of automatic certificate renewal Copy linkLink copied to clipboard!
By viewing the Clusters page, you can verify that the automatic certificate renewal is active.
Procedure
-
In the RHACS portal, click Platform Configuration
Clusters. - Verify that Auto-refresh enabled appears in the Credential Expiration column.
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".
3.3.1.2. Applying the latest internal certificates Copy linkLink copied to clipboard!
By manually restarting the pods of the affected cluster, you can apply the latest certificates and prevent downtime.
Prerequisites
-
You have
write
permission for theAdministration
resource.
Procedure
To manually restart the pods of the affected cluster, run the following command:
oc -n <namespace> delete pods --all
$ oc -n <namespace> delete pods --all
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- The namespace where you installed the secured cluster. For example,
stackrox
.If you use Kubernetes, use
kubectl
instead ofoc
.
3.3.2. Reissuing internal certificates for secured clusters by using init bundles Copy linkLink copied to clipboard!
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.
The information banner only appears 15 days before the certificate expiry date.
Prerequisites
-
You have
write
permission for theAdministration
resource. -
You have the
Admin
user role to create init bundles.
Store the init bundle securely because it contains secrets. You can use the same bundle on multiple secured clusters.
Procedure
Choose the appropriate method to generate an init bundle:
To generate an init bundle by using the user interface (UI), perform the following steps:
-
In the RHACS portal, click Platform Configuration
Clusters. - Click Init bundles.
- To create a new init bundle, click Create bundle.
- Enter a name for the cluster init bundle.
Choose the appropriate platform of the secured clusters:
The following values are associated with the platform of the secured clusters:
-
OpenShift
-
EKS
-
AKS
-
GKE
-
Choose the appropriate installation method for the secured cluster services from the drop-down list:
The following values are associated with the installation method for the secured cluster services:
-
Operator (recommended)
-
Helm chart
-
Click Download.
ImportantYou can only download the YAML file once when you create an init bundle. Store the YAML file securely because it contains secrets.
-
In the RHACS portal, click Platform Configuration
To generate an init bundle by using the
roxctl
CLI, run the following command:roxctl -e <endpoint> -p <admin_password> central \ init-bundles generate --output-secrets <bundle_name> \ init-bundle.yaml
$ roxctl -e <endpoint> -p <admin_password> central \ init-bundles generate --output-secrets <bundle_name> \ init-bundle.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
To create the necessary resources on each secured cluster, run the following command:
oc -n stackrox apply -f <init-bundle.yaml>
$ oc -n stackrox apply -f <init-bundle.yaml>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3.3. Reissuing internal certificates for secured clusters by using automatic upgrades Copy linkLink copied to clipboard!
Secured clusters contain the Collector, Sensor, Admission Control, and local Scanner components. You can reissue internal certificates for these components by using automatic upgrades.
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 theAdministration
resource.
Procedure
-
In the RHACS portal, click Platform Configuration
Clusters. - Select a cluster to view its details.
From the cluster details panel, select the link to Apply credentials by using an automatic upgrade.
NoteWhen 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.