このページは Cloud Translation API によって翻訳されました。

Hashicorp Vault での Cassandra 認証情報のローテーション

概要

この手順では、Hashicorp Vault 内で Cassandra 認証情報をローテーションする方法について説明します。クラスタ内の Kubernetes Secret で認証情報をローテーションする方法については、Kubernetes Secret で Cassandra 認証情報をローテーションするをご覧ください。

この機能を使用すると、プラットフォーム管理者は次のことができます。

Hashicorp Vault で Cassandra の認証情報をローテーションします。
パスワードのローテーション中に問題が発生した場合に備えて、Vault で以前の Cassandra 認証情報にロールバックします。
Cassandra パスワードを一度に 1 つのリージョンでローテーションします。これにより、サービス可用性への影響を最小限に抑え、ローテーションプロセスを制御できます。
単一リージョンのローテーションの開始、進行状況、完了を追跡します。

この機能は、Apigee ハイブリッド 1.13.1 以降で使用できます。

始める前に

認証情報のローテーションを設定する前に、次のことを行う必要があります。

Cassandra データベースをバックアップします。このバックアップは、事前にローテーションされた認証情報の復元を確実に行うためのものです。
クラスタが正常な状態であることを確認します。つまり、すべての Apigee リソースが実行されており、保留中の状態変更がないことを確認します。

注: 認証情報のローテーションを設定するには、クラスタ内で kubectl apply -f を実行する権限が必要です。

単一リージョンの設定

新しい Cassandra 認証情報用に、Apigee Namespace に新しい SecretProviderClass Kubernetes リソースを作成します。使用するテンプレートについては、Hashicorp Vault への Cassandra Secret の保存をご覧ください。これにより、Vault ロールに Kubernetes Namespace 内の Secret へのアクセスが許可されます。
次のテンプレートを使用して、新しい 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 はカスタム ID（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
```
ヒント: ジョブの実行中にログを表示することもできます。
```
kubectl -n APIGEE_NAMESPACE logs sr-(rotationId)-(rotate|rollback|cleanup)-job-(hash)
```
ローテーションの事前チェックジョブが完了したら、metadata.name の値を変更し、spec.precheck を false に設定します。ファイルをもう一度適用して、ローテーションを実行します。
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
ローテーションジョブが完了し、トラフィックが引き続き正しく転送されていることを確認したら、次の 2 つの手順でプロセスをクリーンアップします。
1. metadata.name の値を更新し、spec.cassandra.jobType を CLEANUP に設定します。
2. ファイルを適用してクリーンアップジョブをトリガーします。
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
  注: このステップまでは、ロールバックジョブをトリガーしてローテーションプロセスを戻し、クラスタを元の状態にすることができます。
クリーンアップジョブが完了すると、ローテーションプロセスは完了します。
Cassandra データベースをバックアップします。このバックアップは、ローテーション後の認証情報の復元を確実に行うためのものです。
Vault から古い Cassandra 認証情報、ロール、ポリシーを削除します。

マルチリージョンの設定

マルチリージョンの設定手順は、最初のリージョンの設定と残りのリージョンの設定の 2 つのセクションに分かれています。

後続のリージョンの設定を始める前に、最初のリージョンで次の手順を完了します。
1. 新しい Cassandra 認証情報用に、APIGEE_NAMESPACE Namespace に新しい SecretProviderClass Kubernetes リソースを作成します。使用するテンプレートについては、Hashicorp Vault への Cassandra Secret の保存をご覧ください。これにより、Vault ロールに Kubernetes Namespace 内の Secret へのアクセスが許可されます。
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 はカスタム ID（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 を新しい ID（rotation-1 など）に設定します。
6. ファイルをもう一度適用して、ローテーションを実行します。
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
7. SecretRotation の状態を確認し、complete になるまで待ちます。
```
kubectl -n APIGEE_NAMESPACE get sr SR_NAME
```
後続の各リージョンで、次の手順を完了します。
1. 新しい Cassandra 認証情報用に、Apigee Namespace に新しい SecretProviderClass Kubernetes リソースを作成します。使用するテンプレートについては、Hashicorp Vault への Cassandra Secret の保存をご覧ください。これは、ステップ 1a と同じ定義にする必要があります。
2. overrides.yaml を更新し、cassandra.auth.secretProviderClass を rotation.yaml ファイルの spec.cassandra.newSecretProviderClass の値と一致するように設定します。
```
cassandra:
  auth:
    secretProviderClass: NEW_SPC_NAME
```
3. オペレーターチャートを適用します。
```
helm upgrade operator apigee-operator/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f OVERRIDES_FILE
```
4. 新しい ReplicaSet が作成されます。新しい controller-manager Pod が新しい 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
```
5. データストアチャートを適用します。
```
helm upgrade datastore apigee-datastore/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f OVERRIDES_FILE
```
  注: データストアグラフを適用すると、組織と環境のリリースもトリガーされます。
6. データストアは「リリース中」状態になります。データストアのリリースが完了して実行状態になるまで待ちます。
```
kubectl -n APIGEE_NAMESPACE get apigeedatastore DATASTORE_NAME
```
  ほとんどのインストールでは、DATASTORE_NAME は default です。
7. 新しいデータストア Pod が新しい 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
```
8. 組織と環境のリリースが完了し、実行状態に戻るまで待ちます。
```
kubectl -n APIGEE_NAMESPACE get apigeeorg ORG_NAME
kubectl -n APIGEE_NAMESPACE get apigeeenv ENV_NAME
```
9. 新しい MART、ランタイム、同期 Pod が新しい 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
```
すべてのリージョンで手順を完了し、トラフィックが引き続き正しく流れていることを確認したら、次の 2 つの手順で最初のリージョンのプロセスをクリーンアップします。
1. 最初のリージョンで、metadata.name の値を更新し、spec.cassandra.jobType を CLEANUP に設定します。
2. ファイルを適用してクリーンアップジョブをトリガーします。
```
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
```
3. ジョブのステータスを確認し、ジョブログを監視して、クリーンアップジョブが完了したことを確認します。
クリーンアップジョブが完了すると、ローテーションプロセスは完了します。
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 Namespace。
- APIGEE_ORG: Apigee 組織の ID。
- ROTATION_ID: ロールバックする現在のローテーションの ID（例: rot-1）。
- TIMEOUT_MINUTES: 省略可。デフォルト（480 分 = 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
```
マルチリージョンインストールの場合は、各リージョンでクリーンアッププロセスを繰り返します。