Google Distributed Cloud (GDC) 에어 갭 적용 어플라이언스 객체 스토리지는 OTS (ONTAP Select)에서 제공합니다. OTS에는 자체 객체 스토리지 사용자 관리 시스템이 있습니다. 각 OTS 객체 스토리지 사용자 인증 정보는 클러스터에 보안 비밀로 저장됩니다.
이 문서에서는 OTS 객체 스토리지 사용자 인증 정보를 순환하는 단계를 설명합니다. 다음과 같은 상황에서는 객체 스토리지 사용자 인증 정보를 순환하세요.
- 모든 사용자 키를 순환하기 위해 정기적으로 예약된 키 순환
- 키 노출을 완화합니다. 노출된 사용자 키는 가능한 한 빨리 순환해야 합니다.
시작하기 전에
다음 단계를 완료합니다.
- 노트북 기본 요건을 충족하는지 확인합니다.
- OTS 클러스터에 로그인하고
vserver object-store-serverCLI 명령어를 실행할 수 있는지 확인합니다. kubectl를 사용하여 인프라 클러스터와 관리 클러스터에 관리자로 로그인할 수 있는지 확인합니다.
UID 번역
각 객체 스토리지 사용자에게는 Kubernetes 보안 비밀로 저장되고 Kubernetes 워크로드가 백엔드 객체 스토리지에 액세스하는 데 사용되는 액세스 키와 보안 비밀 키가 있습니다. 사용자 키를 순환하면 모든 보안 비밀이 업데이트됩니다.
다음 명령어를 사용하여 세 노드 중 하나에 로그인하여 객체 스토리지 사용자 목록을 가져올 수 있습니다.
vserver object-store-server user show
출력은 UID 목록이며 다음과 비슷합니다.
[
"root",
"k8ssa_gpc-system_inventory-export-images",
"k8ssa_gpc-system_inventory-export-hardware",
"k8su_test-user@example.com"
]
사용자에는 세 가지 유형이 있습니다.
| UID | 사용자 유형 | 보안 비밀 이름 | 보안 비밀 네임스페이스 |
|---|---|---|---|
| 루트 | 시스템 관리자 | objectstorage-tenant-bucket-controller-standard-system-s3-sa | gpc-system |
| objectstorage-tenant-bucket-controller-standard-user-s3-sa | |||
| objectstorage-tenant-bucket-controller-nearline-user-s3-sa | |||
| k8ssa_<namespace>_<sa> | Kubernetes 서비스 계정 | object-storage-key-std-sa-<encoded-sa> | <namespace> |
| k8su_<username> | Kubernetes 사용자 | object-storage-key-std-user-<encoded-username> | object-storage-access-keys |
root 사용자는 데이터 센터의 구조를 반영하는 동일한 보안 비밀을 3개 보유하고 있습니다. 데이터 센터는 여러 스토리지 클래스와 테넌트 카테고리를 포함합니다. 반면 어플라이언스에는 단일 객체 스토리지 계층만 있습니다. 루트 사용자와 연결된 세 가지 비밀번호 모두를 동시에 순환해야 합니다.
root 사용자를 제외한 사용자 식별자 (UID)는 k8ssa_<namespace>_<sa> 또는 k8su_<username> 형식을 따라야 합니다. <encoded-sa> 또는 <encoded-username>을 가져옵니다.
echo -n 'UID_SUFFIX' | shasum -a 256 | cut -d " " -f 1 | xxd -r -p | base32 | awk '{print tolower($0)}' | sed 's/=*$//g'
UID에서 UID_SUFFIX를 <sa>로 바꾸면 <encoded-sa>가 됩니다.
UID에서 UID_SUFFIX를 <username>로 바꾸면 <encoded-username>가 됩니다.
사용자 키 순환
OTS 클러스터에 로그인합니다.
객체 스토리지 사용자 UID 목록을 가져옵니다.
vserver object-store-server user show결과는 UID 목록입니다. 예는 UID 변환에서 확인할 수 있습니다. 목록에 있는 각 UID에 대해 다음 단계를 반복합니다.
타겟 사용자의 이전 액세스 키와 보안 비밀 키를 가져옵니다.
set -privilege advanced vserver object-store-server user show -user UIDUID를 타겟 사용자 UID로 바꿉니다.객체 스토리지에서 대상 사용자의 새 액세스 키와 보안 비밀 키를 생성합니다. 이 단계를 거치면 이전 키와 새 키가 공존하며 둘 다 액세스에 사용할 수 있습니다.
vserver object-store-server user regenerate-keys -vserver root-admin -user UID새 액세스 키와 보안 비밀 키로 Kubernetes 보안 비밀을 업데이트합니다. 루트 인프라 클러스터 또는 관리 클러스터에서만 보안 비밀을 업데이트하면 됩니다. 필요한 경우 보안 비밀이 다른 클러스터로 전파됩니다.
kubectl --kubeconfig KUBECONFIG patch secret -n SECRET_NAMESPACE SECRET_NAME --type='json' -p='[{"op": "replace", "path": "/data/access-key-id", "value": "'"$(echo -n "ACCESS_KEY" | base64)"'"}, {"op": "replace", "path": "/data/secret-access-key", "value": "'"$(echo -n "ACCESS_KEY" | base64)"'"}]'다음을 바꿉니다.
KUBECONFIG: kubeconfig의 경로입니다. API 서버는root사용자의 컨트롤 플레인 API 서버여야 합니다. 그렇지 않은 경우 관리 API 서버여야 합니다.SECRET_NAME: UID 변환 섹션에서 파생될 수 있는 사용자의 보안 비밀 이름입니다. 사용자에게 여러 Kubernetes 보안 비밀이 있는 경우 (예:root사용자)를 각 보안 비밀 이름으로 바꿔 명령어를 실행합니다.SECRET_NAMESPACE: UID 변환 섹션에서 파생될 수 있는 사용자 보안 비밀 네임스페이스입니다.ACCESS_KEY: 이전 단계에서 생성된 새 액세스 키입니다.SECRET_KEY: 이전 단계에서 생성된 새 보안 비밀 키입니다.
보안 비밀을 사용하는 워크로드는 자동으로 새로고침되도록 구현해야 합니다. 그렇지 않으면 시크릿의 변경사항을 반영하기 위해 워크로드를 다시 시작해야 합니다.
예를 들어
root사용자의 경우 인프라 클러스터에서 다음 워크로드를 다시 시작해야 합니다.kubectl --kubeconfig KUBECONFIG rollout restart deployment obj-bucket-cm-backend-controller -n obj-system
검증
객체 스토리지 버킷 만들기 및 객체 업로드 및 다운로드에 따라 새 버킷을 만들고 RBAC를 사용하여 액세스 권한을 부여합니다. 버킷이 성공적으로 생성되고 주체에 버킷에 액세스하는 데 필요한 권한이 있는 경우 객체 스토리지 키 순환이 완료된 것입니다.