Hashicorp Vault에서 Cassandra 사용자 인증 정보 순환

개요

이 절차에서는 Hashicorp Vault 내에서 Cassandra 사용자 인증 정보를 순환하는 방법을 설명합니다. 클러스터의 Kubernetes 보안 비밀에서 사용자 인증 정보를 순환하는 방법은 Kubernetes 보안 비밀에서 Cassandra 사용자 인증 정보 순환을 참조하세요.

이 기능을 사용하면 플랫폼 관리자가 다음을 수행할 수 있습니다.

Hashicorp Vault에서 Cassandra 사용자 인증 정보를 순환합니다.
비밀번호 순환 중 문제가 발생하면 Vault에 있는 이전 Cassandra 사용자 인증 정보로 롤백합니다.
한 번에 하나의 리전에 대해 Cassandra 비밀번호를 순환하여 서비스 가용성에 대한 영향을 최소화하고 순환 프로세스를 효율적으로 제어할 수 있습니다.
단일 리전의 순환 시작, 진행률 및 완료를 추적합니다.

이 기능은 Apigee Hybrid 1.13.1 이상에서 제공됩니다.

시작하기 전에

사용자 인증 정보 순환을 설정하기 전

Cassandra 데이터베이스를 백업합니다. 이 백업은 순환 전 사용자 인증 정보를 복원할 수 있도록 하기 위한 것입니다.
클러스터가 정상 상태인지 확인합니다(즉, 모든 Apigee 리소스가 실행 중이고 대기 중인 상태 변경사항이 없음).

참고: 사용자 인증 정보 순환을 설정하려면 클러스터 내에서 kubectl apply -f 실행 권한이 있어야 합니다.

단일 리전 설정

새 Cassandra 사용자 인증 정보에 대해 Apigee 네임스페이스에 새로운 SecretProviderClass Kubernetes 리소스를 만듭니다. 사용할 템플릿은 Hashicorp Vault에 Cassandra 보안 비밀 저장을 참조하세요. 이렇게 하면 Vault 역할이 Kubernetes 네임스페이스 내의 보안 비밀에 액세스할 수 있습니다.
다음 템플릿을 사용하여 새 SecretRotation 커스텀 리소스를 만듭니다.
```
# rotation.yaml

apiVersion: apigee.cloud.google.com/v1alpha1
kind: SecretRotation
metadata:
  name: ROTATION_PROCESS_NAME
  namespace: APIGEE_NAMESPACE
spec:
  organizationId: ORG_NAME
  rotationId: ROTATION_ID
  timeoutMinutes: 480 # optional. overrides the default (480m == 8hr).
                      # less than or equal to 0 means infinite timeout.
  precheck: true
  cassandra:
    oldSecretProviderClass: OLD_SPC_NAME
    newSecretProviderClass: NEW_SPC_NAME
    jobType: ROTATE
```
- ROTATION_PROCESS_NAME: 순환 작업의 고유 이름입니다. 순환 사전 확인 작업 및 순환 작업에 대해 metadata.name을 고유한 값으로 설정해야 합니다. 예를 들어 sr-1-precheck 다음에 sr-1과 같이 설정할 수 있습니다.
- ROTATION_ID: spec.rotationId를 커스텀 식별자(예: rotation-1-precheck)로 설정합니다.
- NEW_SPC_NAME: spec.cassandra.newSecretProviderClass를 이전 단계에서 만든 새로운 보안 비밀 제공자 클래스 이름으로 설정합니다.
- OLD_SPC_NAME: spec.cassandra.oldSecretProviderClass를 ApigeeDatastore에서 현재 사용 중인 SPC 이름으로 설정합니다.
rotation.yaml 파일을 적용하여 순환 사전 확인 작업을 트리거합니다.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```

사전 확인 작업이 완료되었을 때 확인할 작업 상태를 확인합니다.

kubectl -n APIGEE_NAMESPACE get job sr-(rotationId)-(rotate|rollback|cleanup)-job

순환 사전 확인 작업이 완료되면 metadata.name 값을 변경하고 spec.precheck를 false로 설정합니다. 파일을 다시 적용하여 순환을 수행합니다.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
순환 작업이 완료되고 트래픽이 계속 올바르게 작동하는지 확인되었으면 다음 두 단계에 따라 프로세스를 정리합니다.
1. metadata.name의 값을 업데이트하고 spec.cassandra.jobType을 CLEANUP으로 설정합니다.
2. 파일을 적용하여 정리 작업을 트리거합니다.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
  참고: 이 단계까지는 롤백을 트리거하여 순환 프로세스를 되돌리고 클러스터를 원래 상태로 둘 수 있습니다.
정리 작업이 끝나면 순환 프로세스가 완료됩니다.
재정의 파일을 업데이트하고 cassandra.auth.secretProviderClass를 새 보안 비밀 제공자 클래스(newSecretProviderClass)로 설정합니다.
```
cassandra:
  auth:
    secretProviderClass: NEW_SPC_NAME
