アップグレード

Red Hat Advanced Cluster Security for Kubernetes 3.71

Red Hat Advanced Cluster Security for Kubernetes のアップグレード

Red Hat OpenShift Documentation Team

概要

このセクションでは、Helm チャートまたは roxctl コマンドラインインターフェイスを使用して、Red Hat Advanced Cluster Security for Kubernetes をアップグレードする手順を説明します。

第1章 Helm チャートを使用したアップグレード

Helm チャートを使用して Red Hat Advanced Cluster Security for Kubernetes をインストールしていて、Red Hat Advanced Cluster Security for Kubernetes の最新バージョンにアップグレードするには、次の手順を実行する必要があります。

  • Helm チャートを更新します。
  • central-services Helm チャートの設定ファイルを更新します。
  • central-services Helm チャートをアップグレードします。
  • secured-cluster-services Helm チャートの設定ファイルを更新します。
  • secured-cluster-services Helm チャートをアップグレードします。
重要

最適な機能を確保するには、secure-cluster-services Helm チャートと central-services Helm チャートに同じバージョンを使用してください。

1.1. Helm チャートリポジトリーの更新

Red Hat Advanced Cluster Security for Kubernetes の新しいバージョンにアップグレードする前に、常に Helm チャートを更新する必要があります。

前提条件

  • Red Hat Advanced Cluster Security for Kubernetes の Helm チャートリポジトリーをすでに追加している必要がある。

手順

  • Red Hat Advanced Cluster Security for Kubernetes チャートリポジトリーを追加します。

    $ helm repo update

検証

  • 次のコマンドを実行して、追加されたチャートリポジトリーを確認します。

    $ helm search repo -l rhacs/

1.2. 関連情報

1.3. central-services Helm チャートをデプロイした後の設定オプションの変更

central-services Helm チャートをデプロイした後、任意の設定オプションに変更を加えることができます。

手順

  1. values-public.yaml および values-private.yaml 設定ファイルを新しい値で更新します。
  2. helm upgrade コマンドを実行し、-f オプションを使用して設定ファイルを指定します。

    $ helm upgrade -n stackrox \
      stackrox-central-services rhacs/central-services \
      -f <path_to_values_public.yaml> \
      -f <path_to_values_private.yaml>
    注記

    --set または --set-file パラメーターを使用して設定値を指定することもできます。ただし、これらのオプションは保存されないため、変更を加えるたびにすべてのオプションを手動で再度指定する必要があります。

1.4. secure-cluster-services Helm チャートをデプロイした後の設定オプションの変更

secure-cluster-services Helm チャートをデプロイした後、任意の設定オプションに変更を加えることができます。

手順

  1. values-public.yaml および values-private.yaml 設定ファイルを新しい値で更新します。
  2. helm upgrade コマンドを実行し、-f オプションを使用して設定ファイルを指定します。

    $ helm upgrade -n stackrox \
      stackrox-secured-cluster-services rhacs/secured-cluster-services \
      --reuse-values \ 1
      -f <path_to_values_public.yaml> \
      -f <path_to_values_private.yaml>
    1
    --reuse-values パラメーターを指定する必要があります。指定しない場合、Helm upgrade コマンドは以前に設定されたすべての設定をリセットします。
    注記

    --set または --set-file パラメーターを使用して設定値を指定することもできます。ただし、これらのオプションは保存されないため、変更を加えるたびにすべてのオプションを手動で再度指定する必要があります。

第2章 roxctl CLI を使用して手動でアップグレード

サポートされている古いバージョンから、Red Hat Advanced Cluster Security for Kubernetes の最新バージョンにアップグレードできます。

Red Hat Advanced Cluster Security for Kubernetes を最新バージョンにアップグレードするには、以下を実行する必要があります。

  • Central データベースをバックアップする
  • Central をアップグレードする
  • roxctl CLI をアップグレードする
  • スキャナーをアップグレードする
  • 保護されたすべてのクラスターがアップグレードされていることを確認する

2.1. Central データベースのバックアップ

Central データベースをバックアップし、そのバックアップを使用して、インフラストラクチャーの障害が発生した場合に、失敗したアップグレードまたはデータの復元からロールバックすることができます。

前提条件

  • Red Hat Advanced Cluster Security for Kubernetes のすべてのリソースに対する read 権限を持つ API トークンがある。Analyst システムロールには、すべてのリソースに対する read 権限がある。
  • roxctl CLI をインストールした。
  • ROX_API_TOKEN および ROX_CENTRAL_ADDRESS 環境変数を設定した。

