Chapter 2. Manually upgrading using the roxctl CLI

Prerequisites

• If you deploy images from a private image registry, first push the new image into your private registry, and then replace your image registry for the commands in this section.

Procedure

• Run the following commands to upgrade Central:

  $ oc -n stackrox patch deploy/central -p '{"spec":{"template":{"spec":{"containers":[{"name":"central","env":[{"name":"ROX_NAMESPACE","valueFrom":{"fieldRef":{"fieldPath":"metadata.namespace"}}}]}]}}}}' 1

  1

  If you use Kubernetes, enter kubectl instead of oc.

  $ oc -n stackrox patch deployment/scanner -p '{"spec":{"template":{"spec":{"containers":[{"name":"scanner","securityContext":{"runAsUser":65534}}]}}}}' 1

  1

  If you use Kubernetes, enter kubectl instead of oc.

  $ oc -n stackrox set image deploy/central central=registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:3.71.3 1

  1

  If you use Kubernetes, enter kubectl instead of oc.

  Important

  • If you are upgrading from Red Hat Advanced Cluster Security for Kubernetes 3.65.0, you must run the following additional command to create the stackrox-central-diagnostics role:

    $ oc -n stackrox patch role stackrox-central-diagnostics -p '{"rules":[{"apiGroups":["*"],"resources":["deployments","daemonsets","replicasets","configmaps","services"],"verbs":["get","list"]}]}' 1

    1

    If you use Kubernetes, enter kubectl instead of oc.

  • If you have not installed Red Hat Advanced Cluster Security for Kubernetes by using Helm or Operator, and you want to enable authentication using the OpenShift OAuth server, you must run the following additional command:

    $ oc -n stackrox set env deploy/central ROX_ENABLE_OPENSHIFT_AUTH=true

    $ oc -n stackrox patch serviceaccount/central -p '
    {
    "metadata": {
    "annotations": {
    "serviceaccounts.openshift.io/oauth-redirecturi.main": "sso/providers/openshift/callback",
    "serviceaccounts.openshift.io/oauth-redirectreference.main": "{"kind":"OAuthRedirectReference","apiVersion":"v1","reference":{"kind":"Route","name":"central"}}"
    }
    }
    }'

Verification

• Check that the new pods have deployed:

  $ oc get deploy -n stackrox -o wide 1

  1

  If you use Kubernetes, enter kubectl instead of oc.

  $ oc get pod -n stackrox --watch 1

  1

  If you use Kubernetes, enter kubectl instead of oc.

Prerequisites

• If you deploy images from a private image registry, you must first push the new image into your private registry, then edit the commands in the following section to use the name of your private image registry.

Verification

• Check that the new pods have deployed successfully:

  • If you use OpenShift Container Platform, enter the following command:

    $ oc get pod -n stackrox --watch

  • If you use Kubernetes, enter the following command:

    $ kubectl get pod -n stackrox --watch

Procedure

• Check the Central logs:

  If you are using OpenShift Container Platform, enter the following command:

  $ oc logs -n stackrox deploy/central -c central

  If you are using Kubernetes, enter the following command:

  $ kubectl logs -n stackrox deploy/central -c central

Procedure

• Update the readiness probe path:

  $ oc -n stackrox patch deploy/sensor -p '{"spec":{"template":{"spec":{"containers":[{"name":"sensor","readinessProbe":{"httpGet":{"path":"/ready"}}}]}}}}' 1

  1

  If you use Kubernetes, enter kubectl instead of oc.

Procedure

