스토리지 인증 키 및 인증서 순환

Google Distributed Cloud (GDC) 에어갭 어플라이언스는 ONTAP Select (OTS)를 소프트웨어 정의 스토리지 공급업체로 채택합니다. OTS에는 각 ID (핵심 서비스 또는 클라이언트)에 연결된 이름과 키가 있는 자체 인증 시스템이 있습니다.

이 문서에서는 다음을 위해 실행해야 하는 인증 키와 인증서를 순환하는 단계를 설명합니다.

  • 기기가 규정을 준수하고 안전하도록 정기적으로 예약된 키 순환
  • 키 노출을 방지합니다. 노출된 키는 가능한 한 빨리 순환하는 것이 좋습니다.

시작하기 전에

다음 액세스 권한이 있는지 확인합니다.

  • ONTAP 클러스터에 대한 관리 콘솔 액세스
  • 관리 API 서버의 kubeconfig

IPsec 사용자 인증 정보 (PSK) 순환

ONTAP는 9.10.1부터 IPsec의 인증서 기반 인증을 지원합니다. 이 GDC 버전은 9.14.1에 있으며 사전 공유 키를 사용합니다.

어플라이언스의 경우 IPsec은 두 가지 유형의 OTS 트래픽에 구현됩니다.

  • 베어메탈 호스트와 SVM 간의 외부 트래픽
  • 작업자 노드 간 내부 트래픽

각각 살펴보겠습니다.

기본 요건

  • ONTAP 클러스터에 대한 관리 콘솔 액세스
  • 새 사전 공유 키
  • 관리 API 서버의 kubeconfig
  • StrongSwan 구성을 업데이트하기 위한 호스트 액세스

영향

IPsec 정책이 순환되는 동안 호스트에서 스토리지 시스템으로의 IP 연결이 손실됩니다. 애플리케이션 동작에 따라 연결이 멈추거나 실패할 수 있습니다. 가능한 경우 순환 중에 사용자 워크로드를 일시중지할 수 있지만 필수는 아닙니다. 보안 비밀이 재설정된 후 곧 연결이 복구됩니다.

OTS 외부 트래픽의 키 순환

회전을 검증하려면 다음 명령어를 사용하고 출력을 비교하세요.

export KUBECONFIG= #path to root-admin kubeconfig

kubectl get StorageEncryptionConnections -n gpc-system

출력:

NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR   PRESHAREDKEY                 READY   AGE
bm-1ba9796c   bm-1ba9796c        root-admin              10.4.4.0/24   bm-1ba9796c-pre-shared-key   True    6h16m
bm-96a5f32a   bm-96a5f32a        root-admin              10.4.4.0/24   bm-96a5f32a-pre-shared-key   True    16h
bm-e07f4a4f   bm-e07f4a4f        root-admin              10.4.4.0/24   bm-e07f4a4f-pre-shared-key   True    21h

이전에 스크립트를 실행한 특정 호스트의 READY 필드가 true인지 확인합니다.

유효성 검사 중에 오류가 발견되면 PSK를 수동으로 순환합니다.

  1. 다음 명령어를 실행합니다.

    export KUBECONFIG= #path to root-admin kubeconfig

    mgmt_ip="$(kubectl get storagecluster -A -o jsonpath='{.items[0].spec.network.clusterManagement.ip}')"

username="$(kubectl get secret storage-root-level1 -n gpc-system -o jsonpath='{.data.username}' | base64 -d)"

password="$(kubectl get secret storage-root-level1 -n gpc-system -o jsonpath='{.data.password}' | base64 -d)"

  2. 비밀번호를 확인하고 클립보드에 복사합니다.

    echo $password

  3. ONTAP 콘솔에 로그인합니다.

    ssh $username@$mgmt_ip

    비밀번호를 입력하라는 메시지가 표시되면 이전 단계에서 복사한 비밀번호를 붙여넣습니다.

  4. 사용자 인증 정보 순환에는 다음 스크립트를 사용하세요.

    export KUBECONFIG= #path to root-admin kubeconfig

    kubectl get StorageEncryptionConnections -n gpc-system

    출력:

    NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR   PRESHAREDKEY                 READY   AGE
bm-1ba9796c   bm-1ba9796c        root-admin              10.4.4.0/24   bm-1ba9796c-pre-shared-key   True    6h16m
bm-96a5f32a   bm-96a5f32a        root-admin              10.4.4.0/24   bm-96a5f32a-pre-shared-key   True    16h
bm-e07f4a4f   bm-e07f4a4f        root-admin              10.4.4.0/24   bm-e07f4a4f-pre-shared-key   True    21h

    순환하려는 모든 호스트에 대해 다음을 실행할 수 있습니다.

    export bm_host= //name of bm-host from above
export secret="${bm_host}-pre-shared-key"
export job_name="os-policy-config-host-ipsec-${bm_host}"
export ns="gpc-system"
export svm="$(kubectl get storageencryptionconnections "${bm_host}" -n "${ns}" -o jsonpath='{.spec.storageVirtualMachineRef.name}')"

    이제 스토리지 암호화 연결의 모든 구성요소가 표시되는지 확인합니다. 관리자 클러스터 연결(루트 관리자 또는 조직 관리자)의 경우 루트 관리자 클러스터를 사용해야 합니다.

    kubectl get secrets -n "${ns}" "${secret}"
