序章：環境変数という名の「パンドラの箱」
「おい、またやったのか……」
インシデントレスポンスの現場で、私は何度このセリフを吐いたことだろう。深夜に鳴り響くアラート、徹夜でのフォレンジック調査。その原因をたどると、決まってコンテナの環境変数（Environment Variables）にベタ書きされたDBのマスターパスワードや、APIのプライベートキーに行き着く。
Kubernetes（K8s）のデプロイメントマニフェストを見れば、堂々と value: "super-secret-key" と書かれている。これを「シークレット管理だ」と信じ込んでいるジュニアエンジニアやマネージャーを見ると、私は頭を抱えたくなる。
環境変数は、セキュリティの観点から言えば「丸裸でプロセス空間を歩き回る機密情報」に他ならない。Linuxのプロセス設計思想において、環境変数は /proc/[PID]/environ を読める権限さえあれば、同一ノード上のコンテナエスケープや、誤って外部出力されたデバッグログから一網打尽に窃取できる。コンテナイメージのレイヤーに焼き付こうものなら、Docker Hubのパブリックリポジトリに世界中へ向けて自ら鍵をばら撒いているようなものだ。
クラウドネイティブ時代の要塞化（ハーデニング）において、もはや「設定ファイルや環境変数にシークレットを置かない」ことは大前提である。今回は、K8s標準の Secret の限界と、HashiCorp Vaultを用いた動的シークレット注入による真のゼロ・トラスト・アーキテクチャについて、現場の泥臭い知見を交えて徹底的に解説しよう。
—
第1章：K8s Secretsの残酷な真実とメモリ上の脆弱性
多くの組織が「Kubernetesを使っているから安全だ」という神話を信じ込んでいる。K8sには Secret という専用のリソースが存在し、Base64エンコードされて保存される。
だが、セキュリティをかじった人間なら誰でも知っている通り、Base64は暗号化ではなく、単なるエンコード（文字列表現の変換）に過ぎない。 kubectl get secret my-secret -o jsonpath='{.data.password}' | base64 -d と叩けば、誰でも平文を拝むことができる。
etcdの暗号化という「気休め」
「じゃあ、etcdの暗号化（EncryptionConfiguration）を有効にすればいいんだろう？」という声が聞こえてきそう確かに、etcdの保存データ自体はAES-CBCなどで暗号化される。しかし、それは「ストレージ層での静止データ（Data at Rest）の保護」に過ぎない。
アプリケーションが起動し、K8sの Secret を環境変数やボリュームマウントとしてコンテナ内に取り込んだ瞬間、そのデータは平文としてメモリ上に展開される。
もし、アプリケーションにRCE（リモートコード実行）やSSRF、あるいはメモリ上のダンプを取得される脆弱性が存在した場合、攻撃者はLinuxの /proc/PID/mem やコアダンプから容赦なくシークレットを回収する。
さらに言えば、RBAC（Role-Based Access Control）の設定を少しでもミスし、get や list 権限を不要なサービスアカウントに付与していれば、etcdの暗号化など何の意味も持たない。K8s Secretsは、本番環境の厳格な監査要件（PCI-DSSやSOC2など）をクリアするには、あまりにも機能が不足しているのだ。
—
第2章：HashiCorp Vaultによる動的シークレット（Dynamic Secrets）の防衛ロジック
静的なシークレットを排除し、真のセキュリティを実現するためのゴールドスタンダードが HashiCorp Vault である。Vaultの本質は、単なる「鍵の保管庫」ではない。「必要になった瞬間に生成され、用が済んだら自動消滅する動的シークレット（Dynamic Secrets）のエンジン」である点に最大の強みがある。
静的シークレット vs 動的シークレット
- 静的シークレット（K8s Secrets等）: 一度発行された長寿命の認証情報を永続的に使い回す。漏洩した際の影響範囲が極めて広く、失効（Revocation）のプロセスが泥臭く困難。
- 動的シークレット（Vault）: アプリケーションからのリクエストに応じて、その都度データベース等のバックエンドシステムに対して一時的な権限を持つクレデンシャルを動的に発行する。TTL（Time-To-Live）が切れると自動的に失効し、データベース側からもユーザーが削除される。
このアプローチにより、「万が一、コンテナが侵害されてシークレットが抜かれたとしても、その時にはすでにTTLが切れて無効化されている」という時間差攻撃への耐性を獲得できる。
—
第3章：実践アーキテクチャ – Vault Agent Injectorによるシークレットのインメモリ注入
クラウドネイティブ環境において、VaultとKubernetesを統合する最もエレガントかつセキュアな手法が、Vault Agent Injector の利用である。
これは、K8sのMutating Webhookを利用して、Podの作成時にサイドカーコンテナ（Vault Agent）を自動挿入し、アプリケーションコンテナのファイルシステムやメモリ上に直接、安全にシークレットをレンダリングする仕組みだ。環境変数を一切経由しないため、/proc からの窃取リスクを完全にシャットアウトできる。
以下に、実務でそのまま使えるKubernetesデプロイメントマニフェストと、Vault側の設定アノテーションの具体例を示す。
1. Vault側でのKubernetes認証バックエンドの設定（管理者向け）
まず、Vault側でK8sのService Accountトークンを検証できるようにKubernetes認証を有効化する。
# Kubernetes認証方式を有効化
Vault auth enable kubernetes
# K8sのAPIサーバーのアドレスとCA証明書を設定
Vault write auth/kubernetes/config \
kubernetes_host="https://kubernetes.default.svc:443"
# アプリケーションがアクセスするためのロールを作成
Vault write auth/kubernetes/role/my-app-role \
bound_service_account_names=my-app-service-account \
bound_service_account_namespaces=production \
policies=my-app-policy \
ttl=1h2. K8sデプロイメントマニフェスト（Vault Agent Injectorの活用）
アプリケーションのDeployment定義に、Vault Agentにシークレットの取得を指示するアノテーション（Annotaions）を付与する。ここが実務上の肝となる。
apiVersion: apps/v1
kind: Deployment
metadata:
name: secured-api-server
namespace: production
labels:
app: secured-api-server
spec:
replicas: 3
selector:
matchLabels:
app: secured-api-server
template:
metadata:
labels:
app: secured-api-server
annotations:
# Vault Agent Injectorを有効化
vault.hashicorp.com/agent-inject: "true"
# Vault側で設定したロールを指定
vault.hashicorp.com/role: "my-app-role"
# 取得するシークレットのパスを指定（例: secret/data/production/db）
vault.hashicorp.com/agent-inject-secret-db-config.txt: "secret/data/production/db"
# テンプレートを用いて、アプリケーションが読み込める形式（JSONやEnv形式）でファイルに出力
vault.hashicorp.com/agent-inject-template-db-config.txt: |
{{- with secret "secret/data/production/db" -}}
export DB_USER="{{ .Data.data.username }}"
export DB_PASSWORD="{{ .Data.data.password }}"
{{- end -}}
spec:
serviceAccountName: my-app-service-account
containers:
- name: api-server
image: my-registry.internal/secured-api:v1.2.0
# 環境変数には機密情報を一切持たせず、ファイルから読み込むか、
# アプリケーション側で /vault/secrets/db-config.txt をパースする設計にする
volumeMounts:
- name: secret-volume
mountPath: /vault/secrets
readOnly: true
volumes:
- name: secret-volume
emptyDir:
medium: Memory # ディスクに書き込まず、揮発性のメモリ（tmpfs）上にシークレットを保持この設定の防衛上の優位性
1. メモリ上（tmpfs）のバッファリング: emptyDir の medium: Memory を指定することで、シークレットファイルが物理ディスクやホストのストレージに残らず、ノードのRAM上にのみ存在するように強制する。
2. 環境変数の完全排除: アプリケーションはディスク（メモリ上のファイル）から設定を読み込むため、/proc/[PID]/environ を狙ったプロセスインスペクション攻撃を無効化できる。
3. ライフサイクルの分離: サイドカーとして動くVault Agentがバックグラウンドでシークレットのローテーションとファイル更新を自動で行うため、アプリケーションを再起動することなく最新の鍵を維持できる。
—
第4章：次世代を見据えたセキュリティアーキテクチャ – 耐量子暗号（PQC）と監査の眼
シークレット管理の議論は、現在の暗号アルゴリズムの寿命についても触れておかなかったらセキュリティアーキテクト失格だ。
現在、VaultとK8s間、あるいはアプリケーションとデータベース間の通信（TLS）の多くは、RSAやECDSAといった公開鍵暗号、およびAESなどの共通鍵暗号に依存している。しかし、近い将来、実用的な量子コンピューターが実用化された場合（いわゆる「Qデイ」）、Shorのアルゴリズムによって現在のRSAやECCは瞬時に破られる。
今、あなたが安全に管理しているシークレットも、「Store Now, Decrypt Later（今盗んで、後で復号する）」という国家 nivel のスパイ手法によって、ダークウェブや組織のサーバーの片隅に蓄積されている可能性を忘れてはならない。
クラウドネイティブにおける次世代防衛要件
1. ハイブリッド暗号スイートへの移行: 通信およびVault内部のストレージ暗号化において、NISTが標準化した耐量子暗号（PQC: Post-Quantum Cryptography）アルゴリズム（CRYSTALS-KyberやCRYSTALS-Dilithiumなど）をサポートする暗号ライブラリへの移行計画を今すぐ策定すること。
2. 厳格な監査ログのリアルタイム監視: Vaultの監査デバイス（Audit Devices）機能を有効化し、すべてのシークレットアクセス試行（成功・失敗問わず）をFluentdやDatadogなどのSIEMに転送し、異常なアクセスパターン（深夜の大量取得、未知のIP/ServiceAccountからのアクセス）をMLベースで検知する体制を作る。
—
結び：シークレット管理は「設計」ではなく「思想」である
シークレット管理の本質は、高価なツールを導入することではない。「人間とプロセスを信用しない」というゼロ・トラストの思想を、インフラの隅々にまでコードとして定着させることにある。
「とりあえず環境変数に入れておいて、あとで直そう」
その「あとで」は、セキュリティの世界では永遠に来ない。そして、その油断が次の致命的なインシデントを生む。
K8s Secretsの利便性に甘えるのをやめ、Vaultをはじめとした動的シークレット基盤への移行を断行せよ。それが、プロフェッショナルなエンジニアリングチームが備えるべき、最低限の防衛ラインなのだ。
コメント