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

Fri, 04 Sep 2026 00:00:00 +0900

概要
#

顧客管理の暗号鍵（CMEK）でGKEノードのブートディスクを暗号化すると、鍵の管理責任がこちらに移ります。定期的なローテーションもその一つです。

ところが鍵をローテーションしても、稼働中のノードは何も変わりません。ディスクは古い鍵バージョンで暗号化されたままです。しかもterraform planは差分なしで通ります。「回したから終わり」と思って旧バージョンを無効化すると、次にノードが再起動したとき起動できません。

この記事では、鍵をローテーションしたあと何が起きるかを実測します。新しい鍵バージョンへの移し方と、移行中にサービスがどれだけ止まるかまで見ます。

対象読者は、GKEのクラスタをTerraformで作ったことがあり、Cloud KMSの鍵を触ったことがある人です。それぞれの入門は扱いません。

Blue/Greenアップグレードを使った移行は扱いません。etcdやPersistentVolumeのCMEKも扱いません。ノードのブートディスクだけを見ます。

検証すること
#

鍵をローテーションしたあと、既存ノードのブートディスクはどうなるか
ローテーション後のterraform planは差分を検知するか
新しい鍵バージョンにするには、本当にノードプールの入れ替えが必要か
ノードプールを入れ替える移行で、サービスはどれだけ止まるか
旧鍵バージョンを無効化すると何が起きるか
Cloud Loggingに何が残るか

前提環境
#

Google Cloud CLI、Terraform
Billingが有効な検証用Google Cloud Project
GKE、Cloud KMS、Compute Engineを操作できるGoogleアカウント
検証時のバージョン：Terraform 1.14.5、google 7.46.0、GKE 1.35.7-gke.1027000（REGULARチャネル）

使用するTerraformコード
#

Advanced-Examples/20-gke-cmek-node-boot-disk-rotation

今回の構成
#

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に同じ鍵を指定しています。違うのは作られた時刻だけです。

CMEK on LIFELOG

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

概要 #

検証すること #

前提環境 #

使用するTerraformコード #

今回の構成 #

概要
#

検証すること
#

前提環境
#

使用するTerraformコード
#

今回の構成
#