• Red Hat Advanced Cluster Security for Kubernetes 3.64.0 renames the SCCs. If you are upgrading from a version below Red Hat Advanced Cluster Security for Kubernetes 3.64.0, you must delete and reapply the SCCs, otherwise, skip this step:

  1. Run the following commands to update Central:

     $ oc apply -f - <<EOF
     kind: SecurityContextConstraints
     apiVersion: security.openshift.io/v1
     metadata:
       name: stackrox-central
       labels:
         app.kubernetes.io/name: stackrox
       annotations:
         kubernetes.io/description: stackrox-central is the security constraint for the central server
         email: support@stackrox.com
         owner: stackrox
     allowHostDirVolumePlugin: false
     allowedCapabilities: []
     allowHostIPC: false
     allowHostNetwork: false
     allowHostPID: false
     allowHostPorts: false
     allowPrivilegeEscalation: false
     allowPrivilegedContainer: false
     defaultAddCapabilities: []
     fsGroup:
       type: MustRunAs
       ranges:
         - max: 4000
           min: 4000
     priority: 0
     readOnlyRootFilesystem: true
     requiredDropCapabilities: []
     runAsUser:
       type: MustRunAs
       uid: 4000
     seLinuxContext:
       type: MustRunAs
     seccompProfiles:
       - '*'
     users:
       - system:serviceaccount:stackrox:central
     volumes:
       - '*'
     EOF

     $ oc delete scc central

  2. Run the following commands to update Scanner:

     $ oc apply -f - <<EOF
     kind: SecurityContextConstraints
     apiVersion: security.openshift.io/v1
     metadata:
       name: stackrox-scanner
       labels:
         app.kubernetes.io/name: stackrox
       annotations:
         email: support@stackrox.com
         owner: stackrox
         kubernetes.io/description: stackrox-scanner is the security constraint for the Scanner container
     priority: 0
     runAsUser:
       type: RunAsAny
     seLinuxContext:
       type: RunAsAny
     seccompProfiles:
       - '*'
     users:
       - system:serviceaccount:stackrox:scanner
     volumes:
       - '*'
     allowHostDirVolumePlugin: false
     allowedCapabilities: []
     allowHostIPC: false
     allowHostNetwork: false
     allowHostPID: false
     allowHostPorts: false
     allowPrivilegeEscalation: false
     allowPrivilegedContainer: false
     defaultAddCapabilities: []
     fsGroup:
       type: RunAsAny
     readOnlyRootFilesystem: false
     requiredDropCapabilities: []
     EOF

     $ oc delete scc scanner

  3. Run the following commands on each OpenShift Secured Cluster:

     $ oc apply -f - <<EOF
     apiVersion: security.openshift.io/v1
     kind: SecurityContextConstraints
     metadata:
       name: stackrox-admission-control
       labels:
         app.kubernetes.io/name: stackrox
         auto-upgrade.stackrox.io/component: "sensor"
       annotations:
         email: support@stackrox.com
         owner: stackrox
         kubernetes.io/description: stackrox-admission-control is the security constraint for the admission controller
     users:
       - system:serviceaccount:stackrox:admission-control
     priority: 0
     runAsUser:
       type: RunAsAny
     seLinuxContext:
       type: RunAsAny
     seccompProfiles:
       - '*'
     supplementalGroups:
       type: RunAsAny
     fsGroup:
       type: RunAsAny
     groups: []
     readOnlyRootFilesystem: true
     allowHostDirVolumePlugin: false
     allowHostIPC: false
     allowHostNetwork: false
     allowHostPID: false
     allowHostPorts: false
     allowPrivilegeEscalation: false
     allowPrivilegedContainer: false
     allowedCapabilities: []
     defaultAddCapabilities: []
     requiredDropCapabilities: []
     volumes:
       - configMap
       - downwardAPI
       - emptyDir
       - secret
     ---
     apiVersion: security.openshift.io/v1
     kind: SecurityContextConstraints
     metadata:
       name: stackrox-collector
       labels:
         app.kubernetes.io/name: stackrox
         auto-upgrade.stackrox.io/component: "sensor"
       annotations:
         email: support@stackrox.com
         owner: stackrox
         kubernetes.io/description: This SCC is based on privileged, hostaccess, and hostmount-anyuid
     users:
       - system:serviceaccount:stackrox:collector
     allowHostDirVolumePlugin: true
     allowPrivilegedContainer: true
     fsGroup:
       type: RunAsAny
     groups: []
     priority: 0
     readOnlyRootFilesystem: true
     runAsUser:
       type: RunAsAny
     seLinuxContext:
       type: RunAsAny
     seccompProfiles:
       - '*'
     supplementalGroups:
       type: RunAsAny
     allowHostIPC: false
     allowHostNetwork: false
     allowHostPID: false
     allowHostPorts: false
     allowPrivilegeEscalation: true
     allowedCapabilities: []
     defaultAddCapabilities: []
     requiredDropCapabilities: []
     volumes:
       - configMap
       - downwardAPI
       - emptyDir
       - hostPath
       - secret
     ---
     apiVersion: security.openshift.io/v1
     kind: SecurityContextConstraints
     metadata:
       name: stackrox-sensor
       labels:
         app.kubernetes.io/name: stackrox
         auto-upgrade.stackrox.io/component: "sensor"
       annotations:
         email: support@stackrox.com
         owner: stackrox
         kubernetes.io/description: stackrox-sensor is the security constraint for the sensor
     users:
       - system:serviceaccount:stackrox:sensor
       - system:serviceaccount:stackrox:sensor-upgrader
     priority: 0
     runAsUser:
       type: RunAsAny
     seLinuxContext:
       type: RunAsAny
     seccompProfiles:
       - '*'
     supplementalGroups:
       type: RunAsAny
     fsGroup:
       type: RunAsAny
     groups: []
     readOnlyRootFilesystem: true
     allowHostDirVolumePlugin: false
     allowHostIPC: false
     allowHostNetwork: false
     allowHostPID: false
     allowHostPorts: false
     allowPrivilegeEscalation: true
     allowPrivilegedContainer: false
     allowedCapabilities: []
     defaultAddCapabilities: []
     requiredDropCapabilities: []
     volumes:
       - configMap
       - downwardAPI
       - emptyDir
       - secret
     EOF

     $ oc delete scc admission-control collector sensor

Procedure

• Check that the new pods have deployed:

  $ oc get deploy,ds -n stackrox -o wide 1

  1

  If you use Kubernetes, enter kubectl instead of oc.

  $ oc get pod -n stackrox --watch 1

  1

  If you use Kubernetes, enter kubectl instead of oc.

Prerequisites

• You must be using Red Hat Advanced Cluster Security for Kubernetes 3.0.57.0 or higher.
• 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 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 kubectl instead of oc.

Prerequisites

• You must be using Red Hat Advanced Cluster Security for Kubernetes 3.0.58.0 or higher.
• 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 kubectl instead of oc.

  • To forcefully rollback to a specific version:

    1. Edit Central’s ConfigMap:

       $ oc -n stackrox edit configmap/central-config 1

       1

       If you use Kubernetes, enter kubectl instead of oc.

    2. Update the value of the maintenance.forceRollbackVersion key:

       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.

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

       1

       If you use Kubernetes, enter kubectl instead of oc.

       2

       Specify the version that you want to roll back to. It must be the same version that you specified for the maintenance.forceRollbackVersion key in the central-config config map.