手順

  • backup コマンドを実行します。

    • Red Hat Advanced Cluster Security for Kubernetes 3.0.55 以降の場合:

      $ roxctl -e "$ROX_CENTRAL_ADDRESS" central backup
    • Red Hat Advanced Cluster Security for Kubernetes 3.0.54 以前の場合:

      $ roxctl -e "$ROX_CENTRAL_ADDRESS" central db backup

2.2. Central クラスターのアップグレード

Central データベースをバックアップしたら、次のステップは Central クラスターをアップグレードすることです。この手順には、Central、roxctl CLI、および Scanner のアップグレードが含まれます。

2.2.1. Central のアップグレード

更新されたイメージをダウンロードしてデプロイすることにより、Central を最新バージョンに更新できます。

前提条件

  • プライベートイメージレジストリーからイメージをデプロイする場合は、最初に新しいイメージをプライベートレジストリーにプッシュしてから、このセクションのコマンドのイメージレジストリーを置き換えます。

手順

  • 次のコマンドを実行して、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
    Kubernetes を使用する場合は、oc の代わりに kubectl と入力します。
    $ oc -n stackrox patch deployment/scanner -p '{"spec":{"template":{"spec":{"containers":[{"name":"scanner","securityContext":{"runAsUser":65534}}]}}}}' 1
    1
    Kubernetes を使用する場合は、oc の代わりに kubectl と入力します。
    $ oc -n stackrox set image deploy/central central=registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:3.71.3 1
    1
    Kubernetes を使用する場合は、oc の代わりに kubectl と入力します。
    重要
    • Red Hat Advanced Cluster Security for Kubernetes 3.65.0 からアップグレードする場合は、次の追加コマンドを実行して、stackrox-central-diagnostics ロールを作成する必要があります。

      $ oc -n stackrox patch role stackrox-central-diagnostics -p '{"rules":[{"apiGroups":["*"],"resources":["deployments","daemonsets","replicasets","configmaps","services"],"verbs":["get","list"]}]}' 1
      1
      Kubernetes を使用する場合は、oc の代わりに kubectl と入力します。
    • Helm または Operator を使用して Red Hat Advanced Cluster Security for Kubernetes をインストールしておらず、OpenShift OAuth サーバーを使用して認証を有効にする場合は、次の追加コマンドを実行する必要があります。

      $ 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"}}"
      }
      }
      }'

検証

  • 新しい Pod がデプロイされていることを確認します。

    $ oc get deploy -n stackrox -o wide 1
    1
    Kubernetes を使用する場合は、oc の代わりに kubectl と入力します。
    $ oc get pod -n stackrox --watch 1
    1
    Kubernetes を使用する場合は、oc の代わりに kubectl と入力します。

2.2.2. roxctl CLI のアップグレード

roxctl CLI を最新バージョンにアップグレードするには、既存のバージョンの roxctl CLI をアンインストールしてから、最新バージョンの roxctl CLI をインストールする必要があります。

2.2.2.1. roxctl CLI のアンインストール

次の手順を使用して、Linux に roxctl CLI バイナリーをアンインストールできます。

手順

  • roxctl バイナリーを見つけて削除します。

    $ ROXPATH=$(which roxctl) && rm -f $ROXPATH 1
    1
    環境によっては、roxctl バイナリーを削除するために管理者権限が必要になる場合があります。

2.2.2.2. Linux への roxctl CLI のインストール

次の手順を使用して、Linux に roxctl CLI バイナリーをインストールできます。

手順

  1. roxctl CLI の最新バージョンをダウンロードします。

    $ curl -O https://mirror.openshift.com/pub/rhacs/assets/3.71.3/bin/Linux/roxctl
  2. roxctl バイナリーを実行可能にします。

    $ chmod +x roxctl
  3. PATH 上にあるディレクトリーに roxctl バイナリーを配置します。

    PATH を確認するには、以下のコマンドを実行します。

    $ echo $PATH

検証

  • インストールした roxctl のバージョンを確認します。

    $ roxctl version

2.2.2.3. macOS への roxctl CLI のインストール

次の手順を使用して、roxctl CLI バイナリーを macOS にインストールできます。

