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, complete the following steps:

  • If you are upgrading from version 3.74, 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 SecuredCluster custom resource (CR), change the collection method to CORE_BPF. For more information, see "Changing the collection method".

1.1.1. Changing the collection method

If the cluster that you are upgrading contains the SecuredCluster CR, you must ensure that the per node collection setting is set to CORE_BPF before you upgrade.

Procedure

  1. In the OpenShift Container Platform web console, go to the RHACS Operator page.
  2. In the top navigation menu, select Secured Cluster.
  3. Click the instance name, for example, stackrox-secured-cluster-services.
  4. Use one of the following methods to change the setting:

    • In the Form view, under Per Node Settings Collector Settings Collection, select CORE_BPF.
    • Click YAML to open the YAML editor and locate the spec.perNode.collector.collection attribute. If the value is KernelModule or EBPF, then change it to CORE_BPF.
  5. Click Save.

1.2. Modifying the 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 reinstall and configure the Central custom resource (CR) with the storage class for the Central DB persistent volume claim (PVC).

When changing the storageClassName, because of limitations with the Kubernetes storage layer, you cannot modify a claim’s storage class after it is bound; therefore, you must re-create the Central CR.

Note

Skip this section if you have already configured a default storage class for Central.

Procedure

  1. Back up and uninstall the Central instance.
  2. Reinstall RHACS and configure the Central custom resource as shown in the following example:

    spec:
      central:
        db:
          isEnabled: Default 
    1
    
          persistence:
            persistentVolumeClaim: 
    2
    
              claimName: central-db
              size: 100Gi
              storageClassName: <storage-class-name>
    Copy to Clipboard Toggle word wrap
    1
    You must not change the value of IsEnabled to Enabled.
    2
    If this claim exists, your cluster uses the existing claim; otherwise, it creates a new claim.
  3. Restore the Central database backup by using the roxctl CLI.

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.
    • Usage and Create on the schema.
    • Select, Insert, Update, and Delete on all tables in the schema.
    • Usage on all sequences in the schema.

Procedure

  1. 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 password and 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
      Copy to Clipboard Toggle word wrap
      1
      If you use Kubernetes, enter kubectl instead of oc.
      2
      Replace password.txt with the path of the file which has the plain text password.
  2. 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.
  3. Go to the YAML editor view.
  4. For db.passwordSecret.name specify the referenced secret that you created in earlier steps. For example, external-db-password.
  5. For db.connectionString specify the connection string in keyword=value format, for example, host=<host> port=5432 database=stackrox user=stackrox sslmode=verify-ca
  6. For db.persistence delete the entire block.
  7. 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
      Copy to Clipboard Toggle word wrap
      1
      You must not change the value of IsEnabled to Enabled.
  8. Click Save.

1.4. Changing the 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.

Important

You must change the subscription channel for all clusters where you installed the 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 backed up your Central database.
  • You have access to an OpenShift Container Platform cluster web console using an account with cluster-admin permissions.

Use the following instructions for changing the subscription channel by using the web console:

Procedure

  1. In the Administrator perspective of the OpenShift Container Platform web console, go to Operators Installed Operators.
  2. Click the RHACS Operator.
  3. Click the Subscription tab.
  4. Click the name of the update channel under Update Channel.
  5. Select stable, then click Save.
  6. For subscriptions with an Automatic approval strategy, the update begins automatically. Go 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.

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" }}'
    Copy to Clipboard Toggle word wrap
    1
    If you use Kubernetes, enter kubectl instead of oc.

During the update, the RHACS Operator provisions a new deployment called central-db and your data begins migrating. It takes around 30 minutes and happens only after you upgrade.

1.5. 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.

Note

If you are rolling back from RHACS 4.0, you can only roll back to the latest patch release version of RHACS 3.74.

You can roll back the Operator version by using command-line interface (CLI) commands.

Procedure

  1. Delete the Operator Lifecycle Manager (OLM) subscription and cluster service version (CSV):

    Important

    If you use Kubernetes, enter kubectl instead of oc.

    1. To delete the OLM subscription, run the following command:

      $ oc -n rhacs-operator delete subscription rhacs-operator
      Copy to Clipboard Toggle word wrap

      Example output

      subscription.operators.coreos.com "rhacs-operator" deleted
      Copy to Clipboard Toggle word wrap

    2. To delete the CSV, run the following command:

      $ oc -n rhacs-operator delete csv -l operators.coreos.com/rhacs-operator.rhacs-operator
      Copy to Clipboard Toggle word wrap

      Example output

      clusterserviceversion.operators.coreos.com "rhacs-operator.v4.8.4" deleted
      Copy to Clipboard Toggle word wrap

  2. Install the previous version of the RHACS Operator:

    1. In the OpenShift web console, click OperatorHub.
    2. Search for Advanced Cluster Security for Kubernetes.
    3. Select and install the previous version of the Operator.

      Note

      Installing the previous Operator version rolls back RHACS to the same version as the Operator.

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-admin permissions.

Procedure

  1. In the OpenShift web console, click Operators Installed Operators.
  2. From the list of projects, select rhacs-operator.
  3. Locate the Advanced Cluster Security for Kubernetes Operator:

    1. Click the overflow menu kebab Uninstall Operator.

      The uninstall Operator dialog is displayed.

    2. Ensure that the Delete all operand instances for this operator checkbox is clear to avoid uninstallation of Red Hat Advanced Cluster Security for Kubernetes (RHACS).
    3. Click Uninstall.
  4. Install the previous version of RHACS Operator:

    1. In the OpenShift web console, click OperatorHub.
    2. Search for Advanced Cluster Security for Kubernetes.
    3. Select and install the previous version of the Operator.

      Note

      Installing the previous Operator version rolls back RHACS to the same version as the Operator.

1.6. Troubleshooting Operator upgrade issues

Follow these instructions to investigate and resolve upgrade-related issues for the RHACS Operator.

1.6.1. Central DB cannot be scheduled

Follow the instructions here to troubleshoot a failing Central DB pod during an upgrade:

  1. Check the status of the central-db pod:

    $ oc -n <namespace> get pod -l app=central-db 
    1
    Copy to Clipboard Toggle word wrap
    1
    If you use Kubernetes, enter kubectl instead of oc.
  2. 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
    Copy to Clipboard Toggle word wrap
    1
    If you use Kubernetes, enter kubectl instead of oc.
  3. You might see the FailedScheduling warning 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.
    Copy to Clipboard Toggle word wrap
  4. 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-db pod in the custom resource under central db resources. However, running central with fewer resources than the recommended minimum might lead to degraded performance for RHACS.

1.6.2. Central or Secured cluster fails to deploy

When RHACS Operator has the following conditions, you must check the custom resource conditions to find the issue:

  • If the Operator fails to deploy Central or Secured Cluster
  • If the Operator fails to apply CR changes to actual resources
  • For Central, run the following command to check the conditions:

    $ oc -n rhacs-operator describe centrals.platform.stackrox.io 
    1
    Copy to Clipboard Toggle word wrap
    1
    If you use Kubernetes, enter kubectl instead of oc.
  • For Secured clusters, run the following command to check the conditions:

    $ oc -n rhacs-operator describe securedclusters.platform.stackrox.io 
    1
    Copy to Clipboard Toggle word wrap
    1
    If you use Kubernetes, enter kubectl instead of oc.

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

Additionally, 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
Copy to Clipboard Toggle word wrap
1
If you use Kubernetes, enter kubectl instead of oc.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat