概要
この機能を使用すると、プラットフォーム管理者は次のことができます。
- Hashicorp Vault で Cassandra の認証情報をローテーションします。
- パスワードのローテーション中に問題が発生した場合に備えて、Vault で以前の Cassandra 認証情報にロールバックします。
- Cassandra パスワードは一度に 1 つのリージョンでローテーションします。これにより、サービス可用性への影響を最小限に抑え、ローテーション プロセスを制御できます。
- 単一リージョンのローテーションの開始、進行状況、完了を追跡します。
この機能は、Apigee ハイブリッド 1.13.1 以降で使用できます。
始める前に
認証情報のローテーションを設定する前に、次の点を確認してください。
- Cassandra データベースをバックアップします。このバックアップは、事前にローテーションされた認証情報の復元を確実に行うためのものです。
- クラスタが正常な状態であることを確認します(つまり、すべての Apigee リソースが実行されており、保留中の状態変更がない)。
単一リージョンの設定
-
新しい Cassandra 認証情報の Apigee Namespace に新しい
SecretProviderClass
Kubernetes リソースを作成します。使用するテンプレートについては、Hashicorp Vault への Cassandra Secret の保存をご覧ください。これにより、Vault ロールが Kubernetes Namespace 内のシークレットへのアクセスを許可されます。 -
次のテンプレートを使用して、新しい
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_PROCESS_NAME: ローテーション ジョブの一意の名前。
-
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
-
ローテーション ジョブが完了し、トラフィックが引き続き正しく流れていることを確認したら、次の 2 つの手順でプロセスをクリーンアップします。
-
metadata.name
の値を更新し、spec.cassandra.jobType
をCLEANUP
に設定します。 -
ファイルを適用してクリーンアップ ジョブをトリガーします。
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
クリーンアップ ジョブが完了すると、ローテーション プロセスは完了します。
-
- Cassandra データベースをバックアップします。このバックアップは、ローテーション後の認証情報の復元を確実に行うためのものです。
- Vault から古い Cassandra 認証情報、ロール、ポリシーを削除します。
マルチリージョンの設定
マルチリージョンの設定手順は、最初のリージョンの設定と残りのリージョンの設定の 2 つのセクションに分かれています。
- 次のリージョンを開始する前に、最初のリージョンで次の手順を完了します。
-
新しい Cassandra 認証情報の
APIGEE_NAMESPACE
Namespace に新しいSecretProviderClass
Kubernetes リソースを作成します。使用するテンプレートについては、Hashicorp Vault への Cassandra Secret の保存をご覧ください。これにより、Vault ロールが Kubernetes Namespace 内のシークレットへのアクセスを許可されます。 -
次のテンプレートを使用して、新しい
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 名に設定します。
- ROTATION_PROCESS_NAME: ローテーション ジョブの一意の名前。
-
rotation.yaml
ファイルを適用して、ローテーションの事前チェック ジョブをトリガーします。kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
-
ジョブのステータスを確認して、事前チェック ジョブが完了したかどうかを確認します。
kubectl -n APIGEE_NAMESPACE get job sr-(rotationId)-(rotate|rollback|cleanup)-job
-
ローテーションの事前チェック ジョブが完了すると、次のようになります。
metadata.name
の値を変更します(sr-1-precheck
からsr-1
など)。spec.precheck
をfalse
に設定して、事前チェックをオフにしてローテーションを実行します。spec.rotationId
を新しい ID(rotation-1
など)に設定します。
-
ファイルをもう一度適用して、回転を実行します。
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
-
SecretRotation
の状態を確認し、complete
になるまで待ちます。kubectl -n APIGEE_NAMESPACE get sr SR_NAME
-
新しい Cassandra 認証情報の
-
以降の各リージョンで、次の手順を完了します。
- 新しい Cassandra 認証情報の Apigee Namespace に新しい
SecretProviderClass
Kubernetes リソースを作成します。使用するテンプレートについては、Hashicorp Vault への Cassandra Secret の保存をご覧ください。これは、ステップ 1a と同じ定義にする必要があります。 overrides.yaml
を更新し、cassandra.auth.secretProviderClass
をrotation.yaml
ファイルのspec.cassandra.newSecretProviderClass
の値と一致するように設定します。cassandra: auth: secretProviderClass: NEW_SPC_NAME
- オペレーター チャートを適用します。
helm upgrade operator apigee-operator/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE
-
新しい
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 - データストア チャートを適用します。
helm upgrade datastore apigee-datastore/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE
- データストアは解放状態になります。データストアのリリースが完了して実行状態になるまで待ちます。
kubectl -n APIGEE_NAMESPACE get apigeedatastore DATASTORE_NAME
ほとんどのインストールでは、DATASTORE_NAME は
default
です。 - 新しいデータストア 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 - 組織と環境のリリースが完了し、実行状態に戻るまで待ちます。
kubectl -n APIGEE_NAMESPACE get apigeeorg ORG_NAME
kubectl -n APIGEE_NAMESPACE get apigeeenv ENV_NAME
- 新しい 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
- 新しい Cassandra 認証情報の Apigee Namespace に新しい
-
すべてのリージョンで手順を完了し、トラフィックが引き続き正しく流れていることを確認したら、次の 2 つの手順で最初のリージョンのプロセスをクリーンアップします。
-
最初のリージョンで、
metadata.name
の値を更新し、spec.cassandra.jobType
をCLEANUP
に設定します。 -
ファイルを適用してクリーンアップ ジョブをトリガーします。
kubectl -n APIGEE_NAMESPACE apply -f rotation.yaml
- ジョブのステータスを確認し、ジョブログを監視して、クリーンアップ ジョブが完了したことを確認します。
クリーンアップ ジョブが完了すると、ローテーション プロセスは完了します。
-
最初のリージョンで、
- Cassandra データベースをバックアップします。このバックアップは、ローテーション後の認証情報の復元を確実に行うためのものです。
- Vault から古い Cassandra 認証情報、ロール、ポリシーを削除します。