手順

  1. roxctl CLI の最新バージョンをダウンロードします。

    $ curl -O https://mirror.openshift.com/pub/rhacs/assets/3.71.3/bin/Darwin/roxctl
  2. バイナリーからすべての拡張属性を削除します。

    $ xattr -c roxctl
  3. roxctl バイナリーを実行可能にします。

    $ chmod +x roxctl
  4. PATH 上にあるディレクトリーに roxctl バイナリーを配置します。

    PATH を確認するには、以下のコマンドを実行します。

    $ echo $PATH

検証

  • インストールした roxctl のバージョンを確認します。

    $ roxctl version

2.2.2.4. Windows への roxctl CLI のインストール

次の手順を使用して、roxctl CLI バイナリーを Windows にインストールできます。

手順

  • roxctl CLI の最新バージョンをダウンロードします。

    $ curl -O https://mirror.openshift.com/pub/rhacs/assets/3.71.3/bin/Windows/roxctl.exe

検証

  • インストールした roxctl のバージョンを確認します。

    $ roxctl version

roxctl CLI をアップグレードした後、Scanner をアップグレードできます。

2.2.3. Scanner のアップグレード

roxctl CLI を使用して、Scanner を最新バージョンに更新できます。

前提条件

  • プライベートイメージレジストリーからイメージをデプロイする場合は、最初に新しいイメージをプライベートレジストリーにプッシュしてから、次のセクションのコマンドを編集して、プライベートイメージレジストリーの名前を使用する必要があります。

手順

  1. カスタムスキャナー設定を作成した場合は、スキャナー設定ファイルを更新する前に、これらの変更を適用する必要があります。

    1. 次の roxctl コマンドを使用してスキャナーを生成します。

      $ roxctl -e "$ROX_CENTRAL_ADDRESS" scanner generate
    2. TLS シークレット YAML ファイルを適用します。

      • OpenShift Container Platform を使用する場合は、以下のコマンドを入力します。

        $ oc apply -f scanner-bundle/scanner/02-scanner-03-tls-secret.yaml
      • Kubernetes を使用する場合は、次のコマンドを入力します。

        $ kubectl apply -f scanner-bundle/scanner/02-scanner-03-tls-secret.yaml
    3. スキャナー設定 YAML ファイルを適用します。

      • OpenShift Container Platform を使用する場合は、以下のコマンドを入力します。

        $ oc apply -f scanner-bundle/scanner/02-scanner-04-scanner-config.yaml
      • Kubernetes を使用する場合は、次のコマンドを入力します。

        $ kubectl apply -f scanner-bundle/scanner/02-scanner-04-scanner-config.yaml
  2. Scanner イメージを更新します。

    • OpenShift Container Platform を使用する場合は、以下のコマンドを入力します。

      $ oc -n stackrox set image deploy/scanner scanner=registry.redhat.io/advanced-cluster-security/rhacs-scanner-rhel8:3.71.3
    • Kubernetes を使用する場合は、次のコマンドを入力します。

      $ kubectl -n stackrox set image deploy/scanner scanner=registry.redhat.io/advanced-cluster-security/rhacs-scanner-rhel8:3.71.3
  3. Scanner データベースイメージを更新します。

    • OpenShift Container Platform を使用する場合は、以下のコマンドを入力します。

      $ oc -n stackrox set image deploy/scanner-db db=registry.redhat.io/advanced-cluster-security/rhacs-scanner-db-rhel8:3.71.3 init-db=registry.redhat.io/advanced-cluster-security/rhacs-scanner-db-rhel8:3.71.3
    • Kubernetes を使用する場合は、次のコマンドを入力します。

      $ kubectl -n stackrox set image deploy/scanner-db db=registry.redhat.io/advanced-cluster-security/rhacs-scanner-db-rhel8:3.71.3 init-db=registry.redhat.io/advanced-cluster-security/rhacs-scanner-db-rhel8:3.71.3

検証

  • 新しい Pod が正常にデプロイされたことを確認します。

    • OpenShift Container Platform を使用する場合は、以下のコマンドを入力します。

      $ oc get pod -n stackrox --watch
    • Kubernetes を使用する場合は、次のコマンドを入力します。

      $ kubectl get pod -n stackrox --watch

2.2.3.1. RHACS バージョン 3.71 へのアップグレード

