업그레이드

Red Hat Advanced Cluster Security for Kubernetes 3.73

Red Hat Advanced Cluster Security for Kubernetes 업그레이드

Red Hat OpenShift Documentation Team

초록

이 섹션에서는 Helm 차트 또는 roxctl 명령줄 인터페이스를 사용하여 Kubernetes용 Red Hat Advanced Cluster Security를 업그레이드하는 방법을 설명합니다.

1장. Operator를 사용하여 업그레이드

RHACS(Advanced Cluster Security for Kubernetes) Operator를 통한 업그레이드는 설치 시 선택한 업데이트 승인 옵션에 따라 자동으로 또는 수동으로 수행됩니다.

Operator를 사용하여 RHACS를 설치하고 Update 승인 필드에서 자동 을 선택하면 새 소프트웨어 버전이 릴리스될 때 RHACS가 자동으로 업데이트됩니다. 수동 을 선택한 경우 OLM(Operator Lifecycle Manager)을 사용하여 후속 Operator 업데이트를 승인해야 합니다. 자세한 내용은 보류 중인 Operator 업데이트 수동 승인을 참조하십시오.

Operator 업그레이드를 롤백하려면 다음 섹션 중 하나에 설명된 단계를 수행해야 합니다. CLI 또는 OpenShift Container Platform 웹 콘솔을 사용하여 Operator 업그레이드를 롤백할 수 있습니다.

1.1. CLI를 사용하여 Operator 업그레이드 롤백

CLI 명령을 사용하여 Operator 버전을 롤백할 수 있습니다.

절차

  1. 다음 명령을 실행하여 OLM 서브스크립션을 삭제합니다.

    • OpenShift Container Platform의 경우 다음 명령을 실행합니다.

      $ oc -n rhacs-operator delete subscription rhacs-operator
    • Kubernetes의 경우 다음 명령을 실행합니다.

      $ kubectl -n rhacs-operator delete subscription rhacs-operator
  2. 다음 명령을 실행하여 CSV(클러스터 서비스 버전)를 삭제합니다.

    • OpenShift Container Platform의 경우 다음 명령을 실행합니다.

      $ oc -n rhacs-operator delete csv -l operators.coreos.com/rhacs-operator.rhacs-operator
    • Kubernetes의 경우 다음 명령을 실행합니다.

      $ kubectl -n rhacs-operator delete csv -l operators.coreos.com/rhacs-operator.rhacs-operator
  3. 다음 옵션 중 하나를 선택하여 롤백할 이전 버전을 결정합니다.

    • 현재 Central 인스턴스가 실행 중인 경우 RHACS API를 쿼리하여 다음 명령을 실행하여 롤백 버전을 가져옵니다.

      $ curl -k -s -u <user>:<password> https://<central hostname>/v1/centralhealth/upgradestatus | jq -r .upgradeStatus.forceRollbackTo
    • 현재 Central 인스턴스가 실행되고 있지 않은 경우 다음 단계를 수행합니다.

      참고

      이 절차는 Rillsdb 데이터베이스를 설치할 때 RHACS 릴리스 3.74 및 이전 버전에 만 사용할 수 있습니다.

      1. 다음 명령을 실행하여 중앙 배포가 축소되었는지 확인합니다.

        • OpenShift Container Platform의 경우 다음 명령을 실행합니다.

          $ oc scale -n <central namespace> –replicas=0 deploy/central
        • Kubernetes의 경우 다음 명령을 실행합니다.

          $ kubectl scale -n <central namespace> –replicas=0 deploy/central
      2. 다음 Pod 사양을 YAML 파일로 저장합니다.

        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
      3. 저장한 YAML 파일을 사용하여 다음 명령을 실행하여 중앙 네임스페이스에 Pod를 생성합니다.

        • OpenShift Container Platform의 경우 다음 명령을 실행합니다.

          $ oc create -n <central namespace> -f pod.yaml
        • Kubernetes의 경우 다음 명령을 실행합니다.

          $ kubectl create -n <central namespace> -f pod.yaml
      4. Pod 생성이 완료되면 다음 명령을 실행하여 버전을 가져옵니다.

        • OpenShift Container Platform의 경우 다음 명령을 실행합니다.

          $ oc logs -n <central namespace> get-previous-db-version
        • Kubernetes의 경우 다음 명령을 실행합니다.

          $ kubectl logs -n <central namespace> get-previous-db-version
  4. central-config.yaml ConfigMap 을 편집하여 다음 명령을 실행하여 maintenance.forceRollBackVersion:<version > 매개변수를 설정합니다.

    • OpenShift Container Platform의 경우 다음 명령을 실행합니다.

      $ oc get configmap -n <central namespace> central-config -o yaml | sed -e "s/forceRollbackVersion: none/forceRollbackVersion: <version>/" | oc -n <central namespace> apply -f -
    • Kubernetes의 경우 다음 명령을 실행합니다.

      $ kubectl get configmap -n <central namespace> central-config -o yaml | sed -e "s/forceRollbackVersion: none/forceRollbackVersion: <version>/" | kubectl -n <central namespace> apply -f -
  5. 3단계에 표시된 version 문자열을 이미지 태그로 사용하여 중앙 배포의 이미지를 설정합니다. 예를 들어 다음 명령을 실행합니다.

    • OpenShift Container Platform의 경우 다음 명령을 실행합니다.

      $ oc set image -n <central namespace> deploy/central central=registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:<version>
    • Kubernetes의 경우 다음 명령을 실행합니다.

      $ kubectl set image -n <central namespace> deploy/central central=registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:<version>