kubectl get jobs -n "${ns}" "${job_name}"

    이 두 항목이 모두 있으면 다음 단계로 진행할 수 있습니다. 그렇지 않으면 중지하고 ipsec 수정을 진행하지 마세요. 기술 지원팀에 문의하세요.

    kubectl delete secrets -n "${ns}" "${secret}"
kubectl delete jobs "${job_name}" -n "${ns}"

    이제 관리 API 서버를 사용하여 storageencryptionconnection을 삭제합니다.

    export KUBECONFIG= #path to root-admin kubeconfig

    kubectl delete storageencryptionconnections "${bm_host}"

annotation_key="reconcile_annotation_key"
annotation_value="reconcile_annotation_value"

kubectl patch storagevirtualmachines "${svm}" -n "${ns}" --type=merge -p "{\"metadata\":{\"annotations\":{\"$annotation_key\":\"$annotation_value\"}}}"
kubectl patch storagevirtualmachines "${svm}" -n "${ns}" --type=json -p="[{\"op\": \"remove\", \"path\": \"/metadata/annotations/$annotation_key\"}]"

    OTS 내부 트래픽의 키 순환

마찬가지로 회전을 검증하려면 다음 명령어를 사용하고 출력을 비교합니다.

export KUBECONFIG= #path to root-admin kubeconfig

kubectl get secret ots-internal-pre-shared-key -n gpc-system

출력:

NAME                          TYPE     DATA   AGE
ots-internal-pre-shared-key   Opaque   1      18m

kubectl get jobs -n gpc-system | grep os-policy-config-host-ipsec

출력:

os-policy-config-host-ipsec-bm-3d33bb857t5bh                Complete   1/1           17s        10m
os-policy-config-host-ipsec-bm-774fa8e6frgr7                Complete   1/1           30s        11m
os-policy-config-host-ipsec-bm-8e452fb29q5wd                Complete   1/1           23s        11m

모든 작업이 Complete 상태인지 확인합니다.

kubectl get StorageEncryptionConnections -n gpc-system

출력:

NAME          INVENTORYMACHINE   STORAGEVIRTUALMACHINE   STORAGECIDR   PRESHAREDKEY                 READY   AGE
bm-3d33bb85   bm-3d33bb85        root-admin              10.4.4.0/24   bm-3d33bb85-pre-shared-key   True    6h16m
bm-774fa8e6   bm-774fa8e6        root-admin              10.4.4.0/24   bm-774fa8e6-pre-shared-key   True    16h
bm-8e452fb2   bm-8e452fb2        root-admin              10.4.4.0/24   bm-8e452fb2-pre-shared-key   True    21h

READY 필드가 모든 호스트에 대해 true인지 확인합니다.

  1. 나열된 순서대로 2단계의 모든 CR을 삭제합니다.

    • 내부 트래픽 sh kubectl delete secret ots-internal-pre-shared-key -n gpc-system의 보안 비밀 삭제

    • 세 개의 OS 정책 작업 sh kubectl delete jobs os-policy-config-host-ipsec-bm-3d33bb857t5bh -n gpc-system kubectl delete jobs os-policy-config-host-ipsec-bm-774fa8e6frgr7 -n gpc-system kubectl delete jobs os-policy-config-host-ipsec-bm-8e452fb29q5wd -n gpc-system 모두 삭제

    • 세 개의 storageencryptionconnection을 모두 삭제합니다. sh kubectl delete StorageEncryptionConnections bm-3d33bb85-root-admin -n gpc-system kubectl delete StorageEncryptionConnections bm-774fa8e6-root-admin -n gpc-system kubectl delete StorageEncryptionConnections bm-8e452fb2-root-admin -n gpc-system

  2. 몇 분 정도 기다립니다 (약 3~5분). 모든 CR이 READY 또는 Complete 상태가 될 때까지 2단계를 반복합니다.

볼륨 키 회전

이 섹션에서는 OTS 볼륨 사용자 인증 정보를 순환하는 수동 단계를 설명합니다.

시작하기 전에

다음 단계를 완료합니다.

  1. 노트북 기본 요건을 충족하는지 확인합니다.
  2. BM01 또는 BM02를 통해 OTS 클러스터의 콘솔에 로그인할 수 있는지 확인합니다.

볼륨 키 순환 시작

OTS 콘솔에서 일회성 키 순환을 트리거합니다.

volume encryption rekey start -vserver SVM_name -volume volume_name

다음 명령어는 SVMvs1에서 vol1의 암호화 키를 변경합니다.

cluster1::> volume encryption rekey start -vserver vs1 -volume vol1

vserver 및 볼륨의 이름을 보려면 show 명령어를 사용합니다.

vserver show
volume show

볼륨 키 회전 확인

키 순환이 시작된 후 키 재설정 상태를 확인합니다.

volume encryption rekey show

키 재설정 작업의 상태를 표시합니다.

cluster1::> volume encryption rekey show

Vserver   Volume   Start Time           Status
-------   ------   ------------------   ---------------------------
vs1       vol1     9/18/2017 17:51:41   Phase 2 of 2 is in progress.

키 재설정 작업이 완료되면 볼륨에서 암호화가 사용 설정되었는지 확인합니다.

volume show -is-encrypted true

cluster1에 암호화된 볼륨을 표시합니다.

cluster1::> volume show -is-encrypted true

Vserver  Volume  Aggregate  State  Type  Size  Available  Used
-------  ------  ---------  -----  ----  -----  --------- ----
vs1      vol1    aggr2     online    RW  200GB    160.0GB  20%