roxctl CLI および YAML ファイルを使用して RHACS 3.71 にアップグレードする場合は、いくつかの追加手順を実行する必要があります。Scanner DB イメージは、scanner-db-password Kubernetes Secret を db Scanner DB コンテナーにマウントしなくなりました。代わりに、scanner-db-password は init コンテナー init-db でのみ使用されます。したがって、POSTGRES_PASSWORD_FILE 環境変数を init コンテナー設定に追加する必要があります。init コンテナーは、scanner-db-tls-volume および scanner-db-password ボリュームもマウントする必要があります。以下のセクションでは、OpenShift Container Platform または Kubernetes を使用している場合の RHACS のアップグレード手順を説明します。init コンテナーの詳細については、Kubernetes のドキュメント を参照してください。

前提条件

  • この手順では、Scanner DB 設定の db コンテナーが index 0 にあると想定している。これは、containers リストの最初のエントリーである。また、scanner-db-password ボリュームマウントは、3 番目のエントリーである index 2 にある。

このシナリオはほとんどの展開に当てはまりますが、これらのコマンドを入力する前に Scanner DB の設定を確認してください。値が異なる場合は、次のコマンドで …​/containers/x/volumeMounts/y の値を調整する必要があります。

手順

  1. パッチを適用します。

    • OpenShift Container Platform を使用する場合は、以下のコマンドを入力します。

      $ oc -n stackrox patch deployment.apps/scanner-db --patch '{"spec":{"template":{"spec":{"initContainers":[{"name":"init-db","env":[{"name":"POSTGRES_PASSWORD_FILE","value":"/run/secrets/stackrox.io/secrets/password"}],"command":["/usr/local/bin/docker-entrypoint.sh","postgres","-c","config_file=/etc/postgresql.conf"],"volumeMounts":[{"name":"db-data","mountPath":"/var/lib/postgresql/data"},{"name":"scanner-db-tls-volume","mountPath":"/run/secrets/stackrox.io/certs","readOnly":true},{"name":"scanner-db-password","mountPath":"/run/secrets/stackrox.io/secrets","readOnly":true}],"securityContext":{"runAsGroup":70,"runAsNonRoot":true,"runAsUser":70}}]}}}}'
    • Kubernetes を使用する場合は、次のコマンドを入力します。

      $ kubectl -n stackrox patch deployment.apps/scanner-db --patch '{"spec":{"template":{"spec":{"initContainers":[{"name":"init-db","env":[{"name":"POSTGRES_PASSWORD_FILE","value":"/run/secrets/stackrox.io/secrets/password"}],"command":["/usr/local/bin/docker-entrypoint.sh","postgres","-c","config_file=/etc/postgresql.conf"],"volumeMounts":[{"name":"db-data","mountPath":"/var/lib/postgresql/data"},{"name":"scanner-db-tls-volume","mountPath":"/run/secrets/stackrox.io/certs","readOnly":true},{"name":"scanner-db-password","mountPath":"/run/secrets/stackrox.io/secrets","readOnly":true}],"securityContext":{"runAsGroup":70,"runAsNonRoot":true,"runAsUser":70}}]}}}}'
  2. パスを削除します。

    • OpenShift Container Platform を使用する場合は、以下のコマンドを入力します。

      $ oc -n stackrox patch deployment.apps/scanner-db --type json --patch '[{"op":"remove","path":"/spec/template/spec/containers/0/volumeMounts/2"}]'
    • Kubernetes を使用する場合は、次のコマンドを入力します。

      $ kubectl -n stackrox patch deployment.apps/scanner-db --type json --patch '[{"op":"remove","path":"/spec/template/spec/containers/0/volumeMounts/2"}]'

2.2.4. Central クラスターのアップグレードの確認

Central と Scanner の両方をアップグレードした後、Central クラスターのアップグレードが完了していることを確認します。

手順

  • Central ログを確認します。

    OpenShift Container Platform を使用している場合は、次のコマンドを入力します。

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

    Kubernetes を使用している場合は、次のコマンドを入力します。

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

正常なアップグレードのサンプル出力

No database restore directory found (this is not an error).
Migrator: 2019/10/25 17:58:54: starting DB compaction
Migrator: 2019/10/25 17:58:54: Free fraction of 0.0391 (40960/1048576) is < 0.7500. Will not compact
badger 2019/10/25 17:58:54 INFO: All 1 tables opened in 2ms
badger 2019/10/25 17:58:55 INFO: Replaying file id: 0 at offset: 846357
badger 2019/10/25 17:58:55 INFO: Replay took: 50.324µs
badger 2019/10/25 17:58:55 DEBUG: Value log discard stats empty
Migrator: 2019/10/25 17:58:55: DB is up to date. Nothing to do here.
badger 2019/10/25 17:58:55 INFO: Got compaction priority: {level:0 score:1.73 dropPrefix:[]}
version: 2019/10/25 17:58:55.189866 ensure.go:49: Info: Version found in the DB was current. We’re good to go!