```
Cassandra 데이터베이스를 백업합니다. 이 백업은 순환된 사용자 인증 정보를 복원할 수 있도록 하기 위한 것입니다.
Vault에서 이전 Cassandra 사용자 인증 정보, 역할, 정책을 삭제합니다.

멀티 리전 설정

멀티 리전 설정 절차는 첫 번째 리전 설정과 남은 리전 설정의 두 섹션으로 구분됩니다.

후속 리전을 시작하기 전에 첫 번째 리전에서 다음 단계를 완료합니다.
1. 새 Cassandra 사용자 인증 정보에 대해 APIGEE_NAMESPACE 네임스페이스에 새로운 SecretProviderClass Kubernetes 리소스를 만듭니다. 사용할 템플릿은 Hashicorp Vault에 Cassandra 보안 비밀 저장을 참조하세요. 이렇게 하면 Vault 역할이 Kubernetes 네임스페이스 내의 보안 비밀에 액세스할 수 있습니다.
2. 다음 템플릿을 사용하여 새 SecretRotation 커스텀 리소스를 만듭니다.
```
# rotation.yaml

apiVersion: apigee.cloud.google.com/v1alpha1
kind: SecretRotation
metadata:
  name: ROTATION_PROCESS_NAME
  namespace: APIGEE_NAMESPACE
spec:
  organizationId: ORG_NAME
  rotationId: ROTATION_ID
  timeoutMinutes: -1 # this value is required and should not be changed.
  precheck: true
  cassandra:
    oldSecretProviderClass: OLD_SPC_NAME
    newSecretProviderClass: NEW_SPC_NAME
    jobType: ROTATE
```
  - ROTATION_PROCESS_NAME: 순환 작업의 고유 이름입니다. 순환 사전 확인 작업 및 순환 작업에 대해 metadata.name을 고유한 값으로 설정해야 합니다. 예를 들어 sr-1-precheck 다음에 sr-1과 같이 설정할 수 있습니다.
  - ROTATION_ID: spec.rotationId를 커스텀 식별자(예: rotation-1-precheck)로 설정합니다.
  - NEW_SPC_NAME: spec.cassandra.newSecretProviderClass를 이전 단계에서 만든 새로운 보안 비밀 제공자 클래스 이름으로 설정합니다.
  - OLD_SPC_NAME: spec.cassandra.oldSecretProviderClass를 ApigeeDatastore에서 현재 사용 중인 SPC 이름으로 설정합니다.
3. rotation.yaml 파일을 적용하여 순환 사전 확인 작업을 트리거합니다.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
4. 사전 확인 작업이 완료되었을 때 확인할 작업 상태를 확인합니다.
```
kubectl -n APIGEE_NAMESPACE get job sr-(rotationId)-(rotate|rollback|cleanup)-job
```
  팁: 작업이 실행되는 동안 로그를 볼 수도 있습니다.
```
kubectl -n APIGEE_NAMESPACE logs sr-(rotationId)-(rotate|rollback|cleanup)-job-(hash)
```
5. 순환 사전 확인 작업이 완료된 후 다음 안내를 따르세요.
  - metadata.name 값을 변경합니다(예: sr-1-precheck에서 sr-1로).
  - spec.precheck를 false로 설정하여 사전 확인을 사용 중지하고 순환을 실행합니다.
  - spec.rotationId를 새 식별자로 설정합니다(예: rotation-1).
6. 파일을 다시 적용하여 순환을 수행합니다.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
7. SecretRotation 상태를 확인하고 complete가 될 때까지 기다립니다.
```
kubectl -n APIGEE_NAMESPACE get sr SR_NAME
```

이후 각 리전에서 다음 단계를 완료합니다.

새 Cassandra 사용자 인증 정보에 대해 Apigee 네임스페이스에 새로운 SecretProviderClass Kubernetes 리소스를 만듭니다. 사용할 템플릿은 Hashicorp Vault에 Cassandra 보안 비밀 저장을 참조하세요. 1a단계와 동일한 정의여야 합니다.
overrides.yaml을 업데이트하고 rotation.yaml 파일의 spec.cassandra.newSecretProviderClass 값과 일치하도록 cassandra.auth.secretProviderClass를 설정합니다.
```
cassandra:
  auth:
    secretProviderClass: NEW_SPC_NAME
