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

お客様が管理するコントロールプレーンの CA と鍵をローテーションする

Standard

このページでは、クラスタ管理者とセキュリティエンジニア向けに、GKE コントロールプレーン認証用に構成した認証局（CA）とサービスアカウント署名鍵をローテーションする方法について説明します。

次のコンセプトを理解している必要があります。

認証情報のローテーションを計画する

このページでは、コントロールプレーンで次の認証情報コンポーネントをローテーションする方法について説明します。

クラスタルート CA、集約ルート CA、etcd API ルート CA、etcd ピアルート CA。
Kubernetes ServiceAccount の署名鍵と検証鍵。

コントロールプレーンのブートディスク、etcd ディスク、障害復旧に Google Cloud が使用する etcd 内部バックアップの暗号化に使用した顧客管理の暗号鍵をローテーションすることもできます。詳細については、etcd とコントロールプレーンのブートディスクの暗号鍵をローテーションするをご覧ください。

認証情報をローテーションして、CA の有効期限切れを回避し、鍵バージョンの侵害を軽減し、組織のセキュリティプラクティスの一環として使用します。特定の GKE control plane authority リソースをローテーションする頻度を計画するには、次の点を考慮してください。

デフォルトでは、Certificate Authority Service（CA Service）のルート CA によって署名された GKE 証明書の有効期限は、作成日から 1 年後です。
Cloud Key Management Service（Cloud KMS）の鍵は期限切れになりません。鍵のローテーションの要件が組織にある場合にのみ、手動で鍵のローテーションを行います。実行中のワークロードの中断を最小限に抑えるため、これらの鍵の自動ローテーションは構成しないでください。

始める前に

作業を始める前に、次のタスクが完了していることを確認してください。

Google Kubernetes Engine API を有効にする。

Google Kubernetes Engine API の有効化

このタスクに Google Cloud CLI を使用する場合は、gcloud CLI をインストールして初期化する。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得する。
注: gcloud CLI がすでにインストールされている場合には、必ず compute/region プロパティを設定してください。主にゾーンクラスタを使用する場合は、代わりに compute/zone を設定します。デフォルトのロケーションを設定することで、gcloud CLI のエラー（One of [--zone, --region] must be supplied: Please specify location など）を防止できます。クラスタのロケーションが設定したデフォルトと異なる場合は、特定のコマンドでロケーションの指定が必要になることがあります。

セルフマネージド CA とサービスアカウントキーを使用する既存のクラスタがある
次の Google Cloud プロジェクトのプロジェクト ID を特定します。
- 鍵プロジェクト: Cloud KMS リソースと CA Service リソースを含むプロジェクト。
- クラスタプロジェクト: GKE クラスタを含むプロジェクト。
このページの検証タスクを行うには、次のデータアクセス監査ログが有効になっていることを確認します。
- Cloud Key Management Service（KMS）API: DATA_READ
- Certificate Authority Service: ADMIN_READ
これらのログタイプを有効にするには、データアクセス監査ログを有効にするをご覧ください。

必要なロールと権限

顧客管理の CA と鍵をローテーションするために必要な権限を取得するには、次の IAM ロールを付与するよう管理者に依頼してください。

鍵または鍵バージョンを管理する: 鍵プロジェクトに対する Cloud KMS 管理者（roles/cloudkms.admin）
ルート CA を管理する: 鍵プロジェクトに対する CA Service 管理者（roles/privateca.admin）
新しい認証情報を使用するようにクラスタを構成する: クラスタプロジェクトに対する Kubernetes Engine クラスタ管理者（roles/container.clusterAdmin）

ロールの付与については、プロジェクト、フォルダ、組織へのアクセス権の管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

制限事項

サービスアカウントの署名と検証に使用する非対称 Cloud KMS 鍵は、自動鍵ローテーションをサポートしていません。

サービスアカウントの署名鍵と検証鍵をローテーションする

GKE control plane authority を設定するときに、サービスアカウント署名鍵とサービスアカウント検証鍵をクラスタに追加します。GKE は、これらの鍵を使用して Kubernetes ServiceAccount の署名なしトークンに署名し、検証します。ローテーション中に、新しいキーをサービスアカウント検証キーのリストに追加し、変更が伝播されるのを待ってから、サービスアカウント署名キーを新しいキーに置き換えます。

サービスアカウントキーをローテーションする手順は次のとおりです。

サービスアカウント署名鍵の元の鍵バージョンの完全なリソース名を取得します。
```
gcloud container clusters describe CLUSTER_NAME \
    --project=CLUSTER_PROJECT_ID \
    --location=CONTROL_PLANE_LOCATION \
    --format="value(userManagedKeysConfig.serviceAccountSigningKeys)"
```
次のように置き換えます。
- CLUSTER_NAME: クラスタの名前。
- CONTROL_PLANE_LOCATION: クラスタのロケーション。
- CLUSTER_PROJECT_ID: クラスタプロジェクトのプロジェクト ID。
出力は次のようになります。
```
projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/SIGNING_KEY_NAME/cryptoKeyVersions/ORIGINAL_SIGNING_KEY_VERSION
```
この出力で、SIGNING_KEY_NAME は鍵の名前、ORIGINAL_SIGNING_KEY_VERSION は元の署名鍵のバージョンの数です。
サービスアカウントの署名鍵の新しい鍵バージョンを作成します。
```
gcloud kms keys versions create \
    --key=SIGNING_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID
```
次のように置き換えます。
- SIGNING_KEY_NAME: サービスアカウント署名鍵の名前。
- KEYRING_NAME: 鍵を含むキーリングの名前。
- CONTROL_PLANE_LOCATION: キーリングの Google Cloud ロケーション。
- KEY_PROJECT_ID: 鍵プロジェクトのプロジェクト ID。

新しい鍵バージョンの完全なリソース名を取得します。

gcloud kms keys versions list \
    --key=SIGNING_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
    --filter="STATE=ENABLED" --sort-by=~ \
    --format="value(name)" | sed 1q

出力は次のようになります。

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/SIGNING_KEY_NAME/cryptoKeyVersions/NEW_SIGNING_KEY_VERSION

この出力で、SIGNING_KEY_NAME は鍵の名前、NEW_SIGNING_KEY_VERSION は新しい署名鍵バージョンの番号です。

新しいキーバージョンをクラスタのサービスアカウント検証キーのセットに追加します。
```
gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --service-account-verification-keys=ORIGINAL_KEY_VERSION_PATH,NEW_KEY_VERSION_PATH
```
次のように置き換えます。
- ORIGINAL_KEY_VERSION_PATH: このセクションの最初の手順の出力から取得した元の署名鍵バージョンの完全なリソース名。例: projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/1
- NEW_KEY_VERSION_PATH: 前の手順の出力から取得した新しい署名鍵バージョンの完全なリソース名。例: projects/example-key-project/locations/us-central1/keyRings/example-keyring/cryptokeys/example-signing-key/cryptoKeyVersions/2
クラスタの更新オペレーションが完了した後、新しい鍵バージョンのパスが Kubernetes API サーバーとすべての GKE API エンドポイントに伝播されるまでに最大 10 分かかることがあります。
新しい鍵バージョンパスが完全に伝播されたことを確認する手順は次のとおりです。
1. JSON Web Key Set（JWKS）として GKE API からクラスタ署名鍵の公開コンポーネントを取得します。
```
curl https://container.googleapis.com/v1/projects/CLUSTER_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/clusters/CLUSTER_NAME/jwks
```
  出力は次のようになります。
```
{
  "keys": [
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY1_ID",
      "n": "KEY1_MODULUS",
      "e": "KEY1_EXPONENT"
    },
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY2_ID",
      "n": "KEY2_MODULUS",
      "e": "KEY2_EXPONENT"
    }
  ]
}
```
  この出力には 2 つのキーエントリが必要です。これは、両方のキーバージョンが GKE API で使用可能であることを示します。キーエントリが 1 つしか表示されない場合は、10 分待ってからコマンドを再試行します。
2. kubectl コマンドを実行できるように、クラスタに接続します。
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION
```
3. クラスタ署名鍵の公開コンポーネントを JWKS として Kubernetes API サーバーから取得します。
```
kubectl get --raw /openid/v1/jwks | jq
```
  出力は次のようになります。
```
{
  "keys": [
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY1_ID",
      "n": "KEY1_MODULUS",
      "e": "KEY1_EXPONENT"
    },
    {
      "kty": "RSA",
      "alg": "RS256",
      "use": "sig",
      "kid": "KEY2_ID",
      "n": "KEY2_MODULUS",
      "e": "KEY2_EXPONENT"
    }
  ]
}
```
  この出力には 2 つのキーエントリが必要です。これは、両方のキーバージョンが Kubernetes API サーバーで使用可能であることを示します。キーエントリが 1 つしか表示されない場合は、10 分待ってからコマンドを再試行します。

新しいキーバージョンをサービスアカウントの署名キーとして使用するようにクラスタを更新します。

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --service-account-signing-key=NEW_KEY_VERSION_PATH

新しいサービスアカウントトークンが新しいキーバージョンを使用していることを確認します。

ServiceAccount を作成します。

kubectl create serviceaccount test-sa-1

ServiceAccount のトークンを作成します。
```
kubectl create token test-sa-1
```

最近署名されたダイジェストを Logging から抽出します。

export SIGNED_DIGEST=$(gcloud logging read \
    'resource.type="gke_cluster" '\
    'AND resource.labels.cluster_name="' CLUSTER_NAME '" '\
    'AND protoPayload.methodName="google.cloud.gkeauth.v1.Auth.SignServiceAccountJWT" '\
    'AND protoPayload.metadata.subject="system:serviceaccount:default:test-sa-1"' \
    --freshness=1h \
    --bucket=_Required \
    --location=global \
    --view=_AllLogs \
    --order=DESC \
    --limit=1 \
    --format="value(protoPayload.metadata.toBeSignedDigest)")

新しい署名鍵バージョンが使用されていることを確認します。

  gcloud logging read \
      'resource.type="cloudkms_cryptokeyversion" '\
      'AND protoPayload.methodName="AsymmetricSign" '\
      'AND protoPayload.request.digest.sha256="'${SIGNED_DIGEST}'"' \
      --freshness=1h \
      --bucket=_Default \
      --location=global \
      --view=_AllLogs \
      --order=DESC \
      --limit=1 \
      --format="value(protoPayload.resourceName)"
  ```
The output is the resource path of the new signing key version.

元のサービスアカウント署名鍵バージョンを使用するクラスタ内のすべてのトークンが期限切れになるまで待ちます。デフォルトでは、トークンの有効期間は 1 時間ですが、最大 24 時間まで構成できます。クラスタで構成されたトークンの有効期間を確認するには、次のコマンドを実行します。
```
kubectl get pods -A -o json | jq -r '.items[]?.spec?.volumes[]?.projected?.sources[]?.serviceAccountToken?.expirationSeconds | select(. != null)' | sort -nr | head -n 1
```
注: ServiceAccount トークンを Secret に保存する場合は、Kubernetes が新しい鍵バージョンで署名された新しいトークンを生成するように Secret を再作成します。
前の手順の出力で構成されたトークンの有効期限が切れるまで待ちます。この期間が経過すると、クラスタ内のすべてのバインドされたトークンが新しいサービスアカウント署名鍵バージョンを使用します。

クラスタの検証鍵のリストから元の鍵バージョンを削除します。

gcloud container clusters update CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --service-account-verification-keys=NEW_KEY_VERSION_PATH

省略可: 元の鍵バージョンを無効にします。元の鍵バージョンが使用されておらず、クラスタが正常であることを確認したら、鍵バージョンを破棄します。

重大なイベントに対応して鍵をローテーションする場合を除き、元の鍵バージョンを破棄する前に数日待つことをおすすめします。詳細については、鍵バージョンの破棄と復元をご覧ください。

これらの手順を完了すると、クラスタ内のすべての新規および既存のサービスアカウントトークンが新しいキーバージョンで署名されます。元のキーバージョンはクラスタ構成に存在しないため、API サーバーは元のキーバージョンを含むベアラートークンを使用するリクエストを拒否します。

GKE control plane authority の CA をローテーションする

以降のセクションでは、クラスタが GKE control plane authority に使用するルート CA をローテーションする方法について説明します。

CA の新しい鍵バージョンを作成する

クラスタルート CA 鍵の新しい鍵バージョンを作成します。
```
gcloud kms keys versions create \
    --key=CLUSTER_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID
```
次のように置き換えます。
- CLUSTER_CA_KEY_NAME: クラスタのクラスタルート CA 鍵の名前。
- KEYRING_NAME: 鍵を含むキーリングの名前。
- CONTROL_PLANE_LOCATION: キーリングの Google Cloud ロケーション。これは、クラスタのロケーションと同じです。
- KEY_PROJECT_ID: 鍵プロジェクトのプロジェクト ID。

集約ルート CA 鍵の新しい鍵バージョンを作成します。

gcloud kms keys versions create \
    --key=AGGREGATION_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

AGGREGATION_CA_KEY_NAME は、クラスタの集約ルート CA 鍵の名前に置き換えます。

etcd API ルート CA 鍵の新しい鍵バージョンを作成します。

gcloud kms keys versions create \
    --key=ETCD_API_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

ETCD_API_CA_KEY_NAME は、クラスタの etcd API ルート CA 鍵の名前に置き換えます。

etcd ピアルート CA 鍵の新しい鍵バージョンを作成します。

gcloud kms keys versions create \
    --key=ETCD_PEER_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

ETCD_PEER_CA_KEY_NAME は、クラスタの etcd ピアルート CA 鍵の名前に置き換えます。

新しいルート CA を作成する

新しいクラスタルート CA 鍵バージョンの完全なリソース名を取得します。

gcloud kms keys versions list \
    --key=CLUSTER_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
    --filter="STATE=ENABLED" --sort-by=~ \
    --format="value(name)" | sed 1q

出力は次のようになります。

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/CLUSTER_CA_KEY_NAME/cryptoKeyVersions/VERSION

この出力で、VERSION は新しい鍵バージョンの番号です。

クラスタ CA プールに新しいクラスタルート CA を作成します。
```
gcloud privateca roots create CLUSTER_ROOT_CA_NAME \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=CLUSTER_CA_KEY_PATH \
    --subject="CN=cluster-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID
```
次のように置き換えます。
- CLUSTER_ROOT_CA_NAME: 新しいルート CA の名前。
- CLUSTER_CA_POOL_NAME: クラスタ CA プールの名前。
- CLUSTER_CA_KEY_PATH: 前の手順の出力で返された新しい鍵バージョンの完全なリソース名。
- ORGANIZATION: 組織名。

新しい集約ルート CA 鍵バージョンの完全なリソース名を取得します。

gcloud kms keys versions list \
    --key=AGGREGATION_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
    --filter="STATE=ENABLED" --sort-by=~ \
    --format="value(name)" | sed 1q

出力は次のようになります。

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/AGGREGATION_CA_KEY_NAME/cryptoKeyVersions/VERSION

集約 CA プールに新しい集約ルート CA を作成します。
```
gcloud privateca roots create AGGREGATION_ROOT_CA_NAME \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=AGGREGATION_CA_KEY_PATH \
    --subject="CN=aggregation-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID
```
次のように置き換えます。
- AGGREGATION_ROOT_CA_NAME: 新しい集約ルート CA の名前。
- AGGREGATION_CA_POOL_NAME: 集約 CA プールの名前。
- AGGREGATION_CA_KEY_PATH: 前の手順の出力で返された新しい鍵バージョンの完全なリソース名。

新しい etcd API ルート CA 鍵バージョンの完全なリソース名を取得します。

gcloud kms keys versions list \
    --key=ETCD_API_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
    --filter="STATE=ENABLED" --sort-by=~ \
    --format="value(name)" | sed 1q

出力は次のようになります。

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/ETCD_API_CA_KEY_NAME/cryptoKeyVersions/VERSION

etcd API CA プールに新しい etcd API ルート CA を作成します。
```
gcloud privateca roots create ETCD_API_ROOT_CA_NAME \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=ETCD_API_CA_KEY_PATH \
    --subject="CN=etcd-api-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID
```
次のように置き換えます。
- ETCD_API_ROOT_CA_NAME: 新しい etcd API ルート CA の名前。
- ETCD_API_CA_POOL_NAME: etcd API CA プールの名前。
- ETCD_API_CA_KEY_PATH: 前の手順の出力で返された新しい鍵バージョンの完全なリソース名。

新しい etcd ピアルート CA 鍵バージョンの完全なリソース名を取得します。

gcloud kms keys versions list \
    --key=ETCD_PEER_CA_KEY_NAME \
    --keyring=KEYRING_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
    --filter="STATE=ENABLED" --sort-by=~ \
    --format="value(name)" | sed 1q

出力は次のようになります。

projects/KEY_PROJECT_ID/locations/CONTROL_PLANE_LOCATION/keyRings/KEYRING_NAME/cryptoKeys/ETCD_PEER_CA_KEY_NAME/cryptoKeyVersions/VERSION

etcd ピア CA プールに新しい etcd ピアルート CA を作成します。
```
gcloud privateca roots create ETCD_PEER_ROOT_CA_NAME \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --kms-key-version=ETCD_PEER_CA_KEY_PATH \
    --subject="CN=etcd-peer-ca, O=ORGANIZATION" \
    --project=KEY_PROJECT_ID
```
次のように置き換えます。
- ETCD_PEER_ROOT_CA_NAME: 新しい etcd ピアルート CA の名前。
- ETCD_PEER_CA_POOL_NAME: etcd ピア CA プールの名前。
- ETCD_PEER_CA_KEY_PATH: 前の手順の出力で返された新しい鍵バージョンの完全なリソース名。
続行する前に、コントロールプレーンとノードを再起動するの手順に沿って、ルート CA の変更をクラスタの信頼バンドルに伝播します。

元のルート CA を新しいルート CA に置き換える

コントロールプレーンとノードを再起動したら、次の操作を行います。

新しいクラスタルート CA を有効にします。

gcloud privateca roots enable CLUSTER_ROOT_CA_NAME \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

新しい集約ルート CA を有効にします。

gcloud privateca roots enable AGGREGATION_ROOT_CA_NAME \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

新しい etcd API ルート CA を有効にします。

gcloud privateca roots enable ETCD_API_ROOT_CA_NAME \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

新しい etcd ピアルート CA を有効にします。

gcloud privateca roots enable ETCD_PEER_ROOT_CA_NAME \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

元のクラスタルート CA を無効にします。

gcloud privateca roots disable ORIGINAL_CLUSTER_ROOT_CA \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

ORIGINAL_CLUSTER_ROOT_CA は、ローテーションする元のクラスタルート CA の名前に置き換えます。

元の集約ルート CA を無効にします。

gcloud privateca roots disable ORIGINAL_AGGREGATION_ROOT_CA \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

ORIGINAL_AGGREGATION_ROOT_CA は、ローテーションする元の集約ルート CA の名前に置き換えます。

元の etcd API ルート CA を無効にします。

gcloud privateca roots disable ORIGINAL_ETCD_API_ROOT_CA \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

ORIGINAL_ETCD_API_ROOT_CA は、ローテーションする元の etcd API ルート CA の名前に置き換えます。

元の etcd ピアルート CA を無効にします。

gcloud privateca roots disable ORIGINAL_ETCD_PEER_ROOT_CA \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID

ORIGINAL_ETCD_PEER_ROOT_CA は、ローテーションする元の etcd ピアルート CA の名前に置き換えます。

この時点で、新しいルート CA がクラスタ内のすべての新しい証明書を発行します。各ノードの kubelet に新しい証明書を発行するには、コントロールプレーンとノードを再起動します。kubelet 証明書の有効期間が長いため、この手順は必須です。

クラスタが正常な状態を維持している状態が数日続いたら、次のセクションで説明するように、元のルート CA を削除できます。

元のルート CA を削除する

このセクションでは、元のルート CA を削除する方法について説明します。以下の手順を行う前に、次のことを確認してください。

元のルート CA を新しいルート CA に置き換えた後、クラスタは数日間正常な状態を維持しました。
元のルート CA によって発行されたすべての証明書を新しい証明書に置き換えた。

元のルート CA を削除するには、次の手順で説明するように gcloud privateca roots delete コマンドを使用します。これらのコマンドでは、CA に取り消されていない証明書や期限切れになっていない証明書があっても、猶予期間後に --ignore-active-certificates フラグによって CA が削除されます。

元のクラスタルート CA を削除します。

gcloud privateca roots delete ORIGINAL_CLUSTER_ROOT_CA \
    --pool=CLUSTER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

ORIGINAL_CLUSTER_ROOT_CA は、ローテーションする元のクラスタルート CA の名前に置き換えます。

元の集約ルート CA を削除します。

gcloud privateca roots delete ORIGINAL_AGGREGATION_ROOT_CA \
    --pool=AGGREGATION_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

ORIGINAL_AGGREGATION_ROOT_CA は、ローテーションする元の集約ルート CA の名前に置き換えます。

元の etcd API ルート CA を削除します。

gcloud privateca roots delete ORIGINAL_ETCD_API_ROOT_CA \
    --pool=ETCD_API_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

ORIGINAL_ETCD_API_ROOT_CA は、ローテーションする元の etcd API ルート CA の名前に置き換えます。

元の etcd ピアルート CA を削除します。

gcloud privateca roots delete ORIGINAL_ETCD_PEER_ROOT_CA \
    --pool=ETCD_PEER_CA_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=KEY_PROJECT_ID \
      --ignore-active-certificates

ORIGINAL_ETCD_PEER_ROOT_CA は、ローテーションする元の etcd ピアルート CA の名前に置き換えます。

省略可: ルート CA への変更をクラスタの信頼バンドルに伝播します。手順については、コントロールプレーンとノードを再起動するをご覧ください。この手順をスキップすると、次のコントロールプレーンとノードのバージョンアップグレード時に元のルート CA が削除されます。

コントロールプレーンとノードを再起動する

ルート CA の有効化、ルート CA の無効化、証明書の取り消しなど、クラスタのルート CA 構成を変更する場合は、その変更をクラスタの信頼バンドルに伝播する必要があります。クラスタの信頼バンドルに変更を伝播するには、コントロールプレーンと（一部のシナリオでは）ノードを再起動します。

クラスタコントロールプレーンを、すでに使用しているバージョンにアップグレードします。

注意: ゾーンクラスタでは、アップグレードオペレーションが完了するまでコントロールプレーンが使用できなくなります。Autopilot クラスタとリージョン Standard クラスタでは、コントロールプレーンは引き続き使用できます。
1. コントロールプレーンですでに使用されている GKE バージョンを確認します。
```
gcloud container clusters describe CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --format="value(currentMasterVersion)"
```
  次のように置き換えます。
  - CLUSTER_NAME: GKE クラスタの名前。
  - CLUSTER_VERSION: クラスタがすでに実行している GKE バージョン。
  - CLUSTER_PROJECT_ID: クラスタプロジェクトのプロジェクト ID。
2. コントロールプレーンをアップグレードします。
```
gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=CLUSTER_VERSION \
    --project=CLUSTER_PROJECT_ID
```
Kubernetes CertificateSigningRequests を使用して証明書を手動で生成する場合は、それらの証明書をすべて再発行し、新しい証明書を API クライアントに提供します。
クラスタルート CA ローテーションのみの場合は、各ノードプールをすでに使用しているバージョンにアップグレードして、ノードの再作成をトリガーします。

注意: GKE は、この変更に対し、ノードアップグレード戦略を使用してノードの再作成を直ちに開始します。有効なメンテナンスポリシーがある場合も同様です。GKE は、変更に際し、リソースの可用性に依存します。ノードの自動アップグレードを無効にしても、この変更を防ぐことはできません。この変更を開始する前に、ノードで実行されているワークロードが中断に対応できるよう準備してください。
1. ノードプールが使用している GKE バージョンを確認します。
```
gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --project=CLUSTER_PROJECT_ID \
    --format="value(version)"
```
  NODE_POOL_NAME は、アップグレードするノードプールの名前に置き換えます。
2. ノードプールをアップグレードします。
```
gcloud container clusters upgrade CLUSTER_NAME \
    --node-pool=NODE_POOL_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=CLUSTER_VERSION \
    --project=CLUSTER_PROJECT_ID
```

CA ローテーション中にこのセクションの手順を行った場合は、ローテーションの次のフェーズに進みます。このページの次のいずれかのセクションをご覧ください。

元のルート CA を新しいルート CA に置き換えます。
元のルート CA を削除します。

お客様が管理するコントロール プレーンの CA と鍵をローテーションする コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

認証情報のローテーションを計画する

始める前に

必要なロールと権限

制限事項

サービス アカウントの署名鍵と検証鍵をローテーションする

GKE control plane authority の CA をローテーションする

CA の新しい鍵バージョンを作成する

新しいルート CA を作成する

元のルート CA を新しいルート CA に置き換える

元のルート CA を削除する

コントロール プレーンとノードを再起動する

次のステップ

お客様が管理するコントロールプレーンの CA と鍵をローテーションする

サービスアカウントの署名鍵と検証鍵をローテーションする

コントロールプレーンとノードを再起動する