외부 HSM 인증서 순환

이 섹션에서는 ONTAP의 외부 HSM 인증서를 순환하고 업데이트하는 방법을 설명합니다.

기본 요건

  • ONTAP 클러스터 또는 관련 SVM에 대한 관리 액세스
  • 현재 비밀번호
  • 적절한 클러스터에 대한 kubectl 액세스

안내

  1. 이전 HSM 인증서를 백업합니다.

    kubectl get secret aa-aa-external-hsm-creds -n gpc-system -o yaml > external-hsm-creds-old.yaml

  2. Kubernetes에서 HSM 인증서 보안 비밀을 업데이트합니다.

    1. 이전 비밀번호 yaml 파일을 복사합니다. sh cp external-hsm-creds-old.yaml external-hsm-creds-new.yaml

    2. 서버 CA 인증서, 공개 클라이언트 인증서, 클라이언트의 비공개 키를 포함한 새 HSM 사용자 인증 정보로 새 external-hsm-creds-new.yaml 파일을 업데이트합니다.

    3. 변경사항을 적용하고 HSM 비밀 객체를 업데이트합니다.

      kubectl apply -f external-hsm-creds-new.yaml

  3. ONTAP에서 HSM 인증서를 업데이트합니다.

    1. ONTAP CLI에 로그인합니다.

    2. 새 서버 CA 인증서를 설치합니다.

      cluster::> security certificate install -type server-ca -vserver <>

    3. 새 클라이언트 인증서를 설치합니다.

      cluster::> security certificate install -type client -vserver <>

    4. 새로 설치된 인증서를 사용하도록 키 관리자 구성을 업데이트합니다.

      cluster::> security key-manager external modify -vserver <> -client-cert <> -server-ca-certs <>

검증

  1. 키 관리자 상태로 변경사항을 확인합니다.

    cluster::> security key-manager external show-status

    키 서버가 여전히 Available 상태인지 확인합니다.

스토리지 관리자 사용자 인증 정보 순환

이 섹션에서는 스토리지 관리자 사용자 및 비밀번호를 순환하고 설정하는 방법을 설명합니다.

기본 요건

  • ONTAP 클러스터 또는 관련 SVM에 대한 관리 액세스
  • 현재 비밀번호
  • 적절한 클러스터에 대한 kubectl 액세스

안내

  1. 다음 명령어로 시작한 후 결과 메시지를 따릅니다.

    cluster::> security login password

  2. 다음과 일치하도록 보안 비밀을 업데이트합니다.

    • 옵션 1 (대화형):

      kubectl edit secret -n <netapp_namespace> netapp_credential

      편집기를 사용하여 비밀번호를 새 base64 인코딩 값으로 변경합니다.

    • 옵션 2 (jq 종속 항목으로 패치):

      k get secret -n <netapp_namespace> netapp_credential -o json | jq '.data["password"]="<new-base64-encoded-password>"' | kubectl apply -f -

ONTAP 비상 액세스 사용자 인증 정보 순환

파일 및 블록 스토리지 설정 중에 ONTAP에 직접 액세스하는 데 사용할 수 있는 비상 액세스 사용자 계정 4개가 생성됩니다. 이러한 사용자 인증 정보는 관리 API 서버에서 보안 비밀로 가져올 수 있습니다. 이러한 사용자 인증 정보가 사용되면 순환해야 합니다.

설정 중에 수준 1과 수준 2의 두 가지 유형의 보안 비밀이 생성됩니다. 레벨 1은 storage-root-level1 and storage-root-level1-backup입니다. 레벨 2는 storage-root-level2 and storage-root-level2-backup입니다. 2단계 비밀번호는 안전한 곳에 저장해야 하며 각 단계에는 일반 비밀번호와 백업 비밀번호의 두 가지 비밀번호가 있습니다. 소프트웨어는 일반 보안 비밀과 백업 보안 비밀을 동시에 삭제하지만, 보안을 강화하기 위해 한 번에 이러한 파트너 보안 비밀 중 하나만 순환하는 것이 좋습니다.

1단계 보안 비밀은 90일이 지나면 자동으로 순환되지만 2단계 보안 비밀은 그렇지 않습니다. 이러한 유형의 보안 비밀은 사용하는 경우 다음 프로세스를 사용하여 수동으로 순환해야 합니다.

기본 요건

  • 필요한 액세스 권한: Management API 서버

검증

  1. 보안 비밀이 아직 삭제로 표시되어 있는지 확인하여 보안 비밀 순환을 검증할 수 있습니다. 그렇지 않으면 보안 비밀이 순환된 것입니다. 다음 안내의 1단계를 따라 확인하세요.

  2. 보안 비밀이 레벨 2 보안 비밀인 경우 물리적 미디어에 복사하여 금고에 보관합니다. 그런 다음 보안 비밀이 주석 "disk.gdc.goog/persisted"를 사용하여 지속되도록 표시해야 합니다.

     kubectl annotate secrets
 <secret_name> -n gpc-system disk.gdc.goog/persisted=''

유효성 검사 중에 오류가 발견되면 다음 안내에 따라 시크릿을 수동으로 순환하세요.

안내

  1. 보안 비밀이 삭제 대상으로 표시되었는지 확인합니다.

    1. 다음 명령어를 실행합니다.

      kubectl get secret <secret_name> -n gpc-system -o yaml

    2. 이 예에 따라 deletionTimestamp 필드가 응답에 있으면 비밀번호가 삭제되도록 표시됩니다. 그렇지 않으면 아닙니다.

      apiVersion: v1
