【入門編】KubernetesにおけるSecretリソースの暗号化とKMS連携 – アプリケーションセキュリティ & 安全な開発防御ガイド

こんにちは！セキュリティの世界へようこそ。
日々、開発や運用に追われる中で「セキュリティ」という言葉を聞くと、なんだか気が重くなりますよね。「面倒くさそう」「専門用語ばかりで何をすればいいのか分からない」……そんな気持ち、よく分かります。

でも、安心してください。今日は、Kubernetesを使っているエンジニアなら絶対に避けては通れない、でも意外と見落としがちな「Secret（秘密情報）の守り方」について、身近な例え話を交えて紐解いていきましょう。

—

1. なぜ、KubernetesのSecretは「裸」に近いのか？

まずは、Kubernetesにおける「Secret」という機能についてお話ししますね。名前からすると「秘密を守ってくれる魔法の箱」のように聞こえますが、実は少し誤解があるんです。

標準状態のKubernetesでは、Secretリソースは「Base64でエンコード」された状態で `etcd` というデータベースに保存されます。
これを例えるなら、「中身を透かして見たらすぐバレる、透明な封筒」に入れて郵便ポストに入れているようなものです。Base64は「暗号」ではなく、単なる「変換」に過ぎません。

もし、悪意のある攻撃者がデータベース（etcd）に直接アクセスできてしまったら……？
彼らは一瞬であなたのデータベースのパスワードや、クラウドのアクセスキーを盗み出せてしまいます。これが「泥棒が家の合鍵を玄関のマットの下に隠している」のと同じくらい危うい状況であることは、想像に難くないですよね。

—

2. 「Encryption at Rest（保存時の暗号化）」という最強の防犯カメラ

そこで登場するのが「Encryption at Rest（保存時の暗号化）」という考え方です。

これは、先ほどの「透明な封筒」を、「物理的に壊さないと絶対に開けられない頑丈な金庫」に入れ直すような作業です。さらに、その金庫の鍵をあなた自身が管理するのではなく、「信頼できる警備会社（KMS：Key Management Service）」に預けてしまうのです。

AWSならKMS、GCPならCloud KMSといったサービスが、その「警備会社」の役割を果たします。これによって、たとえ泥棒がデータベースを盗み出しても、肝心の「金庫の鍵」が警備会社の手元にあるため、中身を読み解くことができなくなります。

—

3. 実践！KMS連携の設定をのぞいてみよう

では、実際にどう設定するかを見ていきましょう。Kubernetesには「EncryptionConfiguration」という設定ファイルが存在します。これをマスターノード（kube-apiserver）に読み込ませることで、魔法が始まります。

以下は、AWS KMSを利用する場合のイメージ設定ファイルです。

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:

resources:
secrets # Secretリソースを暗号化の対象にするよ！

providers:

kms:

# ここにAWS KMSのキーIDを指定します
name: my-kms-provider
key: arn:aws:kms:ap-northeast-1:123456789012:key/あなたのキーID
# キャッシュの時間を設定して、パフォーマンスを維持するよ
cachesize: 100

identity: {} # 万が一KMSが使えない時のために、最後は「暗号化なし」を置くのが定石

この設定のポイント

providers: 複数の暗号化方式を指定できます。一番上に書いたものが「メインの鍵」として使われます。
identity: もしKMSとの通信がうまくいかなくても、とりあえず既存のデータにアクセスできるようにするための「安全装置」です。

—

4. セキュリティ担当からの「泥臭い」アドバイス

ここまで設定すれば万全……と言いたいところですが、現場ではもう少しだけ「泥臭い」配慮が必要です。

1. 鍵の権限管理（IAM）を厳格に:
Kubernetesのノード（APIサーバー）が、KMSの鍵を使うための権限を最小限に絞ってください。「誰でも鍵を使える」状態は、結局「鍵を玄関先に置いている」のと変わりません。
2. 鍵のローテーション:
一生同じ鍵を使い続けるのは、防犯上あまり良くありません。年に一度は新しい鍵に切り替える（ローテーションする）運用を検討しましょう。
3. etcdへのアクセス制限:
そもそも、etcd自体に誰もがアクセスできない環境（ネットワークの分離など）を作るのが、究極の防御です。

—

最後に：一歩ずつ、確実に。

「暗号化」と聞くと難しく感じるかもしれませんが、要は「大事なものには、自分たちだけの鍵をかけよう」という、ごく当たり前の防犯意識の話です。

まずは、今動いているクラスターが「暗号化されているのか？それとも透明な封筒のままなのか？」を確認することから始めてみませんか？
分からないことがあれば、いつでもまた聞きに来てくださいね。一つずつ、一緒にセキュリティの階段を登っていきましょう！