GKEノードのブートディスクをCMEKで暗号化して鍵をローテーションしてみた

flowchart TB
    subgraph GCP["Google Cloud"]
        KMS["Cloud KMS
鍵バージョン 1 / 2"]
        subgraph VPC["VPC"]
            subgraph GkeSubnet["GKE Subnet（外部IPなし）"]
                NP1["ノードプール v1
ディスク = 鍵バージョン 1"]
                NP2["ノードプール v2
ディスク = 鍵バージョン 2"]
            end
            Bastion["踏み台"]
        end
    end

    KMS -->|"作成時のprimaryで暗号化"| NP1
    KMS -->|"作成時のprimaryで暗号化"| NP2
    Bastion -->|"kubectl"| NP1

ノードプールは2つともboot_disk_kms_keyに同じ鍵を指定しています。違うのは作られた時刻だけです。

移行を3フェーズに分ける
#

鍵を回した時点では何も動きません。 動くのはノードプールを足したときで、そのずれをterraform planは見つけられません。

sequenceDiagram
    participant OP as 運用者
    participant KMS as Cloud KMS
    participant V1 as ノードプール v1
    participant V2 as ノードプール v2
    participant TF as terraform plan

    Note over V1: ディスクは鍵バージョン 1
    OP->>KMS: versions create --primary
    KMS-->>OP: バージョン 2 が primary（1 は ENABLED のまま）
    KMS--xV1: 既存ディスクは再暗号化されない
    Note over V1: 再作成なし・Pod 再起動 0 回
    OP->>TF: plan
    TF-->>OP: No changes（ずれを検知できない）
    OP->>V2: create_v2_node_pool = true で apply
    KMS->>V2: 作成時の primary（2）で暗号化
    OP->>V1: keep_v1_node_pool = false で削除
    Note over V1,V2: ただし v1 をスケールアウトしても新バージョンになる（後述）

移行の各段階をterraform applyだけで進められるよう、変数2つで制御しています。

フェーズ	`keep_v1_node_pool`	`create_v2_node_pool`	状態
1. 初期	`true`	`false`	v1のみ
2. ローテーション後	`true`	`true`	v1 + v2
3. 移行完了	`false`	`true`	v2のみ

resource "google_container_node_pool" "v1" {
  count = var.keep_v1_node_pool ? 1 : 0
  # ...
  node_config {
    boot_disk_kms_key = google_kms_crypto_key.boot_disk.id
    # ...
  }
}

resource "google_container_node_pool" "v2" {
  count = var.create_v2_node_pool ? 1 : 0
  # ...
  node_config {
    boot_disk_kms_key = google_kms_crypto_key.boot_disk.id
    # ...
  }
}

CMEKを有効にするために要るもの
#

ブートディスクを作るのはGKEではなくCompute Engineです。そのため、Compute Engineのサービスエージェントに鍵の使用権限が要ります。これがないとノードプールの作成そのものが失敗します。

resource "google_kms_crypto_key_iam_member" "compute_agent" {
  crypto_key_id = google_kms_crypto_key.boot_disk.id
  role          = "roles/cloudkms.cryptoKeyEncrypterDecrypter"
  member        = "serviceAccount:service-${data.google_project.current.number}@compute-system.iam.gserviceaccount.com"
}

resource "google_kms_crypto_key_iam_member" "container_agent" {
  crypto_key_id = google_kms_crypto_key.boot_disk.id
  role          = "roles/cloudkms.cryptoKeyEncrypterDecrypter"
  member        = "serviceAccount:service-${data.google_project.current.number}@container-engine-robot.iam.gserviceaccount.com"
}

鍵のロケーションはノードが動くリージョンと一致させます。別ロケーションの鍵ではディスクを暗号化できません。

実行
#

terraform apply

Apply complete! Resources: 27 added, 0 changed, 0 destroyed.

鍵のパスとディスクの鍵バージョン
#

まずノードのブートディスクを見ます。

gcloud compute disks list --filter="name~gke-tf-adv-gke-cmek" \
  --format="table(name,creationTimestamp,diskEncryptionKey.kmsKeyName)"

NAME                                                 CREATION_TIMESTAMP             KMS_KEY_NAME
gke-tf-adv-gke-cmek-tf-adv-gke-cmek-n-aadc2c38-6xm3  2026-09-03T17:03:25.939-07:00  projects/YOUR_PROJECT_ID/locations/asia-northeast1/keyRings/tf-adv-gke-cmek-ring/cryptoKeys/tf-adv-gke-cmek-boot-disk/cryptoKeyVersions/1

ここが以降の話の起点になります。Terraformに書いたのは鍵のパス（.../cryptoKeys/KEY）までです。一方ディスクが持っているのはバージョンまで含んだ名前（.../cryptoKeyVersions/1）です。

Terraformの設定にはバージョンが現れません。 この非対称が、あとで効いてきます。

ワークロードを置いて疎通を確認しておきます。kubectlは踏み台から実行します。

kubectl apply -f 01-nginx.yaml -f 02-curl.yaml
kubectl exec curl-client -- curl -s -o /dev/null -w "HTTP %{http_code}\n" http://nginx-cmek/

HTTP 200

鍵をローテーションする
#

gcloud kms keys versions create --key=tf-adv-gke-cmek-boot-disk \
  --keyring=tf-adv-gke-cmek-ring --location=asia-northeast1 --primary

Successfully created key version [2] and set it as the primary version.

NAME                     STATE
.../cryptoKeyVersions/1  ENABLED
.../cryptoKeyVersions/2  ENABLED

バージョン2がprimaryになりました。バージョン1は有効なままです。

ローテーション後、既存ノードは何も変わらない
#

gcloud compute disks list --filter="name~gke-tf-adv-gke-cmek" \
  --format="table(name,creationTimestamp,diskEncryptionKey.kmsKeyName.basename())"

NAME                                                 CREATION_TIMESTAMP             KMS_KEY_NAME
gke-tf-adv-gke-cmek-tf-adv-gke-cmek-n-aadc2c38-6xm3  2026-09-03T17:03:25.939-07:00  1

ディスクは鍵バージョン1のままです。creationTimestampも変わっていないので、ノードは再作成されていません。

kubectl get pods -o custom-columns=NAME:.metadata.name,RESTARTS:.status.containerStatuses[0].restartCount
kubectl exec curl-client -- curl -s -o /dev/null -w "HTTP %{http_code}\n" http://nginx-cmek/

NAME                          RESTARTS
curl-client                   0
nginx-cmek-5678d55d86-4hfsz   0
HTTP 200

Podの再起動も0回。疎通も維持されています。既存データが自動で再暗号化されることはありません。

Terraformはこのずれを検知できない
#

ここが実運用でいちばん危ないところです。

terraform plan

No changes. Your infrastructure matches the configuration.

差分なしで通ります。 設定にあるのは鍵のパスだけなので、ディスクが実際に使っているバージョンは比較対象になりません。

つまり「鍵を回したのに古いバージョンのノードが残っている」状態でも、planはクリーンなままです。移行が終わったかどうかはgcloud compute disks listで確認します。

新しいノードプールは新しい鍵バージョンを使う
#

create_v2_node_pool = true にして再度applyします。

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

NAME                                                 CREATION_TIMESTAMP             KMS_KEY_NAME
gke-tf-adv-gke-cmek-tf-adv-gke-cmek-n-aadc2c38-6xm3  2026-09-03T17:03:25.939-07:00  1
gke-tf-adv-gke-cmek-tf-adv-gke-cmek-n-dcf2a6c2-hlmr  2026-09-03T17:06:31.786-07:00  2

2つのノードプールはboot_disk_kms_keyに同じ値を書いています。違うのは作られた時刻だけで、それが鍵バージョンを分けています。

ノードプールの入れ替えは、実は要らない
#

ここで想定と違う結果が出ました。旧ノードプール（v1）をそのままスケールアウトしてみます。

この試験は、後述する旧鍵の無効化と自動修復のあとに実施しています。記事の並び順とは前後します。

gcloud container clusters resize tf-adv-gke-cmek \
  --node-pool=tf-adv-gke-cmek-np-v1 --num-nodes=2 --zone=asia-northeast1-a

NAME                                                 CREATION_TIMESTAMP             KMS_KEY_NAME
gke-tf-adv-gke-cmek-tf-adv-gke-cmek-n-aadc2c38-6xm3  2026-09-03T17:24:23.695-07:00  2
gke-tf-adv-gke-cmek-tf-adv-gke-cmek-n-aadc2c38-pb8w  2026-09-03T17:25:41.514-07:00  2
gke-tf-adv-gke-cmek-tf-adv-gke-cmek-n-dcf2a6c2-hlmr  2026-09-03T17:06:31.786-07:00  2

6xm3 は自動修復で作り直された結果すでにバージョン2で、このスケールアウトで増えたのは pb8w です。

v1プールに追加された pb8w も鍵バージョン2でした。

ノードプールが保持しているのは鍵のパスだけです。ディスクは作られた時点のprimaryバージョンで暗号化されます。

よく見る「ブートディスクのCMEKは既存ノードプールで変更できない」という説明は、どの鍵を使うかを変える場合の話です。鍵のバージョンを進めるだけなら、ノードが作り直されればよく、ノードプールを分ける必要はありません。

裏を返すと、ノードが入れ替わるたびに、そのときの primary が使われます。自動アップグレード・自動修復・オートスケールのいずれでも同じです。ローテーションを挟んだあとは、クラスタ内に複数の鍵バージョンが混ざりえます。

primary が変わっていなければ、作り直しても同じバージョンのままです。

ノードを作り直さずに、ディスクの鍵バージョンを直接進める手段もあります。gcloud compute disks update-kms-key です。

ただし2つ引っかかります。Terraform で作成・管理している CMEK ディスクは、この方法で変更できないと明記されています。

一方、ここで対象になるのは GKE が作るノードのブートディスクです。Terraform が直接持っているものではありません。どちらに当たるかは今回試していません。

移行中の断を測る
#

ここからは、ノードプールを入れ替える移行で実際にどれだけ止まるかを見ます。

kubectl drainを実行しながら、毎秒1回HTTPリクエストを送りました。000はcurlがHTTPの応答コードを1つも受け取らなかったことを示します。接続失敗に限らず、名前解決の失敗やTLSの失敗も同じ値になります。

ステータス行を受け取ったあとに本文が途切れた場合は、200のままです。

計測は次のコマンドです。sleep 1なので間隔は1秒より少し長くなります。

while true; do
  kubectl exec curl-client -- curl -s -o /dev/null -m 2 -w '%{http_code} ' http://nginx-cmek/
  sleep 1
done

計測用のPodは移行先（v2）のノードに固定しています（03-curl-pinned-v2.yaml）。固定しないと、計測用Pod自体がdrainで退避されて測定が止まります。

レプリカ1個では21回連続で応答が取れない
#

200 200 200 200 200 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 200
     21 000
      6 200

21回連続で、応答コードを1つも取れませんでした。 毎秒1回のサンプリングなので21秒前後ですが、各リクエストの時刻は記録していません。

Podが1個しかないので、退避された瞬間からServiceのエンドポイントが空になります。新しいPodがReadyになるまで受け先がありません。

drainの前後だけを見ると両方200なので、「疎通は継続した」と誤って結論できてしまいます。移行の断を測るには、drainしている最中にサンプリングし続ける必要があります。

2レプリカ + PodDisruptionBudget でも5回失敗した
#

レプリカを2個にし、podAntiAffinityで別ノードに分け、minAvailable: 1のPodDisruptionBudgetを付けました。今度はkube-dnsを経路から外すため、ServiceのClusterIPに直接リクエストしています。

000 000 000 200 000 200 200 000 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200
      5 000
     25 200

連続した失敗は短くなりましたが、30サンプル中5回失敗しました。失敗は1・2・3・5・8番目で、最初と最後は7サンプル離れています。各リクエストの時刻を記録していないので、失敗が続いた時間そのものは確定できません。

退避されたPodには停止シグナルが送られます。どのシグナルになるかはイメージの STOPSIGNAL 次第で、nginx では TERM が即時終了、QUIT が正常終了です。

一方、他ノードのkube-proxyがエンドポイントを外し終えるまでには遅れがあります。すでに落ちたPodにリクエストが振られたという説明は筋が通りますが、この計測では因果まで確かめていません。 確かめるなら、Podの終了時刻とエンドポイントの更新時刻を突き合わせます。

PodDisruptionBudgetは「同時に何個まで止めてよいか」を制御するものです。 エンドポイント伝播の遅れは面倒を見ません。

preStopを足すと失敗が0になった
#

preStop: sleep 20とterminationGracePeriodSeconds: 40を追加します。

spec:
  terminationGracePeriodSeconds: 40
  containers:
    - name: nginx
      lifecycle:
        preStop:
          exec:
            command: ["sleep", "20"]

200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200 200
     33 200

33回すべて200でした。コンテナは終了要求を受けてもすぐには止まらず、sleep 20のあいだ応答を返し続けます。

固定時間のsleepは「エンドポイントが外れ切るまで待つ」ことを保証しません。 伝播が20秒を超えれば同じ失敗が出ます。観測した範囲で失敗が無かった、というところまでです。

terminationGracePeriodSecondsはsleepより長くします。短いと、フックが返る前にkubeletがコンテナを殺します。

構成	測定先	結果
レプリカ1個	Service名	21回連続で応答コードを取れず
2レプリカ + anti-affinity + PDB	ClusterIP	30回中5回失敗
＋ `preStop: sleep 20`	ClusterIP	33回中0回失敗

測定先が途中で変わっているので、差のすべてをレプリカ構成に帰せません。 また、これは観測した回数の話で、無停止を保証するものでもありません。比較を強めるなら測定先を揃え、時刻付きで複数回測ります。

旧鍵バージョンを無効化するとどうなるか
#

鍵バージョン1で暗号化されたノードが稼働している状態で、バージョン1を無効化しました。

gcloud kms keys versions disable 1 --key=... --keyring=... --location=asia-northeast1

state: DISABLED

NAME                                                  STATUS                     AGE
gke-tf-adv-gke-cmek-tf-adv-gke-cmek-n-aadc2c38-6xm3   Ready,SchedulingDisabled   19m
gke-tf-adv-gke-cmek-tf-adv-gke-cmek-n-dcf2a6c2-hlmr   Ready                      16m
HTTP 200

今回の構成では、稼働中に見えている範囲では何も起きませんでした。 ノードはReadyのままで、HTTPも200を返しました。

ただしこれは、旧鍵のディスクの読み書きを直接確かめたものではありません。 6xm3はSchedulingDisabledで、200を返したのがどちらのノードかも示していません。確かめるなら、対象ノードに固定したPodからそのノードのディスクに書き込みます。

ディスクの暗号化に使う鍵はすでに展開済みなので読み書きは続く、というのが仕組み上の説明です。保存データが平文になるわけではありません。

これは無条件ではありません。VM には鍵を失効させたときに自動停止する設定（key_revocation_action_type）があり、STOP にすると失効から7時間以内に停止します。既定は NONE で、今回は指定していません。

問題は再起動したときに出ます。

gcloud compute instances stop gke-tf-adv-gke-cmek-...-6xm3 --zone=asia-northeast1-a
gcloud compute instances start gke-tf-adv-gke-cmek-...-6xm3 --zone=asia-northeast1-a

ERROR: (gcloud.compute.instances.start) HTTPError 400: Cloud KMS error when using key
projects/YOUR_PROJECT_ID/locations/asia-northeast1/keyRings/tf-adv-gke-cmek-ring/cryptoKeys/tf-adv-gke-cmek-boot-disk/cryptoKeyVersions/1:
... is not enabled, current state is: DISABLED.

起動できません。

「無効化しても平気だった」ように見えるのは、たまたま誰も停止・起動していないだけです。

ただし、ここで失敗したのは既存ディスクをそのまま起動する経路です。自動アップグレードや自動修復はノードごと作り直すので、新しいディスクは当時の primary で暗号化されます。

実際、次の節ではその経路で復旧しました。同じ失敗になるとは限りません。

GKEは自動修復するが、その間ノードは落ちている
#

上の状態を放置していたら、GKEがノードを復旧させました。

gcloud logging read 'protoPayload.methodName=("compute.instances.repair.recreateInstance" OR "v1.compute.instances.insert" OR "v1.compute.instances.delete")' \
  --format="table(timestamp,protoPayload.methodName,protoPayload.authenticationInfo.principalEmail)"

TIMESTAMP                    METHOD_NAME                                PRINCIPAL_EMAIL
2026-09-04T00:24:33.634564Z  v1.compute.instances.insert                service-YOUR_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
2026-09-04T00:24:23.010680Z  v1.compute.instances.insert                service-YOUR_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
2026-09-04T00:24:21.743331Z  v1.compute.instances.delete                service-YOUR_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com
2026-09-04T00:23:31.965354Z  compute.instances.repair.recreateInstance  system@google.com

ノード名は同じですがcreationTimestampが新しくなり、新しいブートディスクは鍵バージョン2で作られていました。

結果的に自己修復はします。ただし、その間ノードは落ちています。無効化の前に旧バージョンを使うノードが残っていないことを確認するという手順は省けません。

移行完了を確認してから無効化する
#

keep_v1_node_pool = false にしてapplyします。

Apply complete! Resources: 0 added, 0 changed, 1 destroyed.

無効化の前に、旧バージョンを使うディスクが残っていないことを確認します。

gcloud compute disks list \
  --filter="name~gke-tf-adv-gke-cmek AND diskEncryptionKey.kmsKeyName~cryptoKeyVersions/1$" \
  --format="value(name)" | wc -l

この形は危ういです。 gcloudが失敗して標準出力が空でもwc -lは0を返すので、「残っていない」と「一覧を取れなかった」が同じ値になります。判断に使うなら終了コードを見ます。

disks=$(gcloud compute disks list \
  --filter="name~gke-tf-adv-gke-cmek AND diskEncryptionKey.kmsKeyName~cryptoKeyVersions/1$" \
  --format="value(name)") || { echo "一覧を取得できませんでした" >&2; exit 2; }
[ -z "$disks" ] && echo "残存0件"

前の試験でバージョン1はすでに無効化しています。 そのあと自動修復の挙動を見るために再度有効化してから、ここで改めて無効化しました。有効化の手順は載せていません。

残存0件を確認してから無効化します。

NAME  STATE
1     DISABLED
2     ENABLED
HTTP 200

影響は出ませんでした。

移行先プールのサイズに注意
#

podAntiAffinityをrequiredDuringSchedulingで指定していると、v1プールを削除して1ノードだけになったとき、2つ目のレプリカが配置できません。

NAME                          READY   STATUS    AGE
nginx-cmek-77d8bffdbc-6lg74   0/1     Pending   106s
nginx-cmek-77d8bffdbc-wph68   1/1     Running   104s

移行先のノードプールは、移行元のワークロードを丸ごと収容できるサイズにしてから旧プールを削除します。

maxSurgeの既定値は25%で、切り上げると1です。このままローリング更新をかけると3つ目のPodを作ろうとし、アンチアフィニティに阻まれてロールアウトが終わりません。

Warning  FailedScheduling  default-scheduler
  0/2 nodes are available: 1 Insufficient cpu, 1 node(s) didn't match pod anti-affinity rules.

2ノードで2レプリカを別ノードに固定するなら、maxSurge: 0 / maxUnavailable: 1にします。

Cloud Loggingに残るもの
#

gcloud logging read 'protoPayload.serviceName="cloudkms.googleapis.com"' \
  --format="table(timestamp,protoPayload.methodName,protoPayload.resourceName.basename())"

TIMESTAMP                       METHOD_NAME                    RESOURCE_NAME
2026-09-04T00:24:32.745742413Z  UpdateCryptoKeyVersion         1
2026-09-04T00:22:54.283612977Z  UpdateCryptoKeyVersion         1
2026-09-04T00:05:30.699113171Z  UpdateCryptoKeyPrimaryVersion  tf-adv-gke-cmek-boot-disk
2026-09-04T00:05:30.558472618Z  CreateCryptoKeyVersion         tf-adv-gke-cmek-boot-disk
2026-09-03T23:55:22.169578524Z  SetIamPolicy                   tf-adv-gke-cmek-boot-disk
2026-09-03T23:55:17.567414618Z  SetIamPolicy                   tf-adv-gke-cmek-boot-disk
2026-09-03T23:55:16.899849634Z  CreateCryptoKey                tf-adv-gke-cmek-boot-disk
2026-09-03T23:55:16.561706287Z  CreateKeyRing                  tf-adv-gke-cmek-ring

ローテーション（CreateCryptoKeyVersion + UpdateCryptoKeyPrimaryVersion）と、有効化・無効化（UpdateCryptoKeyVersion）は追えます。

一方、ディスク暗号化で鍵が使われた記録は出ません。

gcloud logging read 'protoPayload.serviceName="cloudkms.googleapis.com" AND protoPayload.methodName=~"Encrypt|Decrypt"' --limit=5

（0件）

データアクセス監査ログが既定で無効なためです。この0件は、有効にしていないことの結果です。

Encrypt と Decrypt はCloud KMS の監査ログ対象に DATA_READ として載っています。鍵の利用を追跡したい場合は明示的に有効化します（課金対象）。

ただし「どのノードが」まで対応づけられるかは、今回確かめていません。 KMS API の呼び出し記録と、個々のノードへの紐づけは別の確認になります。

GKEのPodにSecret Managerの値をファイルとしてマウントするでも同じ構図がありました。管理操作は残るが、値や鍵の利用は残らない。Cloud KMSでも同じです。

後片付け
#

terraform destroy

Destroy complete! Resources: 27 destroyed.

terraform destroy では Cloud KMS のキーリングと鍵は消えません。 stateからは消えますが、実体はプロジェクトに残ります。

鍵バージョンは破棄がスケジュールされます。

NAME                       PURPOSE          PRIMARY_ID  PRIMARY_STATE
tf-adv-gke-cmek-boot-disk  ENCRYPT_DECRYPT  2           DESTROY_SCHEDULED

ただし「Google Cloud で削除できない」わけではありません。 鍵と鍵バージョンの削除は2026年3月2日、キーリングの削除は2026年8月24日に一般提供されています。削除には条件があり、Terraform が消さないというだけです。今回は削除を試していません。

破棄がスケジュールされた鍵バージョンは、その期間なら復元できます。復元して enable すれば再び使えるので、DESTROY_SCHEDULED は再利用できない理由になりません。

再利用できないのは削除した鍵の名前のほうです。

names of deleted keys can’t be reused — Destroy and restore key versions

残っている鍵を import して使うのと、消した名前で作り直すのは別の話です。課金は鍵バージョン単位でごくわずかです。

GKE・踏み台VM・Cloud NATは利用中に料金が発生します。

まとめ
#

鍵をローテーションしても既存ノードは変わらない。 ディスクは旧バージョンのまま、ノード再作成も起きない
terraform planはこのずれを検知できない。 設定にあるのは鍵のパスだけ。移行の完了はgcloud compute disks listで確認する
鍵バージョンを進めるだけならノードプールの入れ替えは不要。 旧プールをスケールアウトしただけで新ノードは新バージョンになった。ノードプールを分けるのは「どの鍵を使うか」を変える場合
移行中の断は構成で変わった。 レプリカ1個で21回連続の失敗、2レプリカとPDBで30回中5回、preStopを足して33回中0回。ただし測定先を途中で変えており、無停止の保証でもない
旧鍵バージョンの無効化は、今回の構成では稼働中に影響が見えなかった。 影響が出たのは既存ディスクで起動し直したとき。ただしkey_revocation_action_type = STOPにしてあれば失効から7時間以内に停止するので、無条件ではない
鍵の利用は、データアクセス監査ログを有効にすれば残る。 既定では無効なので今回は0件だった。管理操作は既定で追える