2.3. 保護されたすべてのクラスターのアップグレード

Central サービスをアップグレードした後、すべての保護されたクラスターをアップグレードする必要があります。

重要
  • 自動アップグレードを使用している場合は、以下を行います。

  • 自動アップグレードを使用していない場合は、Central クラスターを含むすべての保護されたクラスターでこのセクションの手順を実行する必要があります。

    • 最適な機能を確保するには、セキュアなクラスターと Central がインストールされているクラスターに同じ RHACS バージョンを使用してください。

Sensor、Collector、および Admission コントローラーを実行しているセキュリティーで保護された各クラスターの手動アップグレードを完了するには、このセクションの手順に従ってください。

2.3.1. 準備状態 (readiness) プローブを更新

Red Hat Advanced Cluster Security for Kubernetes 3.65.0 より前のバージョンからアップグレードする場合は、次の追加コマンドを実行して、readiness プローブパスを更新する必要があります。3.65 よりも新しいバージョンを実行している場合は、この手順をスキップしてください。

手順

  • readiness プローブパスを更新します。

    $ oc -n stackrox patch deploy/sensor -p '{"spec":{"template":{"spec":{"containers":[{"name":"sensor","readinessProbe":{"httpGet":{"path":"/ready"}}}]}}}}' 1
    1
    Kubernetes を使用する場合は、oc の代わりに kubectl と入力します。

2.3.2. OpenShift セキュリティーコンテキスト制約の更新

アップグレードする Red Hat Advanced Cluster Security for Kubernetes のバージョンに応じて、特定の OpenShift Container Platform セキュリティーコンテキスト制約 (SCC) を更新する必要があります。

警告

このセクションのコマンドは、OpenShift Container Platform で Red Hat Advanced Cluster Security for Kubernetes を使用している場合に限り実行してください。それ以外の場合は、このセクションの手順をスキップしてください。

手順

  • Red Hat Advanced Cluster Security for Kubernetes 3.64.0 は SCC の名前を変更します。Red Hat Advanced Cluster Security for Kubernetes 3.64.0 より前のバージョンからアップグレードする場合は、SCC を削除して再適用する必要があります。それ以外の場合は、次の手順をスキップしてください。

    1. 次のコマンドを実行して、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. 次のコマンドを実行して 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. 各 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

2.3.3. その他のイメージの更新

自動アップグレードを使用しない場合は、セキュリティーで保護された各クラスターのセンサー、コレクター、コンプライアンスイメージを更新する必要があります。

注記

Kubernetes を使用している場合は、この手順にリストされているコマンドに oc の代わりに kubectl を使用してください。

手順

  1. Sensor イメージを更新します。

    $ oc -n stackrox set image deploy/sensor sensor=registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:3.71.3 1
    1
    Kubernetes を使用する場合は、oc の代わりに kubectl と入力します。
  2. Compliance イメージを更新します。

    $ oc -n stackrox set image ds/collector compliance=registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:3.71.3 1
    1
    Kubernetes を使用する場合は、oc の代わりに kubectl と入力します。
  3. Collector イメージを更新します。

    $ oc -n stackrox set image ds/collector collector=registry.redhat.io/advanced-cluster-security/rhacs-collector-rhel8:3.71.3 1
    1
    Kubernetes を使用する場合は、oc の代わりに kubectl と入力します。
    注記

    コレクタースリムイメージを使用している場合は、代わりに次のコマンドを実行します。

    $ oc -n stackrox set image ds/collector collector=registry.redhat.io/advanced-cluster-security/rhacs-collector-slim-rhel8:{rhacs-version}
  4. アドミッションコントロールイメージを更新します。

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

2.3.4. 保護されたクラスターのアップグレードの確認

保護されたクラスターをアップグレードしたら、更新された Pod が機能していることを確認します。

手順

  • 新しい Pod がデプロイされていることを確認します。

    $ oc get deploy,ds -n stackrox -o wide 1
    1
    Kubernetes を使用する場合は、oc の代わりに kubectl と入力します。
    $ oc get pod -n stackrox --watch 1
    1
    Kubernetes を使用する場合は、oc の代わりに kubectl と入力します。

