概要
この手順では、Hashicorp Vault 内で Cassandra 認証情報をローテーションする方法について説明します。クラスタ内の Kubernetes Secret で認証情報をローテーションする方法については、Kubernetes Secret での Cassandra 認証情報のローテーションをご覧ください。
この機能を使用すると、プラットフォーム管理者は次のことができます。
- Hashicorp Vault で Cassandra の認証情報をローテーションします。
- パスワードのローテーション中に問題が発生した場合に備えて、Vault で以前の Cassandra 認証情報にロールバックします。
- Cassandra パスワードを一度に 1 つのリージョンでローテーションします。これにより、サービス可用性への影響を最小限に抑え、ローテーション プロセスを制御できます。
- 単一リージョンのローテーションの開始、進行状況、完了を追跡します。
この機能は、Apigee ハイブリッド 1.13.1 以降で使用できます。
始める前に
認証情報のローテーションを設定する前に、次のことを行う必要があります。
- Cassandra データベースをバックアップします。このバックアップは、事前にローテーションされた認証情報の復元を確実に行うためのものです。
- クラスタが正常な状態であることを確認します。つまり、すべての Apigee リソースが実行されており、保留中の状態変更がないことを確認します。
単一リージョンの設定
- 
    新しい Cassandra 認証情報用に、Apigee Namespace に新しい SecretProviderClassKubernetes リソースを作成します。使用するテンプレートについては、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_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.auth.secretProviderClassを新しいシークレット プロバイダ クラス(newSecretProviderClass)に設定します。cassandra: auth: secretProviderClass: NEW_SPC_NAME
- Cassandra データベースをバックアップします。このバックアップは、ローテーション後の認証情報の復元を確実に行うためのものです。
- Vault から古い Cassandra 認証情報、ロール、ポリシーを削除します。
マルチリージョンの設定
マルチリージョンの設定手順は、最初のリージョンの設定と残りのリージョンの設定の 2 つのセクションに分かれています。
- 後続のリージョンの設定を始める前に、最初のリージョンで次の手順を完了します。- 
        新しい Cassandra 認証情報用に、APIGEE_NAMESPACENamespace に新しいSecretProviderClassKubernetes リソースを作成します。使用するテンプレートについては、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: -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 に新しい SecretProviderClassKubernetes リソースを作成します。使用するテンプレートについては、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_NAMEkubectl -n APIGEE_NAMESPACE get pods $POD -o jsonpath='{.spec.volumes[?(@.name=="apigee-external-secrets")].csi.volumeAttributes.secretProviderClass}'export POD=NEW_SYNCHRONIZER_POD_NAMEkubectl -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.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: 省略可。デフォルト(480 分 = 8 時間)をオーバーライドします。<=0 は無限のタイムアウトを意味します。
- OLD_SPC_NAME: 単一リージョンの設定またはマルチリージョンの設定の手順で使用したローテーション YAML ファイルの oldSecretProviderClass:のシークレット名と一致させる必要があります。
- NEW_SPC_NAME: 単一リージョンの設定またはマルチリージョンの設定の手順で使用したローテーション YAML ファイルの newSecretProviderClass:のシークレット名と一致させる必要があります。
 
- ROLLBACK_NAME: ロールバック ジョブの名前(例: 
- 
    ロールバックを適用します。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