data:
  password: KFZbQTJdYjIwSUtVVV1aNytJJVM=
  username: cm9vdC1sdmwy
immutable: true
kind: Secret
metadata:
  annotations:
    cluster-name: aa-aa-stge01
  creationTimestamp: "2022-12-21T05:03:02Z"
  deletionGracePeriodSeconds: 0
  deletionTimestamp: "2022-12-21T14:42:13Z"
  finalizers:
  - ontap.storage.private.gdc.goog/breakglass-finalizer
  labels:
    breakglass-secret: "true"
  name: storage-root-level2
  namespace: gpc-system
  resourceVersion: "591897"
  uid: 6f331f8a-bf48-4d59-9725-6c99c5e766f7
type: Opaque

  2. ONTAP에 액세스하는 데 사용한 후 보안 비밀을 순환합니다.

    1. 파트너 사용자 인증 정보가 존재하고 삭제로 표시되지 않았는지 확인합니다. 삭제로 표시된 경우 계속 진행하지 말고 나중에 이 단계로 돌아오세요.

    2. 2단계 보안 비밀이 순환되는 경우 파트너 보안 비밀은 disk.gdc.goog/persisted 주석을 추가하여 지속된 것으로 표시해야 합니다.

      kubectl annotate secrets
<secret_name> -n gpc-system disk.gdc.goog/persisted=''

    3. 다음을 사용하여 클러스터에서 보안 비밀을 삭제합니다.

      kubectl delete
secret <secret_name> -n gpc-system

    4. 이 시점에서 삭제 프로세스가 시작됩니다 (보안 비밀이 삭제 대상으로 표시되었는지 확인하여 확인할 수 있음). 보안 비밀이 삭제되고 재생성되는 데 1시간 가까이 걸릴 수 있습니다.

스토리지 관리자 및 SVM 인증서 순환

이러한 인증서는 GDC에서 ONTAP 시스템에 설치한 서버 인증서입니다.

스토리지 관리자(클러스터 관리자 계정이라고도 함)용 인증서가 하나 있습니다. 이름에는 ONTAP 시스템의 호스트 이름이 프리픽스로 추가되고 고유한 해시가 후행합니다. 클러스터 관리자 vserver에 설치됩니다. GDC는 관리 작업에 이 인증서를 내부적으로 사용합니다.

ONTAP SVM에 정의된 서버 측 인증서도 여러 개 있습니다. 이는 SVM과 통신하는 클라이언트의 진위성을 설정합니다.

모든 인증서는 동일한 프로세스를 사용하여 순환할 수 있습니다. 루트 관리자 클러스터의 루트 CA 인증서가 일치하지 않기 때문에 다음 표에 나열된 클러스터 및 SVM 인증서의 경우 순환하려면 해당 목록 내의 모든 인증서를 순환해야 합니다. 즉, 클러스터 인증서를 순환해야 하는 경우 다른 모든 클러스터 인증서도 순환해야 합니다. SVM 인증서에도 동일하게 적용됩니다. 자동 인증서 관리가 구현되면 이 제한사항이 해결됩니다.

기본 요건

  • ONTAP 클러스터 또는 관련 SVM에 대한 관리 액세스
  • 적절한 Kubernetes 클러스터에 대한 kubectl 액세스
  • 클라이언트-CA 인증서 설치 단계에 설명된 대로 client-ca 인증서를 다시 설치합니다.

인증서와 Kubernetes 보안 비밀 간 매핑

ONTAP에 설치된 각 인증서에는 인증서 세부정보가 포함된 Management API 서버의 해당 Kubernetes 보안 비밀이 있습니다. GDC는 인증서를 생성하며 인증서 교체 프로세스는 간단합니다. 지정된 인증서에 해당하는 보안 비밀을 삭제하면 인증서가 즉시 재생성됩니다. 그런 다음 새 인증서를 ONTAP에 수동으로 설치하여 기존 인증서를 대체할 수 있습니다.

kubectl get secrets -n <namespace> -s <secret> -o yaml를 사용하여 Kubernetes의 인증서를 검사하고 security certificate show -vserver <svm_name>에서 확인한 ONTAP의 세부정보와 일치하는지 확인합니다. 네임스페이스는 항상 'gpc-system'이며, 보안 비밀 이름은 위의 표를 참고하세요.

다음을 확인하여 인증서와 보안 비밀의 매핑을 확인할 수도 있습니다.

kubectl get certificates -n <namespace>

관련 클러스터 인증서

ONTAP 일반 이름 Vserver K8S 인증서 이름 Kubernetes 보안 비밀 이름 설명
해당 사항 없음 <hostname> <hostname>-admin-cert <hostname>-admin-cert-secret 클러스터 관리자 인증서
해당 사항 없음 <hostname> <hostname>-server-cert <hostname>-server-cert-secret ONTAP 서버 인증서로 사용되는 GDC 발급자가 서명한 서버 인증서
해당 사항 없음 <hostname> <hostname>-read-only-cert <hostname>-read-only-cert-secret 읽기 전용 모니터링 액세스

관련 SVM 인증서

