OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history
×

Upgrading secured clusters in RHACS Cloud Service by using the Operator

Red Hat provides regular service updates for the components that it manages, including Central services. These service updates include upgrades to new versions of Red Hat Advanced Cluster Security Cloud Service.

You must regularly upgrade the version of RHACS on your secured clusters to ensure compatibility with RHACS Cloud Service.

Preparing to upgrade

Before you upgrade the Red Hat Advanced Cluster Security for Kubernetes (RHACS) version, complete the following steps:

  • 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".

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, if you are upgrading from 4.1 or later. Otherwise, set the collection method to EBPF. To set the collection method to EBPF, you must set the forceCollection parameter to true after the upgrade and make sure that the collection method is EBPF.

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, then change it to CORE_BPF.

      Only use EBPF if you are upgrading from a version earlier than 4.1 or if there is a specific reason to use it.

  5. Click Save.

Additional resources

Rolling back an Operator upgrade for secured clusters

To roll back an Operator upgrade, you can use either the CLI or the OpenShift Container Platform web console.

On secured clusters, rolling back Operator upgrades is needed only in rare cases, for example, if an issue exists with the secured cluster.

Rolling back an Operator upgrade by using the CLI

You can roll back the Operator version by using CLI commands.

Procedure

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

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

  3. Install the latest version of the Operator on the rolled back channel.

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

Procedure

  1. Go to the Operators → Installed Operators page.

  2. Click the RHACS Operator.

  3. On the Operator Details page, select Uninstall Operator from the Actions list. Following this action, the Operator stops running and no longer receives updates.

  4. Install the latest version of the Operator on the rolled back channel.

Additional resources

Troubleshooting Operator upgrade issues

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

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 Secured Cluster

  • If the Operator fails to apply CR changes to actual resources

  • 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 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

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)
1 If you use Kubernetes, enter kubectl instead of oc.