2.4. Central のロールバック

新しいバージョンへのアップグレードが失敗した場合は、以前のバージョンの Central にロールバックできます。

2.4.1. Central を通常どおりロールバック

Red Hat Advanced Cluster Security for Kubernetes のアップグレードが失敗した場合は、以前のバージョンの Central にロールバックできます。

前提条件

  • Red Hat Advanced Cluster Security for Kubernetes 3.0.57.0 以降を使用している必要がある。
  • ロールバックを実行する前に、永続ストレージで使用可能な空きディスク容量が必要である。Red Hat Advanced Cluster Security for Kubernetes は、ディスク領域を使用して、アップグレード中にデータベースのコピーを保持する。ディスク容量がコピーを保存するのに十分でなく、アップグレードが失敗した場合は、以前のバージョンにロールバックすることはできない。

手順

  • アップグレードが失敗した場合 (Central サービスが開始する前) に、次のコマンドを実行して前のバージョンにロールバックします。

    $ oc -n stackrox rollout undo deploy/central 1
    1
    Kubernetes を使用する場合は、oc の代わりに kubectl と入力します。

2.4.2. Central を強制的にロールバックする

強制ロールバックを使用して、以前のバージョンの Central にロールバックできます (Central サービスの開始後)。

重要

強制ロールバックを使用して以前のバージョンに戻すと、データと機能が失われる可能性があります。

前提条件

  • Red Hat Advanced Cluster Security for Kubernetes 3.0.58.0 以降を使用している必要がある。
  • ロールバックを実行する前に、永続ストレージで使用可能な空きディスク容量が必要である。Red Hat Advanced Cluster Security for Kubernetes は、ディスク領域を使用して、アップグレード中にデータベースのコピーを保持する。ディスク容量がコピーを保存するのに十分でなく、アップグレードが失敗した場合は、以前のバージョンにロールバックすることはできない。

手順

  • 次のコマンドを実行して、強制ロールバックを実行します。

    • 以前にインストールしたバージョンに強制的にロールバックするには、以下のコマンドを実行します。

      $ oc -n stackrox rollout undo deploy/central 1
      1
      Kubernetes を使用する場合は、oc の代わりに kubectl と入力します。
    • 特定のバージョンに強制的にロールバックするには、以下を行います。

      1. Central の ConfigMap を編集します。

        $ oc -n stackrox edit configmap/central-config 1
        1
        Kubernetes を使用する場合は、oc の代わりに kubectl と入力します。
      2. maintenance.forceRollbackVersion キーの値を更新します。

        data:
          central-config.yaml: |
            maintenance:
              safeMode: false
              compaction:
                 enabled: true
                 bucketFillFraction: .5
                 freeFractionThreshold: 0.75
              forceRollbackVersion: <x.x.x.x> 1
          ...
        1
        ロールバックするバージョンを指定します。
      3. Central イメージのバージョンを更新します。

        $ oc -n stackrox \ 1
          set image deploy/central central=registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:<x.x.x.x> 2
        1
        Kubernetes を使用する場合は、oc の代わりに kubectl と入力します。
        2
        ロールバックするバージョンを指定します。これは、central-config 設定マップで maintenance.forceRollbackVersion キーに指定したものと同じバージョンである必要があります。

2.5. アップグレードの確認

更新された Sensor と Collector は、保護された各クラスターからの最新データを引き続き報告します。

Sensor が Central に最後に接続した時刻は、RHACS ポータルに表示されます。

手順

  1. RHACS ポータルで、Platform ConfigurationSystem Health に移動します。
  2. Sensor Upgrade で、Central で最新のクラスターが表示されることを確認してください。

2.6. API トークンの取り消し

セキュリティー上の理由から、Red Hat では、Central データベースのバックアップを完了するために使用した API トークンを取り消すことが推奨されます。

前提条件

  • アップグレード後、RHACS ポータルページをリロードし、証明書を再承認して、RHACS ポータルを引き続き使用する必要がある。

手順

  1. RHACS ポータルで、Platform ConfigurationIntegrations に移動します。
  2. Authentication Tokens カテゴリーまで下にスクロールし、API Token をクリックします。
  3. 取り消すトークン名の前にあるチェックボックスを選択します。
  4. Revoke をクリックします。
  5. 確認ダイアログボックスで、Confirm をクリックします。

法律上の通知

Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.