Questo contenuto non è disponibile nella lingua selezionata.
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
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
applabel that contains one of the values ofcentral,central-db,scanner, orscanner-db. - CA certificates are not updated. They are valid for 5 years.
- The service certificates in the init bundles used by secured cluster components are not updated. You must rotate the init bundles at regular intervals.
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
writepermission for theServiceIdentityresource.
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>
- Restart Central to apply the changes.
3.1.1. Restarting the Central container
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
Or, run the following command to delete the Central pod:
$ oc -n stackrox delete pod -lapp=central
3.2. Reissuing internal certificates for Scanner
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
writepermission for theServiceIdentityresource.
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>
- Restart Scanner to apply the changes.
3.2.1. Restarting the Scanner and Scanner DB containers
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
On Kubernetes:
$ kubectl delete pod -n stackrox -l app=scanner; kubectl -n stackrox delete pod -l app=scanner-db
3.3. Reissuing internal certificates for Sensor, Collector, and Admission controller
Sensor, Collector, and Admission controller use certificates to communicate with each other, and with Central.
To replace the certificates, use one of the following methods:
-
Create, download, and install an init bundle on the secured cluster. You must have the
Adminuser role to create an init bundle. -
Use the automatic upgrades functionality. Automatic upgrades are available only for static manifest deployments using the
roxctlCLI.
3.3.1. Reissuing internal certificates for Secured Clusters using init bundles
Secured clusters contain the Collector, Sensor, and Admission Control components. These components use a built-in server certificate for authentication when communicating with other Red Hat Advanced Cluster Security for Kubernetes 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
-
To reissue certificates, you must have
writepermission for theServiceIdentityresource.
Store this bundle securely because it contains secrets. You can use the same bundle on multiple secured clusters. You must have the Admin user role to create init bundles.
Procedure
To generate an init bundle using the RHACS portal:
-
Select Platform Configuration
Clusters. - Click Manage Tokens.
- Go to the Authentication Tokens section, and click Cluster Init Bundle.
- Click Generate bundle.
- Enter a name for the cluster init bundle and click Generate.
- To download the generated bundle, click Download Kubernetes secrets file.
-
Select Platform Configuration
To generate an init bundle using the
roxctlCLI, run the following command:$ roxctl -e <endpoint> -p <admin_password> central \ init-bundles generate --output-secrets <bundle_name> \ init-bundle.yaml
Next steps
To create the necessary resources on each secured cluster, run the following command:
$ oc -n stackrox apply -f <init-bundle.yaml>
3.3.2. Reissuing internal certificates for secured clusters by using automatic upgrades
You can reissue internal certificates for Sensor, Collector, and Admission controller by using automatic upgrades.
Automatic upgrades are only applicable to static manifest-based deployments using the roxctl CLI. See "Installing Central" in the "Installing by using the roxctl CLI" section of the Installing chapter.
Prerequisites
- You must have enabled automatic upgrades for all clusters.
-
To reissue certificates, you must have
writepermission for theServiceIdentityresource.
Procedure
-
In the RHACS portal, go to Platform Configuration
Clusters. - In the Clusters view, select a Cluster to view its details.
- From the cluster details panel, select the link to Apply credentials by using an automatic upgrade.
When you apply an automatic upgrade, Red Hat Advanced Cluster Security for Kubernetes creates new credentials in the selected cluster. However, you will still see a notification. The notification goes away when each Red Hat Advanced Cluster Security for Kubernetes service begins using the new credentials after the service restarts.