검증

  1. 중앙 Pod가 시작되고 준비 상태인지 확인합니다. Pod가 충돌하는 경우 로그를 확인하여 백업이 복원되었는지 확인합니다. 성공 로그 메시지는 다음 예와 유사합니다.

    Clone to Migrate ".previous", ""
  2. 롤백된 백엔드 채널에 Operator를 다시 설치합니다. 예를 들어 3.71.3rhacs-3.71 채널에 설치됩니다.

1.2. 웹 콘솔을 사용하여 Operator 업그레이드 롤백

OpenShift Container Platform 웹 콘솔을 사용하여 Operator 버전을 롤백할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터 웹 콘솔에 액세스할 수 있습니다.

절차

  1. Operator설치된 Operator 페이지로 이동합니다.
  2. RHACS Operator를 찾아 클릭합니다.
  3. Operator 세부 정보 페이지의 작업 목록에서 Operator 제거를 선택합니다. 이 작업 후에 Operator는 실행을 중지하고 더 이상 업데이트가 수신되지 않습니다.
  4. 다음 옵션 중 하나를 선택하여 롤백할 이전 버전을 결정합니다.

    • 현재 중앙 인스턴스가 실행 중인 경우 터미널 창에서 다음 명령을 실행하여 RHACS API를 쿼리하여 롤백 버전을 가져올 수 있습니다.

      $ curl -k -s -u <user>:<password> https://<central hostname>/v1/centralhealth/upgradestatus | jq -r .upgradeStatus.forceRollbackTo
    • 다음 단계를 수행하여 Pod를 생성하고 이전 버전을 추출할 수 있습니다.

      참고

      이 절차는 Rillsdb 데이터베이스를 설치할 때 RHACS 릴리스 3.74 및 이전 버전에 만 사용할 수 있습니다.

      1. 워크로드 → 배포 중앙 으로 이동합니다.
      2. 배포 세부 정보에서 포드 수 옆에 있는 아래쪽 화살표를 클릭하여 Pod를 축소합니다.
      3. 워크로드PodPod 생성 으로 이동하여 다음 예에 표시된 대로 Pod 사양의 내용을 편집기에 붙여넣습니다.

        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
      4. 생성을 클릭합니다.
      5. 포드가 생성되면 로그 탭을 클릭하여 버전 문자열을 가져옵니다.
  5. 다음 단계를 수행하여 롤백 구성을 업데이트합니다.

    1. 워크로드 → ConfigMaps central-config 로 이동하여 작업 목록에서 ConfigMap 편집 을 선택합니다.
    2. central-config.yaml 키 값에서 forceRollbackVersion 행을 찾습니다.
    3. none3.73.3 으로 교체한 다음 파일을 저장합니다.
  6. 다음 단계를 수행하여 이전 버전으로 중앙을 업데이트합니다.

    1. 워크로드 → 배포 중앙 으로 이동하고 작업 목록에서 배포 편집 을 선택합니다.
    2. 이미지 이름을 업데이트한 다음 변경 사항을 저장합니다.

검증

  1. 중앙 Pod가 시작되고 준비 상태인지 확인합니다. Pod가 충돌하는 경우 로그를 확인하여 백업이 복원되었는지 확인합니다. 성공 로그 메시지는 다음 예와 유사합니다.

    Clone to Migrate ".previous", ""
  2. 롤백된 백엔드 채널에 Operator를 다시 설치합니다. 예를 들어 3.71.3rhacs-3.71 채널에 설치됩니다.

1.3. 추가 리소스

2장. Helm 차트를 사용하여 업그레이드

Helm 차트를 사용하여 Kubernetes용 Red Hat Advanced Cluster Security for Kubernetes를 설치한 경우 최신 버전의 Red Hat Advanced Cluster Security for Kubernetes로 업그레이드하려면 다음을 수행해야 합니다.

  • Helm 차트를 업데이트합니다.
  • central-services Helm 차트의 구성 파일을 업데이트합니다.
  • central-services Helm 차트를 업그레이드합니다.
  • secure-cluster-services Helm 차트의 구성 파일을 업데이트합니다.
  • secure-cluster-services Helm 차트를 업그레이드합니다.
중요

최적의 기능을 유지하려면 보안-cluster-services Helm 차트 및 central-services Helm 차트에 동일한 버전을 사용합니다.

2.1. Helm 차트 리포지터리 업데이트

Kubernetes용 새 버전의 Red Hat Advanced Cluster Security로 업그레이드하기 전에 항상 Helm 차트를 업데이트해야 합니다.

사전 요구 사항

  • 이미 Kubernetes Helm 차트용 Red Hat Advanced Cluster Security 리포지터리를 추가해야 합니다.

절차

  • Red Hat Advanced Cluster Security for Kubernetes 차트 리포지터리 업데이트.

    $ helm repo update

검증

  • 다음 명령을 실행하여 추가된 차트 리포지터리를 확인합니다.

    $ helm search repo -l rhacs/

2.2. 추가 리소스

3장. roxctl CLI를 사용하여 수동으로 업그레이드

지원되는 이전 버전에서 최신 버전의 RHACS(Red Hat Advanced Cluster Security for Kubernetes)로 업그레이드할 수 있습니다.

참고

RHACS를 배포하는 데 roxctl CLI를 사용한 경우에만 수동 업그레이드 절차를 수행해야 합니다.

RHACS를 최신 버전으로 업그레이드하려면 다음을 수행해야 합니다.

  • ROX_SCANNER_DB_INIT 환경 변수를 설정합니다.
  • 중앙 데이터베이스 백업
  • Upgrade Central
  • roxctl CLI 업그레이드
  • 업그레이드 스캐너
  • 모든 보안 클러스터가 업그레이드되었는지 확인합니다.

3.1. ROX_SCANNER_DB_INIT 환경 변수를 설정합니다.

scannerDB의 initContainer 에는 ROX_SCANNER_DB_INIT 라는 새로운 환경 변수가 필요합니다. 업그레이드하기 전에 해당 값을 true 로 설정해야 합니다.

절차

  • OpenShift Container Platform의 경우 다음 명령을 실행합니다.

    $ oc -n stackrox set env deploy/scanner-db -c init-db ROX_SCANNER_DB_INIT=true
  • Kubernetes의 경우 다음 명령을 실행합니다.

    $ kubectl -n stackrox set env deploy/scanner-db -c init-db ROX_SCANNER_DB_INIT=true

3.2. 중앙 데이터베이스 백업

인프라 재해의 경우 중앙 데이터베이스를 백업하고 해당 백업을 사용하여 실패한 업그레이드 또는 데이터 복원에서 롤백할 수 있습니다.

사전 요구 사항

  • Red Hat Advanced Cluster Security for Kubernetes의 모든 리소스에 대한 읽기 권한이 있는 API 토큰이 있어야 합니다. Analyst 시스템 역할에는 모든 리소스에 대한 읽기 권한이 있습니다.
  • roxctl CLI를 설치했습니다.
  • ROX_API_TOKENROX_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

3.3. 중앙 클러스터 업그레이드

중앙 데이터베이스를 백업한 후 다음 단계는 중앙 클러스터를 업그레이드하는 것입니다. 이 단계에는 Central, roxctl CLI 및 Scanner 업그레이드가 포함됩니다.

3.3.1. Central 업그레이드

업데이트된 이미지를 다운로드하고 배포하여 최신 버전으로 중앙을 업데이트할 수 있습니다.

3.3.1.1. OpenShift Container Platform에서 중앙 업그레이드

OpenShift Container Platform에 Red Hat Advanced Cluster Security for Kubernetes를 설치한 경우 다음 절차를 사용하여 업그레이드하십시오.

절차

  1. 로컬 역할을 패치합니다.

    $ oc -n stackrox patch role edit -p '{"rules":[{"apiGroups":["*"],"resources":["*"],"verbs":["create","get", "list", "watch", "update", "patch", "delete","deletecollection"]}]}'
  2. 기존 역할 및 역할 바인딩을 정리합니다.

    $ oc -n stackrox delete RoleBinding admission-control-use-scc || true
    $ oc -n stackrox delete RoleBinding sensor-use-scc || true
    $ oc -n stackrox delete Role use-anyuid-scc || true
  3. 하드 코드된 보안 컨텍스트를 제거하여 센서허용 제어를 restricted[-v2] 보안 컨텍스트로 설정합니다.

    $ oc -n stackrox patch deploy sensor -p '{"spec":{"template":{"spec":{"securityContext":null}}}}' 1
    1
    Red Hat Advanced Cluster Security for Kubernetes는 Pod를 자동으로 다시 생성하지만 센서 를 다시 시작하는 데 시간이 걸릴 수 있습니다.
    $ oc -n stackrox patch deploy admission-control -p '{"spec":{"template":{"spec":{"securityContext":null}}}}'
  4. 다음 명령을 실행하여 Central을 업그레이드합니다.

    $ oc -n stackrox patch deploy/central -p '{"spec":{"template":{"spec":{"containers":[{"name":"central","env":[{"name":"ROX_NAMESPACE","valueFrom":{"fieldRef":{"fieldPath":"metadata.namespace"}}}]}]}}}}'
    $ oc -n stackrox patch deployment/scanner -p '{"spec":{"template":{"spec":{"containers":[{"name":"scanner","securityContext":{"runAsUser":65534}}]}}}}'
    $ oc -n stackrox set image deploy/central central=registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:3.73.5 1
    1
    개인 이미지 레지스트리에서 이미지를 배포하는 경우 새 이미지를 프라이빗 레지스트리로 푸시하고 여기에서 이미지 레지스트리 주소를 교체합니다.
    중요

    Helm 또는 Operator를 사용하여 Kubernetes용 Red Hat Advanced Cluster Security를 설치하지 않았으며 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
    $ oc get pod -n stackrox --watch

3.3.1.2. Kubernetes의 중앙 업그레이드

Kubernetes에 Red Hat Advanced Cluster Security for Kubernetes를 설치한 경우 다음 절차를 사용하여 업그레이드하십시오.

사전 요구 사항

  • 프라이빗 이미지 레지스트리에서 이미지를 배포하는 경우 먼저 새 이미지를 프라이빗 레지스트리로 내보낸 다음 다음 명령에서 이미지 레지스트리를 교체합니다.

절차

  1. 로컬 역할을 패치합니다.

    $ kubectl -n stackrox patch role edit -p '{"rules":[{"apiGroups":["*"],"resources":["*"],"verbs":["create","get", "list", "watch", "update", "patch", "delete","deletecollection"]}]}'
  2. 다음 명령을 실행하여 Central을 업그레이드합니다.

    $ kubectl -n stackrox patch deploy/central -p '{"spec":{"template":{"spec":{"containers":[{"name":"central","env":[{"name":"ROX_NAMESPACE","valueFrom":{"fieldRef":{"fieldPath":"metadata.namespace"}}}]}]}}}}'
    $ kubectl -n stackrox patch deployment/scanner -p '{"spec":{"template":{"spec":{"containers":[{"name":"scanner","securityContext":{"runAsUser":65534}}]}}}}'
    $ kubectl -n stackrox set image deploy/central central=registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:3.73.5 1
    1
    개인 이미지 레지스트리에서 이미지를 배포하는 경우 새 이미지를 프라이빗 레지스트리로 푸시하고 여기에서 이미지 레지스트리 주소를 교체합니다.

검증

  • 새 Pod가 배포되었는지 확인합니다.

    $ kubectl get deploy -n stackrox -o wide
    $ kubectl get pod -n stackrox --watch

3.3.2. roxctl CLI 업그레이드

roxctl CLI를 최신 버전으로 업그레이드하려면 기존 버전의 roxctl CLI를 제거한 다음 최신 버전의 roxctl CLI를 설치해야 합니다.

3.3.2.1. roxctl CLI 설치 제거

다음 절차에 따라 Linux에서 roxctl CLI 바이너리를 제거할 수 있습니다.

절차

  • roxctl 바이너리를 찾아 삭제합니다.

    $ ROXPATH=$(which roxctl) && rm -f $ROXPATH 1
    1
    환경에 따라 roxctl 바이너리를 삭제하려면 관리자 권한이 필요할 수 있습니다.

3.3.2.2. Linux에서 roxctl CLI 설치

다음 절차에 따라 Linux에서 roxctl CLI 바이너리를 설치할 수 있습니다.

절차

  1. 최신 버전의 roxctl CLI를 다운로드합니다.

    $ curl -O https://mirror.openshift.com/pub/rhacs/assets/3.73.5/bin/Linux/roxctl
  2. roxctl 바이너리를 실행 가능하게 합니다.

    $ chmod +x roxctl
  3. roxctl 바이너리를 PATH 에 있는 디렉터리에 배치합니다.

    PATH를 확인하려면 다음 명령을 실행합니다.

    $ echo $PATH

검증

  • 설치된 roxctl 버전을 확인합니다.

    $ roxctl version

3.3.2.3. macOS에 roxctl CLI 설치

다음 절차에 따라 macOS에서 roxctl CLI 바이너리를 설치할 수 있습니다.

절차

  1. 최신 버전의 roxctl CLI를 다운로드합니다.

    $ curl -O https://mirror.openshift.com/pub/rhacs/assets/3.73.5/bin/Darwin/roxctl
  2. 바이너리에서 모든 확장 속성을 제거합니다.

    $ xattr -c roxctl
  3. roxctl 바이너리를 실행 가능하게 합니다.

    $ chmod +x roxctl
  4. roxctl 바이너리를 PATH 에 있는 디렉터리에 배치합니다.

    PATH를 확인하려면 다음 명령을 실행합니다.

    $ echo $PATH

검증

  • 설치된 roxctl 버전을 확인합니다.

    $ roxctl version

3.3.2.4. Windows에 roxctl CLI 설치

다음 절차에 따라 Windows에서 roxctl CLI 바이너리를 설치할 수 있습니다.

절차

  • 최신 버전의 roxctl CLI를 다운로드합니다.

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

검증

  • 설치된 roxctl 버전을 확인합니다.

    $ roxctl version

roxctl CLI를 업그레이드한 후 스캐너를 업그레이드할 수 있습니다.

3.3.3. 스캐너 업그레이드

roxctl CLI를 사용하여 scanner를 최신 버전으로 업데이트할 수 있습니다.

사전 요구 사항

  • 개인 이미지 레지스트리에서 이미지를 배포하는 경우 먼저 새 이미지를 프라이빗 레지스트리로 푸시한 다음, 개인 이미지 레지스트리 이름을 사용하도록 다음 섹션의 명령을 편집해야 합니다.

절차

  1. 사용자 정의 스캐너 구성을 생성한 경우 스캐너 구성 파일을 업데이트하기 전에 해당 변경 사항을 적용해야 합니다.

    1. 다음 roxctl 명령을 사용하여 Scanner를 생성합니다.

      $ 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. scanner 구성 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.73.5
    • Kubernetes를 사용하는 경우 다음 명령을 입력합니다.

      $ kubectl -n stackrox set image deploy/scanner scanner=registry.redhat.io/advanced-cluster-security/rhacs-scanner-rhel8:3.73.5
  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.73.5 init-db=registry.redhat.io/advanced-cluster-security/rhacs-scanner-db-rhel8:3.73.5
    • Kubernetes를 사용하는 경우 다음 명령을 입력합니다.

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

검증

  • 새 Pod가 성공적으로 배포되었는지 확인합니다.

    • OpenShift Container Platform을 사용하는 경우 다음 명령을 입력합니다.

      $ oc get pod -n stackrox --watch
    • Kubernetes를 사용하는 경우 다음 명령을 입력합니다.

      $ kubectl get pod -n stackrox --watch

3.3.3.1. RHACS 버전 3.71로 업그레이드

roxctl CLI 및 YAML 파일을 사용하여 RHACS 3.71로 업그레이드하는 경우 몇 가지 추가 단계를 수행해야 합니다. scanner DB 이미지는 더 이상 scanner-db-password Kubernetes 시크릿을 db Scanner DB 컨테이너에 마운트하지 않습니다. 대신 scanner-db-password 는 init 컨테이너 init-db 에서만 사용됩니다. 따라서 init 컨테이너 구성에 POSTGRES_PASSWORD_FILE 환경 변수를 추가해야 합니다. init 컨테이너는 scanner-db-tls-volumescanner-db-password 볼륨도 마운트해야 합니다. 다음 섹션에서는 OpenShift Container Platform 또는 Kubernetes를 사용하는 경우 RHACS의 업그레이드 단계를 제공합니다. init 컨테이너에 대한 자세한 내용은 Kubernetes 설명서를 참조하십시오.

사전 요구 사항

  • 이 절차에서는 Scanner DB 구성의 db 컨테이너가 컨테이너 목록의 첫 번째 항목인 인덱스 0 에 있고, scanner-db-password 볼륨 마운트는 세 번째 항목인 인덱스 2 에 있다고 가정합니다.

이 시나리오는 대부분의 배포에 적용되지만 이러한 명령을 입력하기 전에 스캐너 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"}]'

3.3.4. 중앙 클러스터 업그레이드 확인

중앙과 스캐너를 모두 업그레이드한 후 중앙 클러스터 업그레이드가 완료되었는지 확인합니다.

절차

  • 중앙 로그를 확인합니다.

    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!

3.4. 모든 보안 클러스터 업그레이드

중앙 서비스를 업그레이드한 후 모든 보안 클러스터를 업그레이드해야 합니다.

중요
  • 자동 업그레이드를 사용하는 경우:

  • 자동 업그레이드를 사용하지 않는 경우 중앙 클러스터를 포함한 모든 보안 클러스터에 대해 이 섹션의 지침을 실행해야 합니다.

    • 최적의 기능을 유지하려면 보안 클러스터와 중앙이 설치된 클러스터에 동일한 RHACS 버전을 사용하십시오.

센서, 수집기 및 Admission 컨트롤러를 실행하는 각 보안 클러스터의 수동 업그레이드를 완료하려면 이 섹션의 지침을 따르십시오.

3.4.1. Update ValidatingWebhookConfiguration

이전 RHACS 버전에는 ValidatingWebhookConfiguration에 잘못된 항목이 포함되어 있었습니다. 이 문제를 해결하려면 ValidatingWebhookConfiguration을 업데이트해야 합니다.

절차

  • Admission 컨트롤러에서 listenOnEvents 를 활성화한 경우 다음 명령을 실행해야 합니다.

    $ oc patch validatingwebhookconfiguration stackrox -p '{"webhooks":[{"name": "k8sevents.stackrox.io", "rules": [{"apiGroups": ["*"], "apiVersions": ["*"], "operations": ["CONNECT"], "resources": ["pods", "pods/exec", "pods/portforward"]}]}]}' 1
    1
    Kubernetes를 사용하는 경우 oc.. 대신 kubectl 을 입력합니다.

3.4.2. 다른 이미지 업데이트

자동 업그레이드를 사용하지 않는 경우 각 보안 클러스터에서 센서, 수집기, 규정 준수 이미지를 업데이트해야 합니다.

참고

Kubernetes를 사용하는 경우 이 프로세스에 나열된 명령에 oc 대신 kubectl 을 사용하십시오.

절차

  1. 센서 이미지를 업데이트합니다.

    $ oc -n stackrox set image deploy/sensor sensor=registry.redhat.io/advanced-cluster-security/rhacs-main-rhel8:3.73.5 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.73.5 1
    1
    Kubernetes를 사용하는 경우 oc.. 대신 kubectl 을 입력합니다.
  3. 수집기 이미지를 업데이트합니다.

    $ oc -n stackrox set image ds/collector collector=registry.redhat.io/advanced-cluster-security/rhacs-collector-rhel8:3.73.5 1
    1
    Kubernetes를 사용하는 경우 oc.. 대신 kubectl 을 입력합니다.
    참고

    수집기 slim 이미지를 사용하는 경우 대신 다음 명령을 실행합니다.

    $ 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.73.5

3.4.3. 보안 클러스터 업그레이드 확인

보안 클러스터를 업그레이드한 후 업데이트된 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 을 입력합니다.

3.5. Rolling back Central

새 버전으로 업그레이드에 실패하면 이전 버전의 Central으로 롤백할 수 있습니다.

3.5.1. STOP(Rock back Central)를 정상적으로 롤백

Red Hat Advanced Cluster Security for Kubernetes 업그레이드에 실패하면 이전 버전의 Central으로 롤백할 수 있습니다.

사전 요구 사항

  • Kubernetes 3.0.57.0 이상용 Red Hat Advanced Cluster Security를 사용해야 합니다.
  • 롤백을 수행하려면 영구 스토리지에서 사용 가능한 디스크 공간이 있어야 합니다. Red Hat Advanced Cluster Security for Kubernetes는 디스크 공간을 사용하여 업그레이드하는 동안 데이터베이스 복사본을 유지합니다. 디스크 공간이 사본을 저장하기에 충분하지 않고 업그레이드가 실패하면 이전 버전으로 롤백할 수 없습니다.

절차

  • 다음 명령을 실행하여 업그레이드가 실패할 때 이전 버전으로 롤백합니다(중앙 서비스가 시작되기 전에).

    $ oc -n stackrox rollout undo deploy/central 1
    1
    Kubernetes를 사용하는 경우 oc.. 대신 kubectl 을 입력합니다.

3.5.2. 중앙에서 강제로 롤백

강제 롤백을 사용하여 중앙의 이전 버전으로 롤백할 수 있습니다(중앙 서비스 시작 후).

중요

강제 롤백을 사용하여 이전 버전으로 다시 전환하면 데이터 및 기능이 손실될 수 있습니다.

사전 요구 사항

  • Kubernetes 3.0.58.0 이상용 Red Hat Advanced Cluster Security를 사용해야 합니다.
  • 롤백을 수행하려면 영구 스토리지에서 사용 가능한 디스크 공간이 있어야 합니다. Red Hat Advanced Cluster Security for Kubernetes는 디스크 공간을 사용하여 업그레이드하는 동안 데이터베이스 복사본을 유지합니다. 디스크 공간이 사본을 저장하기에 충분하지 않고 업그레이드가 실패하면 이전 버전으로 롤백할 수 없습니다.

절차

  • 다음 명령을 실행하여 강제 롤백을 수행합니다.

    • 이전에 설치한 버전으로 강제로 롤백하려면 다음을 수행합니다.

      $ oc -n stackrox rollout undo deploy/central 1
      1
      Kubernetes를 사용하는 경우 oc.. 대신 kubectl 을 입력합니다.
    • 특정 버전으로 강제로 롤백하려면 다음을 수행합니다.

      1. 중앙의 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. 중앙 이미지 버전을 업데이트합니다.

        $ 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 키에 대해 지정한 버전과 동일해야 합니다.

3.6. 업그레이드 확인

업데이트된 센서 및 수집기는 각 보안 클러스터의 최신 데이터를 계속 보고합니다.

Sensor에게 마지막으로 연결된 Central이 RHACS 포털에서 볼 수 있는 시간입니다.

절차

  1. RHACS 포털에서 플랫폼 구성시스템 상태로 이동합니다.
  2. 센서 업그레이드가 중앙으로 최신 클러스터가 표시되는지 확인합니다.

3.7. API 토큰 해지

보안상의 이유로 중앙 데이터베이스 백업을 완료하는 데 사용한 API 토큰을 취소하는 것이 좋습니다.

사전 요구 사항

  • 업그레이드 후 RHACS 포털 페이지를 다시 로드하고 RHACS 포털을 계속 사용하려면 인증서를 다시 수락해야 합니다.

절차

  1. RHACS 포털에서 플랫폼 구성통합 으로 이동합니다.
  2. 인증 토큰 카테고리까지 아래로 스크롤하고 API 토큰 을 클릭합니다.
  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.