```

연산자 차트를 적용합니다.

helm upgrade operator apigee-operator/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f OVERRIDES_FILE

새 ReplicaSet가 생성됩니다. 새 컨트롤러 관리자 포드가 새 SPC를 사용하는지 확인합니다.

export POD=NEW_CONTROLLER_MANAGER_POD_NAME
kubectl -n APIGEE_NAMESPACE get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'

결과는 rotation.yaml에서 spec.cassandra.newSecretProviderClass에 설정한 값과 일치해야 합니다. 예를 들면 다음과 같습니다.

kubectl -n apigee get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'

my-new-spc

데이터 스토어 차트를 적용합니다.
```
helm upgrade datastore apigee-datastore/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f OVERRIDES_FILE
```
참고: 데이터 스토어 차트를 적용하면 조직 및 환경의 출시도 트리거됩니다.
데이터 스토어가 출시 상태로 전환됩니다. 데이터 스토어의 출시가 완료되고 실행 상태가 될 때까지 기다립니다.
```
kubectl -n APIGEE_NAMESPACE get apigeedatastore DATASTORE_NAME
```
대부분의 설치에서 DATASTORE_NAME은 default입니다.

새 데이터 스토어 포드에서 새 SPC를 사용하는지 확인합니다.

export POD=NEW_DATASTORE_POD_NAME
kubectl -n APIGEE_NAMESPACE get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'

결과는 rotation.yaml에서 spec.cassandra.newSecretProviderClass에 설정한 값과 일치해야 합니다. 예를 들면 다음과 같습니다.

kubectl -n apigee get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'

my-new-spc

조직 및 환경 출시가 완료되고 실행 중 상태로 돌아갈 때까지 기다립니다.

kubectl -n APIGEE_NAMESPACE get apigeeorg ORG_NAME
kubectl -n APIGEE_NAMESPACE get apigeeenv ENV_NAME

새 MART, 런타임, 동기화기 포드가 새 SPC를 사용하는지 확인합니다.

export POD=NEW_MART_POD_NAME
kubectl -n APIGEE_NAMESPACE get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'
export POD=NEW_RUNTIME_POD_NAME
kubectl -n APIGEE_NAMESPACE get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'
export POD=NEW_SYNCHRONIZER_POD_NAME
kubectl -n APIGEE_NAMESPACE get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'

결과는 rotation.yaml에서 spec.cassandra.newSecretProviderClass에 설정한 값과 일치해야 합니다. 예를 들면 다음과 같습니다.

kubectl -n apigee get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'

my-new-spc

모든 리전의 단계를 완료하고 트래픽이 올바르게 작동하는지 확인한 후 다음 두 단계에 따라 첫 번째 리전에서 프로세스를 정리합니다.
1. 첫 번째 리전에서 metadata.name 값을 업데이트하고 spec.cassandra.jobType을 CLEANUP으로 설정합니다.
2. 파일을 적용하여 정리 작업을 트리거합니다.
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
3. 작업 상태를 확인하고 작업 로그를 통해 정리 작업이 완료되었는지 확인합니다.
정리 작업이 끝나면 순환 프로세스가 완료됩니다.
재정의 파일을 업데이트하고 cassandra.auth.secretProviderClass를 새 보안 비밀 제공자 클래스(newSecretProviderClass)로 설정합니다.
```
cassandra:
  auth:
    secretProviderClass: NEW_SPC_NAME
