Upgrading
Upgrading Red Hat Advanced Cluster Security for Kubernetes
Abstract
Chapter 1. Upgrading by using the Operator
Upgrades through the Red Hat Advanced Cluster Security for Kubernetes (RHACS) Operator are performed automatically or manually, depending on the Update approval option you chose at installation.
Follow these guidelines when upgrading:
- If the version for Central is earlier than 3.74, you must upgrade to 3.74 before upgrading to a 4.x version. For upgrading Central to version 3.74, see the upgrade documentation for version 3.74.
-
When upgrading Operator-based Central deployments from version 3.74, first ensure the Operator upgrade mode is set to
Manual. Then, upgrade the Operator to version 4.0 following the procedure in the upgrade documentation for version 4.0 and ensure that Central is online. After the upgrade to version 4.0 is complete, Red Hat recommends upgrading Central to the latest version for full functionality.
1.1. Preparing to upgrade
Before you upgrade the Red Hat Advanced Cluster Security for Kubernetes (RHACS) version, you must perform the following steps:
- Verify that you are running the latest patch release version of the RHACS Operator 3.74.
- Backup your existing Central database.
-
If the cluster you are upgrading contains the
SecuredClustercustom resource (CR), change the collection method to EBPF or CORE_BPF. For more information, see "Changing the collection method".
1.1.1. Changing the collection method to EBPF or CORE_BPF
If the cluster that you are upgrading contains the SecuredCluster CR, you must ensure that the per node collection setting is not set to KernelModule. If collection is set to KernelModule, then change it to EBPF or CORE_BPF. CORE_BPF is available in release 4.1 and later. EBPF is the preferred value for collection, unless there is a specific reason to use CORE_BPF.
Procedure
- In the OpenShift Container Platform web console, go to the RHACS Operator page.
- In the top navigation menu, select Secured Cluster.
- Click the instance name, for example, stackrox-secured-cluster-services.
Use one of the following methods:
- In the Form view, under Per Node Settings → Collector Settings → Collection, select EBPF or CORE_BPF.
-
Click YAML to open the YAML editor and locate the
spec.perNode.collector.collectionattribute. If the value isKernelModule, then change it toEBPForCORE_BPF.
- Click Save.
Additional resources
1.2. Modifying Central custom resource
The Central DB service requires persistent storage. If you have not configured a default storage class for the Central cluster that is an SSD or is high performance, you must update the Central custom resource to configure the storage class for the Central DB persistent volume claim (PVC).
Skip this section if you have already configured a default storage class for Central.
Procedure
- Update the central custom resource with the following configuration:
spec:
central:
db:
isEnabled: Default 1
persistence:
persistentVolumeClaim: 2
claimName: central-db
size: 100Gi
storageClassName: <storage-class-name>1.3. Modifying Central custom resource for external database
External PostgreSQL support is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
Prerequisites
You must have a database in your database instance that supports PostgreSQL 13 and a user with the following permissions:
- Connection rights to the database.
-
UsageandCreateon the schema. -
Select,Insert,Update, andDeleteon all tables in the schema. -
Usageon all sequences in the schema.
Procedure
Create a password secret in the deployed namespace by using the OpenShift Container Platform web console or the terminal.
-
On the OpenShift Container Platform web console, go to the Workloads → Secrets page. Create a Key/Value secret with the key
passwordand the value as the path of a plain text file containing the password for the superuser of the provisioned database. Or, run the following command in your terminal:
$ oc create secret generic external-db-password \ 1 --from-file=password=<password.txt> 2
-
On the OpenShift Container Platform web console, go to the Workloads → Secrets page. Create a Key/Value secret with the key
- Go to the Red Hat Advanced Cluster Security for Kubernetes operator page in the OpenShift Container Platform web console. Select Central in the top navigation bar and select the instance you want to connect to the database.
- Go to the YAML editor view.
-
For
db.passwordSecret.namespecify the referenced secret that you created in earlier steps. For example,external-db-password. -
For
db.connectionStringspecify the connection string inkeyword=valueformat, for example,host=<host> port=5432 database=stackrox user=stackrox sslmode=verify-ca -
For
db.persistencedelete the entire block. If necessary, you can specify a Certificate Authority for Central to trust the database certificate by adding a TLS block under the top-level spec, as shown in the following example:
Update the central custom resource with the following configuration:
spec: tls: additionalCAs: - name: db-ca content: | <certificate> central: db: isEnabled: Default 1 connectionString: "host=<host> port=5432 user=<user> sslmode=verify-ca" passwordSecret: name: external-db-password- 1
- You must not change the value of
IsEnabledtoEnabled.
- Click Save.
Additional resources
1.4. Changing subscription channel
You can change the update channel for the RHACS Operator by using the OpenShift Container Platform web console or by using the command line. For upgrading to RHACS 4.0 from RHACS 3.74, you must change the update channel.
You must change the subscription channel for all clusters where you have installed RHACS Operator, including Central and all Secured clusters.
Prerequisites
- You must verify that you are using the latest RHACS 3.74 Operator and there are no pending manual Operator upgrades.
- You must verify that you have backed up your existing Central database.
-
You have access to an OpenShift Container Platform cluster web console using an account with
cluster-adminpermissions.
Changing the subscription channel by using the web console
Use the following instructions for changing the subscription channel by using the web console:
Procedure
- In the Administrator perspective of the OpenShift Container Platform web console, go to Operators → Installed Operators.
- Locate the RHACS Operator and click on it.
- Click the Subscription tab.
- Click the name of the update channel under Update Channel.
- Select stable, then click Save.
For subscriptions with an Automatic approval strategy, the update begins automatically. Navigate back to the Operators → Installed Operators page to monitor the progress of the update. When complete, the status changes to Succeeded and Up to date.
For subscriptions with a Manual approval strategy, you can manually approve the update from the Subscription tab.
Changing the subscription channel by using command line
Use the following instructions for changing the subscription channel by using command line:
Procedure
Run the following command to change the subscription channel to
stable:$ oc -n rhacs-operator \ 1 patch subscriptions.operators.coreos.com rhacs-operator \ --type=merge --patch='{ "spec": { "channel": "stable" }}'- 1
- If you use Kubernetes, enter
kubectlinstead ofoc.
During the update the RHACS Operator provisions a new deployment called central-db and your data begins migrating. It takes around 30 minutes and only happens once when you upgrade.
1.5. Removing Central-attached PV after upgrading to version 4.1 and later
Kubernetes and OpenShift Container Platform do not delete persistent volumes (PV) automatically. When you upgrade RHACS from earlier versions, the Central PV called stackrox-db remains mounted. However, in RHACS 4.1, Central does not need the previously attached PV anymore.
The PV has data and persistent files used by earlier RHACS versions. You can use the PV to roll back to an earlier version before RHACS 4.1. Or, if you have a large RocksDB backup bundle for Central, you can use the PV to restore that data.
After you complete the upgrade to 4.1, you can remove the Central-attached persistent volume claim (PVC) to free up the storage. Only remove the PVC if you do not plan to roll back or restore from earlier RocksDB backups.
After removing PVC, you cannot roll back Central to an earlier version before RHACS 4.1 or restore large RocksDB backups created with RocksDB.
1.5.1. Removing Central-attached PV using the RHACS Operator for RHACS version 4.1 and later
Remove the Central-attached persistent volume claim (PVC) stackrox-db to free up storage space.
Procedure
Add the following annotation to Central:
annotations: platform.stackrox.io/obsolete-central-pvc: "true"
Verification
Run the following command:
$ oc -n stackrox describe pvc stackrox-db | grep -i 'Used By' Used By: <none> 1- 1
- Wait until you see
Used By: <none>. It might take a few minutes.
1.6. Rolling back an Operator upgrade
To roll back an Operator upgrade, you must perform the steps described in one of the following sections. You can roll back an Operator upgrade by using the CLI or the OpenShift Container Platform web console.
If you are rolling back from RHACS 4.0, you can only rollback to the latest patch release version of RHACS 3.74.
1.6.1. Rolling back an Operator upgrade by using the CLI
You can roll back the Operator version by using CLI commands.
Procedure
Delete the OLM subscription by running the following command:
For OpenShift Container Platform, run the following command:
$ oc -n rhacs-operator delete subscription rhacs-operator
For Kubernetes, run the following command:
$ kubectl -n rhacs-operator delete subscription rhacs-operator
Delete the cluster service version (CSV) by running the following command:
For OpenShift Container Platform, run the following command:
$ oc -n rhacs-operator delete csv -l operators.coreos.com/rhacs-operator.rhacs-operator
For Kubernetes, run the following command:
$ kubectl -n rhacs-operator delete csv -l operators.coreos.com/rhacs-operator.rhacs-operator
Determine the previous version you want to roll back to by choosing one of the following options:
If the current Central instance is running, query the RHACS API to get the rollback version by running the following command:
$ curl -k -s -u <user>:<password> https://<central hostname>/v1/centralhealth/upgradestatus | jq -r .upgradeStatus.forceRollbackTo
If the current Central instance is not running, perform the following steps:
NoteThis procedure can only be used for RHACS release 3.74 and earlier when the
rocksdbdatabase is installed.Ensure the Central deployment is scaled down by running the following command:
For OpenShift Container Platform, run the following command:
$ oc scale -n <central namespace> –replicas=0 deploy/central
For Kubernetes, run the following command:
$ kubectl scale -n <central namespace> –replicas=0 deploy/central
Save the following pod spec as a YAML file:
apiVersion: v1 kind: Pod metadata: name: get-previous-db-version spec: containers: - name: get-previous-db-version image: registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:<rollback version> command: - sh args: - '-c' - "cat /var/lib/stackrox/.previous/migration_version.yaml | grep '^image:' | cut -f 2 -d : | tr -d ' '" volumeMounts: - name: stackrox-db mountPath: /var/lib/stackrox volumes: - name: stackrox-db persistentVolumeClaim: claimName: stackrox-dbCreate a pod in your Central namespace by running the following command using the YAML file that you saved:
For OpenShift Container Platform, run the following command:
$ oc create -n <central namespace> -f pod.yaml
For Kubernetes, run the following command:
$ kubectl create -n <central namespace> -f pod.yaml
After pod creation is complete, get the version by running the following command:
For OpenShift Container Platform, run the following command:
$ oc logs -n <central namespace> get-previous-db-version
For Kubernetes, run the following command:
$ kubectl logs -n <central namespace> get-previous-db-version
Edit the
central-config.yamlConfigMapto set themaintenance.forceRollBackVersion:<version>parameter by running the following command:For OpenShift Container Platform, run the following command:
$ oc get configmap -n <central namespace> central-config -o yaml | sed -e "s/forceRollbackVersion: none/forceRollbackVersion: <version>/" | oc -n <central namespace> apply -f -
For Kubernetes, run the following command:
$ kubectl get configmap -n <central namespace> central-config -o yaml | sed -e "s/forceRollbackVersion: none/forceRollbackVersion: <version>/" | kubectl -n <central namespace> apply -f -
Set the image for the Central deployment using the version string shown in Step 3 as the image tag. For example, run the following command:
For OpenShift Container Platform, run the following command:
$ oc set image -n <central namespace> deploy/central central=registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:<version>
For Kubernetes, run the following command:
$ kubectl set image -n <central namespace> deploy/central central=registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:<version>
Verification
Ensure that the Central pod starts and has a
readystatus. If the pod crashes, check the logs to see if the backup was restored. A successful log message appears similar to the following example:Clone to Migrate ".previous", ""
-
Reinstall the Operator on the rolled back channel. For example,
3.74.2is installed on therhacs-3.74channel.
1.6.2. Rolling back an Operator upgrade by using the web console
You can roll back the Operator version by using the OpenShift Container Platform web console.
Prerequisites
-
You have access to an OpenShift Container Platform cluster web console using an account with
cluster-adminpermissions.
Procedure
- Navigate to the Operators → Installed Operators page.
- Locate the RHACS Operator and click on it.
- On the Operator Details page, select Uninstall Operator from the Actions list. Following this action, the Operator stops running and no longer receives updates.
Determine the previous version you want to roll back to by choosing one of the following options:
If the current Central instance is running, you can query the RHACS API to get the rollback version by running the following command from a terminal window:
$ curl -k -s -u <user>:<password> https://<central hostname>/v1/centralhealth/upgradestatus | jq -r .upgradeStatus.forceRollbackTo
You can create a pod and extract the previous version by performing the following steps:
NoteThis procedure can only be used for RHACS release 3.74 and earlier when the
rocksdbdatabase is installed.- Navigate to Workloads → Deployments → central.
- Under Deployment details, click the down arrow next to the pod count to scale down the pod.
Navigate to Workloads → Pods → Create Pod and paste the contents of the pod spec as shown in the following example into the editor:
apiVersion: v1 kind: Pod metadata: name: get-previous-db-version spec: containers: - name: get-previous-db-version image: registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:<rollback version> command: - sh args: - '-c' - "cat /var/lib/stackrox/.previous/migration_version.yaml | grep '^image:' | cut -f 2 -d : | tr -d ' '" volumeMounts: - name: stackrox-db mountPath: /var/lib/stackrox volumes: - name: stackrox-db persistentVolumeClaim: claimName: stackrox-db- Click Create.
- After the pod is created, click the Logs tab to get the version string.
Update the rollback configuration by performing the following steps:
- Navigate to Workloads → ConfigMaps → central-config and select Edit ConfigMap from the Actions list.
-
Find the
forceRollbackVersionline in the value of thecentral-config.yamlkey. -
Replace
nonewith3.73.3, and then save the file.
Update Central to the earlier version by performing the following steps:
- Navigate to Workloads → Deployments → central and select Edit Deployment from the Actions list.
- Update the image name, and then save the changes.
Verification
Ensure that the Central pod starts and has a
readystatus. If the pod crashes, check the logs to see if the backup was restored. A successful log message appears similar to the following example:Clone to Migrate ".previous", ""
-
Reinstall the Operator on the rolled back channel. For example,
3.74.2is installed on therhacs-3.74channel.
1.7. Troubleshooting Operator upgrade issues
Follow these instructions to investigate and resolve upgrade-related issues for the RHACS Operator.
1.7.1. Central DB cannot be scheduled
Follow the instructions here to troubleshoot a failing Central DB pod during an upgrade:
Check the status of the
central-dbpod:$ oc -n <namespace> get pod -l app=central-db 1- 1
- If you use Kubernetes, enter
kubectlinstead ofoc.
If the status of the pod is
Pending, use the describe command to get more details:$ oc -n <namespace> describe po/<central-db-pod-name> 1- 1
- If you use Kubernetes, enter
kubectlinstead ofoc.
You might see the
FailedSchedulingwarning message:Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 54s default-scheduler 0/7 nodes are available: 1 Insufficient memory, 3 node(s) had untolerated taint {node-role.kubernetes.io/master: }, 4 Insufficient cpu. preemption: 0/7 nodes are available: 3 Preemption is not helpful for scheduling, 4 No preemption victims found for incoming pod.This warning message suggests that the scheduled node had insufficient memory to accommodate the pod’s resource requirements. If you have a small environment, consider increasing resources on the nodes or adding a larger node that can support the database.
Otherwise, consider decreasing the resource requirements for the
central-dbpod in the custom resource undercentral→db→resources. However, running central with fewer resources than the recommended minimum might lead to degraded performance for RHACS.
1.7.2. Central or Secured cluster fails to deploy
When RHACS Operator:
- fails to deploy Central or Secured Cluster.
- fails to apply CR changes to actual resources.
You must check the custom resource conditions to find the issue.
For Central, run the following command to check the conditions:
$ oc -n rhacs-operator describe centrals.platform.stackrox.io 1- 1
- If you use Kubernetes, enter
kubectlinstead ofoc.
For Secured clusters, run the following command to check the conditions:
$ oc -n rhacs-operator describe securedclusters.platform.stackrox.io 1- 1
- If you use Kubernetes, enter
kubectlinstead ofoc.
You can identify configuration errors from the conditions output:
Example output
Conditions:
Last Transition Time: 2023-04-19T10:49:57Z
Status: False
Type: Deployed
Last Transition Time: 2023-04-19T10:49:57Z
Status: True
Type: Initialized
Last Transition Time: 2023-04-19T10:59:10Z
Message: Deployment.apps "central" is invalid: spec.template.spec.containers[0].resources.requests: Invalid value: "50": must be less than or equal to cpu limit
Reason: ReconcileError
Status: True
Type: Irreconcilable
Last Transition Time: 2023-04-19T10:49:57Z
Message: No proxy configuration is desired
Reason: NoProxyConfig
Status: False
Type: ProxyConfigFailed
Last Transition Time: 2023-04-19T10:49:57Z
Message: Deployment.apps "central" is invalid: spec.template.spec.containers[0].resources.requests: Invalid value: "50": must be less than or equal to cpu limit
Reason: InstallError
Status: True
Type: ReleaseFailedAdditionally, you can view RHACS pod logs to find more information about the issue. Run the following command to view the logs:
oc -n rhacs-operator logs deploy/rhacs-operator-controller-manager manager 1- 1
- If you use Kubernetes, enter
kubectlinstead ofoc.
Chapter 2. Upgrading using Helm charts
You must follow a specific upgrade path for RHACS depending on the release of RHACS that you are running. You must also back up your Central database before updating the Helm chart and peforming the upgrade.
2.1. Upgrade sequence from RHACS release 3.74 and earlier
When upgrading from earlier releases, follow this guidance:
- If the release for Central is earlier than 3.74, you must upgrade to the latest 3.74 patch before upgrading to a 4.x release. See the upgrade documentation for version 3.74 for information about upgrades from earlier versions to 3.74.
- When upgrading Helm-based installations from release 3.74, you can upgrade to any latest patch of RHACS version 4.0 through 4.4. However, for full functionality, upgrade to release 4.4.
If you have installed RHACS by using Helm charts, to upgrade to the latest version of RHACS perform the following steps:
- Back up the Central database.
- Optionally, optimize Central’s database and Persistent Volume Claims (PVC).
-
Optionally, generate a
values-private.yamlconfiguration file containing root certificates for the central-services Helm chart. - Update the Helm chart.
-
Run the
helm upgradecommand.
To ensure optimal functionality, use the same version for your secured-cluster-services Helm chart and central-services Helm chart.
2.2. Backing up the Central database
You can back up the Central database and use that backup for rolling back from a failed upgrade or data restoration in the case of an infrastructure disaster.
Prerequisites
-
You must have an API token with
readpermission for all resources of Red Hat Advanced Cluster Security for Kubernetes. The Analyst system role hasreadpermissions for all resources. -
You have installed the
roxctlCLI. -
You have configured the
ROX_API_TOKENand theROX_CENTRAL_ADDRESSenvironment variables.
Procedure
Run the backup command:
$ roxctl -e "$ROX_CENTRAL_ADDRESS" central backup
Additional resources
2.3. Optimizing Central database and PVC
When you upgrade to Red Hat Advanced Cluster Security for Kubernetes (RHACS) 4.0, RHACS creates a PostgreSQL instance called central-db with a default Persistent Volume Claims (PVC). Optionally, you can customize central-db or PVC configuration.
Red Hat recommends the following minimum memory and CPU requests:
central:
db:
resources:
requests:
memory: 16Gi
cpu: 8
limits:
memory: 16Gi
cpu: 82.4. Generating root certificates file
If you do not have access to your values-private.yaml configuration file that you have used to install Red Hat Advanced Cluster Security for Kubernetes (RHACS), use the following instruction to generate the values-private.yaml configuration file containing root certificates.
Skip the instruction here, if you have access to your values-private.yaml configuration file.
The generated values-private.yaml file has sensitive configuration options. Ensure that you store this file securely.
Procedure
-
Download the Content from raw.githubusercontent.com is not included.
create_certificate_values_file.shscript. Make the
create_certificate_values_file.shscript executable:$ chmod +x create_certificate_values_file.sh
Run the
create_certificate_values_file.shscript file:$ create_certificate_values_file.sh values-private.yaml
2.5. Updating the Helm chart repository
You must always update Helm charts before upgrading to a new version of Red Hat Advanced Cluster Security for Kubernetes.
Prerequisites
- You must have already added the Red Hat Advanced Cluster Security for Kubernetes Helm chart repository.
- You must be using Helm version 3.8.3 or newer.
Procedure
Update Red Hat Advanced Cluster Security for Kubernetes charts repository.
$ helm repo update
Verification
Run the following command to verify the added chart repository:
$ helm search repo -l rhacs/
2.6. Additional resources
2.7. Running the Helm upgrade command
You can use the helm upgrade command to update Red Hat Advanced Cluster Security for Kubernetes (RHACS).
Prerequisites
-
You must have access to the
values-private.yamlconfiguration file that you have used to install Red Hat Advanced Cluster Security for Kubernetes (RHACS). Otherwise, you must generate thevalues-private.yamlconfiguration file containg root certificates, before proceeding with the commands here.
Procedure
Run the helm upgrade command and specify the configuration files by using the
-foption:$ helm upgrade -n stackrox stackrox-central-services \ rhacs/central-services --version <current-rhacs-version> \ 1 -f values-private.yaml \ --set central.db.password.generate=true \ --set central.db.serviceTLS.generate=true \ --set central.db.persistence.persistentVolumeClaim.createClaim=trueNoteYou might use the
--reuse-valuesoption to preserve the previously configured Helm values during the upgrade. If you do that, you must turn off central-db creation before you upgrade to the next version. For example,$ helm upgrade -n stackrox stackrox-central-services \ rhacs/central-services --version <current-rhacs-version> --reuse-values \ -f values-private.yaml \ --set central.db.password.generate=false \ --set central.db.serviceTLS.generate=false \ --set central.db.persistence.persistentVolumeClaim.createClaim=false
2.8. Removing Central-attached PV after upgrading to version 4.1 and later
Kubernetes and OpenShift Container Platform do not delete persistent volumes (PV) automatically. When you upgrade RHACS from earlier versions, the Central PV called stackrox-db remains mounted. However, in RHACS 4.1, Central does not need the previously attached PV anymore.
The PV has data and persistent files used by earlier RHACS versions. You can use the PV to roll back to an earlier version before RHACS 4.1. Or, if you have a large RocksDB backup bundle for Central, you can use the PV to restore that data.
After you complete the upgrade to 4.1, you can remove the Central-attached persistent volume claim (PVC) to free up the storage. Only remove the PVC if you do not plan to roll back or restore from earlier RocksDB backups.
After removing PVC, you cannot roll back Central to an earlier version before RHACS 4.1 or restore large RocksDB backups created with RocksDB.
2.8.1. Removing Central-attached PV using Helm
Remove the Central-attached persistent volume claim (PVC) stackrox-db to free up storage space.
Procedure
Run the following command:
$ helm upgrade -n stackrox stackrox-central-services \ rhacs/central-services --version <current-rhacs-version> \ --set central.persistence.none=true
2.9. Rolling back an Helm upgrade
You can roll back to a previous version of Central if the upgrade to a new version is unsuccessful.
Procedure
Run the following
helm upgradecommand:$ helm upgrade -n stackrox \ stackrox-central-services rhacs/central-services \ --version <previous_rhacs_74_version> \ 1 --set central.db.enabled=false- 1
- Replace
<previous_rhacs_74_version>with the previously installed RHACS version.
Delete the
central-dbpersistent volume claim (PVC):$ oc -n stackrox delete pvc central-db 1- 1
- If you use Kubernetes, enter
kubectlinstead ofoc.
Chapter 3. Manually upgrading using the roxctl CLI
You can upgrade to the latest version of Red Hat Advanced Cluster Security for Kubernetes (RHACS) from a supported older version.
-
You need to perform the manual upgrade procedure only if you used the
roxctlCLI to install RHACS. - There are manual steps for each version upgrade that must be followed, for example, from version 3.74 to version 4.0, and from version 4.0 to version 4.1. Therefore, Red Hat recommends upgrading first from 3.74 to 4.0, then from 4.0 to 4.1, then 4.1 to 4.2, until the selected version is installed. For full functionality, Red Hat recommends upgrading to the most recent version.
To upgrade Red Hat Advanced Cluster Security for Kubernetes to the latest version, you must perform the following:
- Backup the Central database
-
Upgrade the
roxctlCLI - Generate Central database provisioning bundle
- Upgrade Central
- Upgrade Scanner
- Verify all the upgraded secured clusters
3.1. Backing up the Central database
You can back up the Central database and use that backup for rolling back from a failed upgrade or data restoration in the case of an infrastructure disaster.
Prerequisites
-
You must have an API token with
readpermission for all resources of Red Hat Advanced Cluster Security for Kubernetes. The Analyst system role hasreadpermissions for all resources. -
You have installed the
roxctlCLI. -
You have configured the
ROX_API_TOKENand theROX_CENTRAL_ADDRESSenvironment variables.
Procedure
Run the backup command:
$ roxctl -e "$ROX_CENTRAL_ADDRESS" central backup
Additional resources
3.2. Upgrading the roxctl CLI
To upgrade the roxctl CLI to the latest version you must uninstall the existing version of roxctl CLI and then install the latest version of the roxctl CLI.
3.2.1. Uninstalling the roxctl CLI
You can uninstall the roxctl CLI binary on Linux by using the following procedure.
Procedure
Find and delete the
roxctlbinary:$ ROXPATH=$(which roxctl) && rm -f $ROXPATH 1- 1
- Depending on your environment, you might need administrator rights to delete the
roxctlbinary.
3.2.2. Installing the roxctl CLI on Linux
You can install the roxctl CLI binary on Linux by using the following procedure.
roxctl CLI for Linux is available for amd64, ppc64le, and s390x architectures.
Procedure
Determine the
roxctlarchitecture for the target operating system:$ arch="$(uname -m | sed "s/x86_64//")"; arch="${arch:+-$arch}"Download the
roxctlCLI:$ curl -f -o roxctl "https://mirror.openshift.com/pub/rhacs/assets/4.3.8/bin/Linux/roxctl${arch}"Make the
roxctlbinary executable:$ chmod +x roxctl
Place the
roxctlbinary in a directory that is on yourPATH:To check your
PATH, execute the following command:$ echo $PATH
Verification
Verify the
roxctlversion you have installed:$ roxctl version
3.2.3. Installing the roxctl CLI on macOS
You can install the roxctl CLI binary on macOS by using the following procedure.
roxctl CLI for macOS is available for the amd64 architecture.
Procedure
Download the
roxctlCLI:$ curl -f -O https://mirror.openshift.com/pub/rhacs/assets/4.3.8/bin/Darwin/roxctl
Remove all extended attributes from the binary:
$ xattr -c roxctl
Make the
roxctlbinary executable:$ chmod +x roxctl
Place the
roxctlbinary in a directory that is on yourPATH:To check your
PATH, execute the following command:$ echo $PATH
Verification
Verify the
roxctlversion you have installed:$ roxctl version
3.2.4. Installing the roxctl CLI on Windows
You can install the roxctl CLI binary on Windows by using the following procedure.
roxctl CLI for Windows is available for the amd64 architecture.
Procedure
Download the
roxctlCLI:$ curl -f -O https://mirror.openshift.com/pub/rhacs/assets/4.3.8/bin/Windows/roxctl.exe
Verification
Verify the
roxctlversion you have installed:$ roxctl version
3.3. Generating Central database provisioning bundle
Before upgrading Central you must first generate a database provisioning bundle. This bundle is a tar archive that has a README file, a few YAML configuration files, and some scripts that aid in the installation process.
Prerequisites
-
You must have an API token with the
Adminrole. -
You must have installed the
roxctlCLI.
Procedure
Set the
ROX_API_TOKENand theROX_CENTRAL_ADDRESSenvironment variables:$ export ROX_API_TOKEN=<api_token>
$ export ROX_CENTRAL_ADDRESS=<address>:<port_number>
Run the
central db generatecommand:$ roxctl -e $ROX_CENTRAL_ADDRESS central db generate \ <cluster_type> \ 1 <storage> \ 2 --output-dir <bundle_dir> \ 3 --central-db-image registry.redhat.io/advanced-cluster-security/rhacs-central-db-rhel8:4.3.8
- 1
cluster-typeis the type of your cluster, specifyk8sfor Kubernetes andopenshiftfor OpenShift Container Platform.- 2
- For
storage, specifyhostpathorpvc. If you usepvcyou can use additional options to specify volume name, size, and storage class. Run$ roxctl central db generate openshift pvc -hfor more details. - 3
- For
bundle-dirspecify the path where you want to save the generated provisioning bundle.
Next Step
- Use the Central DB provisioning bundle to create additional resources.
3.4. Creating resources by using the Central DB provisioning bundle
Before you upgrade the Central cluster, you must use the Central DB provisioning bundle to create additional resources that the Central cluster requires. This bundle is a tar archive that has a README file, a few YAML configuration files, and some scripts that aid in the installation process.
Prerequisites
- You must have generated a Central DB provisioning bundle.
-
You must have extracted the
tararchive bundle.
Procedure
Open the extracted bundle directory and run the
setupscript:$ ./scripts/setup.sh
Run the
deploy-central-dbscript:$ ./deploy-central-db.sh
3.5. Upgrading the Central cluster
After you have created a backup of the Central database and generated the necessary resources by using the provisioning bundle, the next step is to upgrade the Central cluster. This process involves upgrading Central and Scanner.
3.5.1. Upgrading Central
You can update Central to the latest version by downloading and deploying the updated images.
Procedure
Run the following command to update the Central image:
$ oc -n stackrox set image deploy/central central=registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:4.3.8 1- 1
- If you use Kubernetes, enter
kubectlinstead ofoc.
Verification
Verify that the new pods have deployed:
$ oc get deploy -n stackrox -o wide
$ oc get pod -n stackrox --watch
3.5.2. Upgrading Scanner
You can update Scanner to the latest version by downloading and deploying the updated images.
Procedure
Run the following command to update the Scanner image:
$ oc -n stackrox set image deploy/scanner scanner=registry.redhat.io/advanced-cluster-security/rhacs-scanner-rhel8:4.3.8 1- 1
- If you use Kubernetes, enter
kubectlinstead ofoc.
Verification
Verify that the new pods have deployed:
$ oc get deploy -n stackrox -o wide
$ oc get pod -n stackrox --watch
3.5.3. Verifying the Central cluster upgrade
After you have upgraded both Central and Scanner, verify that the Central cluster upgrade is complete.
Procedure
Check the Central logs by running the following command:
$ oc logs -n stackrox deploy/central -c central 1- 1
- If you use Kubernetes, enter
kubectlinstead ofoc.
Sample output of a successful upgrade
No database restore directory found (this is not an error).
Migrator: 2023/04/19 17:58:54: starting DB compaction
Migrator: 2023/04/19 17:58:54: Free fraction of 0.0391 (40960/1048576) is < 0.7500. Will not compact
badger 2023/04/19 17:58:54 INFO: All 1 tables opened in 2ms
badger 2023/04/19 17:58:55 INFO: Replaying file id: 0 at offset: 846357
badger 2023/04/19 17:58:55 INFO: Replay took: 50.324µs
badger 2023/04/19 17:58:55 DEBUG: Value log discard stats empty
Migrator: 2023/04/19 17:58:55: DB is up to date. Nothing to do here.
badger 2023/04/19 17:58:55 INFO: Got compaction priority: {level:0 score:1.73 dropPrefix:[]}
version: 2023/04/19 17:58:55.189866 ensure.go:49: Info: Version found in the DB was current. We’re good to go!3.6. Upgrading all secured clusters
After upgrading Central services, you must upgrade all secured clusters.
If you are using automatic upgrades:
- Update all your secured clusters by using automatic upgrades.
- Skip the instructions in this section and follow the instructions in the Verify upgrades and Revoking the API token sections.
If you are not using automatic upgrades, you must run the instructions in this section on all secured clusters including the Central cluster.
- To ensure optimal functionality, use the same RHACS version for your secured clusters and the cluster on which Central is installed.
To complete manual upgrades of each secured cluster running Sensor, Collector, and Admission controller, follow the instructions in this section.
3.6.1. Updating other images
You must update the sensor, collector and compliance images on each secured cluster when not using automatic upgrades.
If you are using Kubernetes, use kubectl instead of oc for the commands listed in this procedure.
Procedure
Update the Sensor image:
$ oc -n stackrox set image deploy/sensor sensor=registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:4.3.8 1- 1
- If you use Kubernetes, enter
kubectlinstead ofoc.
Update the Compliance image:
$ oc -n stackrox set image ds/collector compliance=registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:4.3.8 1- 1
- If you use Kubernetes, enter
kubectlinstead ofoc.
Update the Collector image:
$ oc -n stackrox set image ds/collector collector=registry.redhat.io/advanced-cluster-security/rhacs-collector-rhel8:4.3.8 1- 1
- If you use Kubernetes, enter
kubectlinstead ofoc.
NoteIf you are using the collector slim image, run the following command instead:
$ oc -n stackrox set image ds/collector collector=registry.redhat.io/advanced-cluster-security/rhacs-collector-slim-rhel8:{rhacs-version}Update the admission control image:
$ oc -n stackrox set image deploy/admission-control admission-control=registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:4.3.8
3.6.2. Verifying secured cluster upgrade
After you have upgraded secured clusters, verify that the updated pods are working.
3.6.3. Enabling RHCOS node scanning
If you use OpenShift Container Platform, you can enable scanning of Red Hat Enterprise Linux CoreOS (RHCOS) nodes for vulnerabilities by using Red Hat Advanced Cluster Security for Kubernetes (RHACS).
Prerequisites
- For scanning RHCOS node hosts of the Secured cluster, you must have installed Secured cluster on OpenShift Container Platform 4.11 or later. For more information on supported managed and self-managed OpenShift Container Platform versions, see Red Hat Advanced Cluster Security for Kubernetes Support Policy.
Procedure
Run one of the following commands to update the compliance container.
For a default compliance container with metrics disabled, run the following command:
$ oc -n stackrox patch daemonset/collector -p '{"spec":{"template":{"spec":{"containers":[{"name":"compliance","env":[{"name":"ROX_METRICS_PORT","value":"disabled"},{"name":"ROX_NODE_SCANNING_ENDPOINT","value":"127.0.0.1:8444"},{"name":"ROX_NODE_SCANNING_INTERVAL","value":"4h"},{"name":"ROX_NODE_SCANNING_INTERVAL_DEVIATION","value":"24m"},{"name":"ROX_NODE_SCANNING_MAX_INITIAL_WAIT","value":"5m"},{"name":"ROX_RHCOS_NODE_SCANNING","value":"true"},{"name":"ROX_CALL_NODE_INVENTORY_ENABLED","value":"true"}]}]}}}}'For a compliance container with Prometheus metrics enabled, run the following command:
$ oc -n stackrox patch daemonset/collector -p '{"spec":{"template":{"spec":{"containers":[{"name":"compliance","env":[{"name":"ROX_METRICS_PORT","value":":9091"},{"name":"ROX_NODE_SCANNING_ENDPOINT","value":"127.0.0.1:8444"},{"name":"ROX_NODE_SCANNING_INTERVAL","value":"4h"},{"name":"ROX_NODE_SCANNING_INTERVAL_DEVIATION","value":"24m"},{"name":"ROX_NODE_SCANNING_MAX_INITIAL_WAIT","value":"5m"},{"name":"ROX_RHCOS_NODE_SCANNING","value":"true"},{"name":"ROX_CALL_NODE_INVENTORY_ENABLED","value":"true"}]}]}}}}'
Update the Collector DaemonSet (DS) by taking the following steps:
Add new volume mounts to Collector DS by running the following command:
$ oc -n stackrox patch daemonset/collector -p '{"spec":{"template":{"spec":{"volumes":[{"name":"tmp-volume","emptyDir":{}},{"name":"cache-volume","emptyDir":{"sizeLimit":"200Mi"}}]}}}}'Add the new
NodeScannercontainer by running the following command:$ oc -n stackrox patch daemonset/collector -p '{"spec":{"template":{"spec":{"containers":[{"command":["/scanner","--nodeinventory","--config=",""],"env":[{"name":"ROX_NODE_NAME","valueFrom":{"fieldRef":{"apiVersion":"v1","fieldPath":"spec.nodeName"}}},{"name":"ROX_CLAIR_V4_SCANNING","value":"true"},{"name":"ROX_COMPLIANCE_OPERATOR_INTEGRATION","value":"true"},{"name":"ROX_CSV_EXPORT","value":"false"},{"name":"ROX_DECLARATIVE_CONFIGURATION","value":"false"},{"name":"ROX_INTEGRATIONS_AS_CONFIG","value":"false"},{"name":"ROX_NETPOL_FIELDS","value":"true"},{"name":"ROX_NETWORK_DETECTION_BASELINE_SIMULATION","value":"true"},{"name":"ROX_NETWORK_GRAPH_PATTERNFLY","value":"true"},{"name":"ROX_NODE_SCANNING_CACHE_TIME","value":"3h36m"},{"name":"ROX_NODE_SCANNING_INITIAL_BACKOFF","value":"30s"},{"name":"ROX_NODE_SCANNING_MAX_BACKOFF","value":"5m"},{"name":"ROX_PROCESSES_LISTENING_ON_PORT","value":"false"},{"name":"ROX_QUAY_ROBOT_ACCOUNTS","value":"true"},{"name":"ROX_ROXCTL_NETPOL_GENERATE","value":"true"},{"name":"ROX_SOURCED_AUTOGENERATED_INTEGRATIONS","value":"false"},{"name":"ROX_SYSLOG_EXTRA_FIELDS","value":"true"},{"name":"ROX_SYSTEM_HEALTH_PF","value":"false"},{"name":"ROX_VULN_MGMT_WORKLOAD_CVES","value":"false"}],"image":"registry.redhat.io/advanced-cluster-security/rhacs-scanner-slim-rhel8:4.3.8","imagePullPolicy":"IfNotPresent","name":"node-inventory","ports":[{"containerPort":8444,"name":"grpc","protocol":"TCP"}],"volumeMounts":[{"mountPath":"/host","name":"host-root-ro","readOnly":true},{"mountPath":"/tmp/","name":"tmp-volume"},{"mountPath":"/cache","name":"cache-volume"}]}]}}}}'
Additional resources
3.7. Removing Central-attached PV after upgrading to version 4.1 and later
Kubernetes and OpenShift Container Platform do not delete persistent volumes (PV) automatically. When you upgrade RHACS from earlier versions, the Central PV called stackrox-db remains mounted. However, in RHACS 4.1, Central does not need the previously attached PV anymore.
The PV has data and persistent files used by earlier RHACS versions. You can use the PV to roll back to an earlier version before RHACS 4.1. Or, if you have a large RocksDB backup bundle for Central, you can use the PV to restore that data.
After you complete the upgrade to 4.1, you can remove the Central-attached persistent volume claim (PVC) to free up the storage. Only remove the PVC if you do not plan to roll back or restore from earlier RocksDB backups.
After removing PVC, you cannot roll back Central to an earlier version before RHACS 4.1 or restore large RocksDB backups created with RocksDB.
3.7.1. Removing Central-attached PV using the roxctl CLI
Remove the Central-attached persistent volume claim (PVC) stackrox-db to free up storage space.
Procedure
Run the following command:
$ oc get deployment central -n stackrox -o json | jq '(.spec.template.spec.volumes[] | select(.name=="stackrox-db"))={"name": "stackrox-db", "emptyDir": {}}' | oc apply -f -It replaces the
stackrox-db`entry in thespec.template.spec.volumesto a local emptyDir.
Verification
Run the following command:
$ oc -n stackrox describe pvc stackrox-db | grep -i 'Used By' Used By: <none> 1- 1
- Wait until you see
Used By: <none>. It might take a few minutes.
3.8. Rolling back Central
You can roll back to a previous version of Central if the upgrade to a new version is unsuccessful.
3.8.1. Rolling back Central normally
You can roll back to a previous version of Central if upgrading Red Hat Advanced Cluster Security for Kubernetes fails.
Prerequisites
- Before you can perform a rollback, you must have free disk space available on your persistent storage. Red Hat Advanced Cluster Security for Kubernetes uses disk space to keep a copy of databases during the upgrade. If the disk space is not enough to store a copy and the upgrade fails, you might not be able to roll back to an earlier version.
Procedure
Run the following command to roll back to a previous version when an upgrade fails (before the Central service starts):
$ oc -n stackrox rollout undo deploy/central 1- 1
- If you use Kubernetes, enter
kubectlinstead ofoc.
3.8.2. Rolling back Central forcefully
You can use forced rollback to roll back to an earlier version of Central (after the Central service starts).
Using forced rollback to switch back to a previous version might result in loss of data and functionality.
Prerequisites
- Before you can perform a rollback, you must have free disk space available on your persistent storage. Red Hat Advanced Cluster Security for Kubernetes uses disk space to keep a copy of databases during the upgrade. If the disk space is not enough to store a copy and the upgrade fails, you will not be able to roll back to an earlier version.
Procedure
Run the following commands to perform a forced rollback:
To forcefully rollback to the previously installed version:
$ oc -n stackrox rollout undo deploy/central 1- 1
- If you use Kubernetes, enter
kubectlinstead ofoc.
To forcefully rollback to a specific version:
Edit Central’s
ConfigMap:$ oc -n stackrox edit configmap/central-config 1- 1
- If you use Kubernetes, enter
kubectlinstead ofoc.
Update the value of the
maintenance.forceRollbackVersionkey:data: central-config.yaml: | maintenance: safeMode: false compaction: enabled: true bucketFillFraction: .5 freeFractionThreshold: 0.75 forceRollbackVersion: <x.x.x.x> 1 ...- 1
- Specify the version that you want to roll back to.
Update the Central image version:
$ oc -n stackrox \ 1 set image deploy/central central=registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:<x.x.x.x> 2
3.9. Verifying upgrades
The updated Sensors and Collectors continue to report the latest data from each secured cluster.
The last time Sensor contacted Central is visible in the RHACS portal.
Procedure
- On the RHACS portal, navigate to Platform Configuration → System Health.
- Check to ensure that Sensor Upgrade shows clusters up to date with Central.
3.10. Revoking the API token
For security reasons, Red Hat recommends that you revoke the API token that you have used to complete Central database backup.
Prerequisites
- After the upgrade, you must reload the RHACS portal page and re-accept the certificate to continue using the RHACS portal.
Procedure
- On the RHACS portal, navigate to Platform Configuration → Integrations.
- Scroll down to the Authentication Tokens category, and click API Token.
- Select the checkbox in front of the token name that you want to revoke.
- Click Revoke.
- On the confirmation dialog box, click Confirm.