Vserver K8S 인증서 이름 Kubernetes 보안 비밀 이름 설명
root-admin root-admin-server-cert root-admin-server-cert-secret SVM 서버 인증서로 사용되는 GDC 발급기관에 의해 서명된 서버 인증서
root-admin root-admin-s3-server-cert root-admin-s3-server-cert-secret ONTAP S3 서버 인증서로 사용되는 GDC 발급자가 서명한 서버 인증서
root-admin root-admin-client-cert root-admin-client-cert-secret SVM 관리자 액세스
root-admin root-admin-s3-identity-client-cert root-admin-s3-identity-client-cert-secret S3 ID 액세스

검증

Vserver 인증서

모든 인증서를 교체한 후 교체된 서버 인증서와 연결된 모든 클러스터에 대해 Trident 백엔드가 여전히 성공적으로 연결되어 있는지 확인합니다.

  1. 다음을 실행합니다.

    export KUBECONFIG= #path to root-admin kubeconfig

    kubectl get tridentbackendconfigs -n netapp-trident

    출력은 다음과 같이 표시됩니다.

    NAME                                   BACKEND NAME   BACKEND UUID                           PHASE   STATUS
netapp-trident-backend-tbc-ontap-san   iscsi-san      a46ce1c7-26da-42c9-b475-e5e37a0911f8   Bound   Success

  2. PHASE가 Bound이고 Status가 Success인지 확인합니다.

루트 관리자 인증서

관리자 인증서를 테스트하기 위해 새 테스트 StorageVirtualMachine을 만들고 GDC가 이를 적절하게 조정할 수 있는지 확인할 수 있습니다. 단계는 다음과 같습니다.

  1. 기존 StorageVirtualMachine을 나열하고 테스트로 클론할 항목을 선택합니다.
  2. Kubernetes 사양을 추출합니다.
  3. 정의를 수정하여 이름을 변경하고 불필요한 필드를 삭제합니다.
  4. 테스트 정의를 적용합니다.
  5. StorageVirtualMachine 상태가 Ready이 될 때까지 기다립니다.
  6. 테스트 StorageVirtualMachine을 삭제합니다.
  7. ONTAP에서 실제 SVM을 삭제합니다.

예

이 예시에서는 GDC NetApp 네임스페이스 gpc-system를 사용하고 organization-root-user을 새 SVM인 test-svm에 일시적으로 클론합니다.

  1. SVM을 나열합니다.

    kubectl get storagevirtualmachines -n ngpc-system

    출력:

    NAME                      AGE
organization-root-admin   13d

  2. 사양을 추출합니다.

    kubectl get storagevirtualmachines -n gpc-system -o yaml > svm.yaml

  3. 다음과 비슷하게 사양을 수정합니다.

    apiVersion: system.gpc.gke.io/v1alpha1
kind: StorageVirtualMachine
metadata:
  labels:
    ontap.storage.gpc.gke.io/role: user
  name: test-svm
  namespace: netapp-alatl12-gpcstge02
spec:
  aggregates:
  - alatl12-gpcstge02-c1-aggr1
  - alatl12-gpcstge02-c2-aggr1
  clusterName: alatl12-gpcstge02
  iscsiTarget:
    port: a0a-4
    subnetName: root-svm-data
  nasServer:
    port: a0a-4
    subnetName: root-svm-data
  svmNetwork:
    port: e0M
    subnetName: Default

  4. 클러스터에 적용합니다.

    kubectl create -f svm.yaml

  5. 새 SVM이 준비될 때까지 기다립니다. 다음의 출력을 주기적으로 관찰합니다.

    kubectl get storagevirtualmachines -n gpc-system test-svm

    성공은 다음으로 표시됩니다.

      Conditions:
    Last Transition Time:  2022-03-30T21:30:27Z
    Message:
    Observed Generation:   1
    Reason:                SVMCreated
    Status:                True
    Type:                  Ready

    또는 AnsibleJobSucceed입니다.

  6. SVM 리소스를 삭제합니다.

    kubectl delete storagevirtualmachines -n gpc-system test-svm

  7. ONTAP에서 완전히 삭제합니다. 리소스를 삭제해도 ONTAP에서 삭제되지는 않습니다.

    NetApp 콘솔에 로그인하고 SVM을 삭제합니다.

    alatl12-gpcstge02::> vserver delete test-svm

    출력:

    Warning: When Vserver "test-svm" is deleted,
        the following objects are automatically removed as well:
        LIFs: 7
        Routes: 2
        Admin-created login accounts: 2
        Do you want to continue? {y|n}: y
[Job 3633] Success

유효성 검사 중에 오류가 발견되면 다음 안내에 따라 ONTAP 인증서를 수동으로 순환하세요.

안내

이전 ONTAP 인증서 이름을 적용할 수 없는 경우 ONTAP에서 로테이션할 필요가 없습니다. Kubernetes에서 인증서와 보안 비밀을 검사하고 보안 비밀을 삭제합니다.

  1. 앞의 표를 참조하여 보안 비밀 이름을 지정하여 새 인증서를 생성합니다.

    kubectl get certificates -n <namespace>

    $ kubectl patch Certificates <cert_name> -n gpc-system \
 --type=merge -p "{\"spec\":{\"privateKey\": {\"rotationPolicy\": \"Always\"}}}"