```
Cassandra 데이터베이스를 백업합니다. 이 백업은 순환된 사용자 인증 정보를 복원할 수 있도록 하기 위한 것입니다.
Vault에서 이전 Cassandra 사용자 인증 정보, 역할, 정책을 삭제합니다.

순환 롤백

멀티 리전의 경우 각 리전에서 롤백을 수행합니다.

다음 템플릿을 사용하여 새 SecretRotation 커스텀 리소스를 만듭니다.
```
# rollback-rotation.yaml

apiVersion: apigee.cloud.google.com/v1alpha1
kind: SecretRotation
metadata:
  name: ROLLBACK_NAME
  namespace: APIGEE_NAMESPACE
spec:
  organizationId: APIGEE_ORG
  rotationId: ROTATION_ID # match the current rotation.
  timeoutMinutes: TIMEOUT_MINUTES # optional.
  precheck: false
  cassandra:
    oldSecretProviderClass: OLD_SPC_NAME # Must match the previous oldSecretProviderClass.
    newSecretProviderClass: NEW_SPC_NAME # Must match the previous newSecretProviderClass.
    jobType: ROLLBACK
```
각 항목의 의미는 다음과 같습니다.
- ROLLBACK_NAME: 롤백 작업의 이름입니다(예: sr-1-rollback).
- APIGEE_NAMESPACE: Apigee 네임스페이스입니다.
- APIGEE_ORG: Apigee 조직 ID입니다.
- ROTATION_ID: 롤백 중인 현재 순환의 ID입니다(예: rot-1).
- TIMEOUT_MINUTES: 선택사항. 기본값을 재정의합니다(480m == 8시간). <=0은 무한 제한 시간을 의미합니다.
- OLD_SPC_NAME: 단일 리전 설정 또는 멀티 리전 설정 프러시저에서 사용한 순환 YAML 파일의 oldSecretProviderClass: 보안 비밀 이름과 일치해야 합니다.
- NEW_SPC_NAME: 단일 리전 설정 또는 멀티 리전 설정 프러시저에서 사용한 순환 YAML 파일의 newSecretProviderClass: 보안 비밀 이름과 일치해야 합니다.

롤백을 적용합니다.

kubectl -n APIGEE_NAMESPACE apply -f ROLLBACK_YAML_FILE

작업 상태를 확인하고 완료될 때까지 기다립니다.
```
kubectl -n APIGEE_NAMESPACE describe sr ROTATION_NAME
```
롤백이 완료되면 트래픽이 계속 올바르게 흐르는지 확인합니다.
멀티 리전 설치의 경우 트래픽이 올바르게 흐르면 각 리전에서 롤백 프로세스를 반복합니다.
롤백을 완료하고 모든 리전에서 트래픽이 계속 올바르게 흐르는지 확인한 후 삭제 프로세스를 시작합니다.
순환 YAML 파일을 다음과 같이 변경합니다.
- metadata.name을 정리 작업임을 나타내는 이름(예: sr-1-cleanup-rollback)으로 변경합니다.
- spec.cassandra.jobType를 CLEANUP_ROLLBACK로 변경합니다.

파일을 적용하여 정리 작업을 트리거합니다.

kubectl -n APIGEE_NAMESPACE apply -f ROTATION_YAML_FILE

작업 상태를 확인하고 완료될 때까지 기다립니다.
```
kubectl -n APIGEE_NAMESPACE describe sr ROTATION_NAME
```
정리 작업이 끝나면 롤백 프로세스가 완료됩니다.
재정의 파일을 업데이트하고 cassandra.auth.secretProviderClass를 이전 보안 비밀 제공자 클래스(oldSecretProviderClass)로 설정합니다.
```
cassandra:
  auth:
    secretProviderClass: OLD_SPC_NAME
```