$ kubectl delete secret -n <namespace> <secret_name>

  2. 특정 vserver에 설치된 인증서를 확인합니다 (해당하지 않는 것으로 표시되지 않은 ONTAP에 설치된 인증서의 경우).

    cluster::> security certificate show -vserver <svm_name> -type server

  3. Kubernetes에서 일치하는 보안 비밀을 검사합니다 (이전 표 참고).

    kubectl get certificates -n <namespace>

  4. 일치하는 항목이 있으면 보안 비밀을 삭제하여 새 인증서를 생성합니다.

    kubectl delete secret -n <namespace> <secret_name>

  5. 보안 비밀을 다시 검사하여 새 인증서가 재생성되었는지 확인합니다. 확인되면 ONTAP에서 새 서버 인증서를 만듭니다. 'server-cert' 접미사가 있는 이전 인증서에 대해서만 다음 단계를 실행하세요.

  6. kubectl 및 기타 도구를 사용하여 새 TLS 인증서 본문을 직접 추출하고 ONTAP에 설치합니다.

    $ gdch_cert_details -n <namespace> -s <secret_name>

cluster::> security certificate install -vserver <svm_name> -type server

    첫 번째 프롬프트는 다음과 같습니다.

    Please enter Certificate: Press <Enter> when done

    여기에 tls.crt을 입력해야 합니다. tls.crt에 인증서 블록이 여러 개 있는 경우 첫 번째 블록을 입력하고 나머지 인증서 블록은 다음 단계에서 참조할 중간 인증서로 유지합니다.

  7. 시스템에 Please enter Private Key: Press <Enter> when done라는 메시지가 표시됩니다. tls.key 파일의 내용을 붙여넣고 Enter 키를 누릅니다.

    다음과 같은 메시지가 표시됩니다. Do you want to continue entering root and/or intermediate certificates {y|n}: tls.crt 파일에 인증서가 하나만 포함된 경우 N를 입력하고 Enter 키를 누릅니다. 그렇지 않으면 Y를 입력하고 Enter 키를 누릅니다.

    Y를 입력한 경우: 중간 인증서를 입력하라는 메시지가 표시됩니다. tls.crt 파일에서 한 번에 하나씩 붙여넣고, 입력할 때마다 Enter 키를 누릅니다. 마지막으로 ca.crt 파일에서 루트 인증서를 붙여넣고 Enter 키를 누릅니다.

    N를 입력한 경우: (이 프롬프트에서 인증서와 관련해 추가 조치가 필요하지 않음)

    그러면 ONTAP에서 일련번호를 반환합니다. 이 번호는 새 인증서와 CA의 일련번호를 나타내므로 기록해 둡니다. 이 일련번호는 후속 단계에서 <new\_server\_serial> 및 <new\_ca>로 참조됩니다. S3 서버 인증서를 구성하는 경우 이러한 인증서 단계를 따르지 마세요.

  8. vserver 및 클러스터의 ssl 구성의 현재 상태를 확인합니다. 서버 인증서 발급 CA, 서버 인증서 일반 이름, 서버 인증서 일련번호를 준비해 두세요. 각각 <old\_server\_common\_name>, <old\_ca>, <old\_server\_serial>로 참조됩니다.

    cluster::> security ssl show -vserver <vserver>

    이렇게 하면 이전 서버 인증서 정보와 함께 SSL 정보가 반환됩니다. 나중에 SSL 구성을 수정한 후 이 정보를 참조하여 업데이트되었는지 확인할 수 있습니다.

  9. SSL 구성을 수정합니다.

    cluster::> security ssl modify -server-enabled -client-enabled true -vserver <svm_name> -serial <new_server_serial> -ca <new_ca>

  10. vserver 및 클러스터의 ssl 구성의 새 상태를 확인합니다. 이제 설치된 서버 인증서의 업데이트된 일련번호가 있어야 합니다.

    cluster::> security ssl show -vserver <vserver>

  11. 이전 단계를 확인한 후 이전 서버 인증서를 삭제합니다.

    cluster::> security certificate delete -vserver <svm_name> -common-name <old_server_common_name> -ca <old_ca> -type server -serial <old_server_serial>

클라이언트-CA 인증서

  1. 다음 명령어를 사용하여 gpc-system 네임스페이스의 trust-store-internal-only ConfigMap에서 모든 CA 인증서를 가져옵니다.

    kubectl get cm -n gpc-system trust-store-internal-only -o jsonpath='{.data.ca\.crt}'

  2. 이전 단계에서 가져온 각 CA 인증서에 대해 ONTAP 클러스터에서 다음 명령어를 실행합니다.

    cluster::> security certificate install -vserver <svm_name> -type client-ca

    다음과 같은 메시지가 표시됩니다. Please enter Certificate: Press <Enter> when done. 1단계에서 가져온 각 인증서 블록을 붙여넣고 Enter 키를 누릅니다. 각 CA 인증서에 대해 이 설치 명령어를 반복합니다.

수집 인증서 순환

수집 인증서 생성은 <hostname>-read-only-cert-secret에 따라 다릅니다. 계속하기 전에 <hostname>-read-only-cert-secret이(가) 순환되었는지 확인합니다.

  1. Harvest 포드에 설치된 인증서를 확인합니다.

    export KUBECONFIG= #path to root-admin kubeconfig

    cluster_name="$(kubectl get storagecluster -A -o jsonpath='{.items[0].metadata.name}')"
secret_name="$cluster_name"-read-only-cert-secret

    export TLS_CRT="$(kubectl get secret -n gpc-system $secret_name -o jsonpath='{.data.tls\.crt}')"

    export TLS_KEY="$(kubectl get secret -n gpc-system $secret_name -o jsonpath='{.data.tls\.key}')"

    export CA_CRT="$(kubectl get secret -n gpc-system $secret_name -o jsonpath='{.data.ca\.crt}')"

  2. 업데이트된 인증서를 제공하도록 수집 사용자 인증 정보 보안 비밀을 패치합니다.

    $ kubectl patch secret \
-n gpc-system netapp-harvest-configuration-credential \
-p "{\"data\":{\"tls.crt\":\"${TLS_CRT:?}\",\"tls.key\":\"${TLS_KEY:?}\",\"ca.crt\":\"${CA_CRT:?}\"}}"

  3. Harvest 서비스를 다시 시작하여 업데이트된 구성을 로드합니다.

    kubectl delete pod -n gpc-system -l 'app=harvest.netapp.io'

파일 시스템 인증서 순환

다음 명령어를 실행하여 file-storage-webhooks-serving-cert 및 file-observability-backend-target-cert 인증서를 재생성합니다.

kubectl delete secret file-storage-webhooks-serving-cert -n file-system
kubectl delete secret file-observability-backend-target-cert -n file-system

업데이트된 구성을 로드하려면 포드를 다시 시작합니다.

kubectl delete pod -n file-system -l 'app=file-observability-backend-controller'
kubectl delete pod file-storage-backend-controller -n file-system

Trident 및 ONTAP 인증서 순환

Trident는 ONTAP와 통신해야 합니다. 이는 이전에 정의된 클라이언트 인증서 <svm\_name>-client-cert-secret>를 사용하는 Trident 백엔드로 구성됩니다. 클라이언트 인증서 순환은 Trident의 일부가 아니지만 Trident는 이 인증서의 일부를 사용하므로 업데이트해야 합니다.

안내

CA 인증서 업데이트:

  1. KUBECONFIG를 내보내 문제의 Trident 구성요소와 관련된 클러스터의 kubeconfig를 가리킵니다. 각 클러스터에는 Trident가 구성되어 있습니다.

  2. client-cert 보안 비밀에서 base64로 인코딩된 ca 인증서를 가져와 변수로 저장합니다.

    ca_cert=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.ca\.crt}')

  3. tridentBackendConfig 객체에 패치를 적용합니다.

    kubectl patch tridentBackendConfigs netapp-trident-backend-tbc-ontap-san -n netapp-trident --type=merge -p "{\"spec\":{\"trustedCACertificate\":\"$ca_cert\"}}"

실제 클라이언트 인증서 및 키의 경우:

  1. client-cert 보안 비밀에서 base64로 인코딩된 TLS 인증서를 가져와 변수로 저장합니다.

    tls_cert=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.tls\.crt}')

  2. client-cert 보안 비밀에서 tls 키를 가져와 base64로 이중 인코딩하고 변수로 저장합니다.

    tls_key=$(kubectl get secrets -n "${ns}" "${secret}" -o jsonpath='{.data.tls\.key}' | base64 -w 0)

  3. 비공개 키로 백엔드 보안 비밀을 업데이트합니다.

    kubectl patch secrets netapp-trident-backend-tbc-ontap -n netapp-trident --type=merge -p "{\"data\":{\"clientPrivateKey\": \"$tls_key\"}}"

  4. TLS 인증서로 백엔드 구성을 패치합니다.

    kubectl patch tridentBackendConfigs netapp-trident-backend-tbc-ontap-san -n netapp-trident --type=merge -p "{\"spec\":{\"clientCertificate\":\"$tls_cert\"}}"

Trident 컨트롤러 인증서 순환

Trident 컨테이너는 Trident Operator와 통신해야 합니다. 이 통신은 HTTP를 통해 이루어지며 서버 및 클라이언트 인증서를 이 통신의 일부로 관리해야 합니다.

검증

daemonset과 deployment (해당하는 경우)가 모두 정상 상태로 표시되는지 확인합니다.

유효성 검사 중에 오류가 발견되면 다음 안내에 따라 서버 및 클라이언트 인증서를 수동으로 순환합니다.

안내

서버 및 클라이언트 인증서 모두 ONTAP 측에 해당 인증서가 없습니다. 이러한 데이터는 클러스터에만 포함됩니다.

  1. 만료되는 인증서에 해당하는 비밀을 삭제합니다.

    kubectl delete secret -n netapp-trident <secret_name>

  2. netapp-trident-csi daemonset를 다시 시작합니다.

    kubectl rollout restart daemonset netapp-trident-csi -n netapp-trident

  3. 서버 인증서 순환의 경우 netapp-trident-csi 배포도 다시 시작해야 합니다.

    kubectl rollout restart deployments netapp-trident-csi -n netapp-trident

Trident CA 인증서

CA 인증서는 Trident 서버 및 클라이언트 인증서에 서명하기 위한 인증 기관을 제공하는 데 사용됩니다.

인증서 이름 네임스페이스 보안 비밀 설명
netapp-trident-csi-cert netapp-trident netapp-trident-csi-cert Trident CA 인증서

검증

보안 비밀이 재생성됩니다. 클라이언트 및 서버 인증서가 적용되도록 하려면 이 인증서를 순환한 후 위의 안내에 따라 Trident 컨트롤러 인증서를 순환하면 됩니다.

유효성 검사 중에 오류가 발견되면 다음 안내에 따라 CA 인증서를 수동으로 순환하세요.

안내

이 키를 순환하려면 Kubernetes에서 보안 비밀을 삭제하기만 하면 됩니다.

kubectl delete secret -n netapp-trident <secret_name>

Trident CSI 노드 및 SVM (데이터)

이는 블록 액세스를 위해 데이터 플레인에 대한 액세스를 사용 설정하는 SVM 전체 iSCSI CHAP 사용자 인증 정보 집합입니다. 파일 프로토콜에는 적용되지 않습니다.

관리 API 서버

네임스페이스 보안 비밀 설명
gpc-system <organization>-<type>-svm-credential Trident 설정에 필요한 SVM 구성

조직 관리자 및 관리 API 서버

네임스페이스 보안 비밀 설명
gpc-system <organization>-<type>-svm-credential Trident 설정에 필요한 SVM 구성
netapp-trident netapp-trident-backend-tbc-ontap Trident 백엔드를 관리하는 데 필요한 보안 비밀

검증

  1. 백엔드가 여전히 성공적으로 구성되어 있는지 확인합니다.

    #export kubeconfig of org cluster
export KUBECONFIG= #path to root-admin kubeconfig

kubectl get tridentBackendConfigs -n netapp-trident

  2. 백엔드 상태가 Success인지 확인합니다.

유효성 검사 중에 오류가 발견되면 다음 안내에 따라 보안 비밀을 수동으로 순환하세요.

안내

시작자 비밀번호와 타겟 시작자 비밀번호 모두에 특수문자가 없는 길이 16의 새 임의 문자열을 생성합니다.

#export kubeconfig of Management API server
export KUBECONFIG= #path to root-admin kubeconfig

initiator_secret=$(head /dev/random | tr -dc A-Za-z0-9 | head -c16 | base64)

target_secret=$(head /dev/random | tr -dc A-Za-z0-9 | head -c16 | base64)

kubectl patch secrets -n gpc-system "$org-$type-svm-credential" --type=merge -p "{\"data\":{\"initiatorSecret\": \"$initiator_secret\", \"targetSecret\": \"$target_secret\"}}"

#export kubeconfig of org cluster
export KUBECONFIG= #path to root-admin kubeconfig

kubectl patch secrets -n netapp-trident netapp-trident-backend-tbc-ontap --type=merge -p "{\"data\":{\"chapInitiatorSecret\": \"$initiator_secret\", \"chapTargetInitiatorSecret\": \"$target_secret\"}}"

Trident AES 키

AES 키는 Trident가 Trident의 내부 사용을 위해 iSCSI CHAP 사용자 인증 정보를 암호화하는 데 내부적으로 사용됩니다. 길이가 32바이트여야 하는 임의 문자 시퀀스입니다.

Trident를 실행하는 클러스터 (루트/조직 관리자/사용자/시스템 클러스터일 수 있음)

네임스페이스 보안 비밀 설명
netapp-trident netapp-trident-aes-key Trident가 iSCSI CHAP 사용자 인증 정보를 암호화하는 데 필요한 AES 키

검증

  1. 백엔드가 여전히 성공적으로 구성되어 있는지 확인합니다.

    #export kubeconfig of org cluster
export KUBECONFIG= #path to root-admin kubeconfig

kubectl get tridentBackendConfigs -n netapp-trident

  2. 백엔드 상태가 Success인지 확인합니다.

  3. 테스트 볼륨을 만들려고 시도합니다.

    1. pvc 정보가 포함된 YAML 파일을 만듭니다.

      echo "
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard-rwo" > pvc.yaml

    2. Kubernetes 클러스터에 적용합니다.

      kubectl apply -f pvc.yaml

  4. iSCSI 암호화로 인해 CSI 로그에 오류가 없는지 확인합니다.

    kubectl logs deploy/netapp-trident-csi -n netapp-trident -c trident-main | grep "Error encrypting"

    오류가 없으면 반환된 로그가 표시되지 않습니다.

  5. 파일 및 PVC 정리:

    kubectl delete -f pvc.yaml
rm -f pvc.yaml

유효성 검사 중에 오류가 발견되면 다음 안내에 따라 키를 수동으로 순환하세요.

안내

이 키를 순환하기 전에 클러스터에 PV가 있는 대기 중인 포드가 없는지 확인하세요. 있는 경우 완전히 프로비저닝될 때까지 기다린 후 키를 순환합니다.

aesKey에 특수 문자가 없는 길이 32의 새 무작위 문자열을 생성합니다.

#export kubeconfig of org cluster
export KUBECONFIG= #path to root-admin kubeconfig

aes_key=$(head /dev/random | tr -dc A-Za-z0-9 | head -c32 | base64)

#save old key just in case of errors
old_key=$(kubectl get secrets -n netapp-trident "netapp-trident-aes-key" -o jsonpath='{.data.aesKey}')

kubectl patch secrets -n netapp-trident "netapp-trident-aes-key" --type=merge -p "{\"data\":{\"aesKey\": \"$aes_key\"}}"

kubectl rollout restart deployment netapp-trident-csi -n netapp-trident

롤백

  1. 오류가 있는 경우 마지막으로 사용한 사용자 인증 정보로 롤백합니다.

    kubectl patch secrets -n netapp-trident "netapp-trident-aes-key" --type=merge -p "{\"data\":{\"aesKey\": \"$old_key\"}}"

kubectl rollout restart deployment netapp-trident-csi -n netapp-trident

  2. 인증 단계를 다시 실행합니다.