Kubernetesの kubectl get secret -o yaml を実行して、値がBase64の文字列で表示されるのを見て「暗号化されているから安全だ」と思ったことはないでしょうか。実はこれは大きな誤解です。KubernetesのSecrets管理は、デフォルト設定のままではBase64エンコードが施されているだけで、暗号化は一切行われていません。etcdにアクセスできる人、あるいはRBACの権限設計が甘いクラスタでは、誰でも一瞬でデコードして平文の認証情報を取り出せてしまいます。
本記事では、この「Base64=暗号化」という思い込みがなぜ生まれるのか、RBACの権限スコープ設計がどのように事故を招くのか、そしてK3s本番運用でSecrets管理を安全にするための具体的な対策を解説します。
1. 「暗号化されている」という思い込みの正体 — Base64とetcdの実態
KubernetesのSecretリソースをマニフェストとして出力すると、data フィールドの値はBase64文字列になっています。この見た目のせいで「難読化されている」「暗号化済みだ」と誤解するエンジニアは少なくありません。しかし、Base64はエンコード方式であり、暗号化ではありません。デコードには鍵も何も必要なく、echo <値> | base64 -d の一行で即座に元の平文に戻せます。
Kubernetes公式ドキュメントも、デフォルト設定ではSecretやConfigMapなどの機密データがetcdに暗号化されずに保存されることを明記しています。Kubernetes APIサーバーに --encryption-provider-config フラグで暗号化設定を渡さない限り、identity プロバイダー（実質的に暗号化なしの状態）が使われ続けます。つまり、何も設定していないクラスタでは、etcdのバックアップファイルやスナップショットにアクセスできる人間が、そのままSecretsの中身を読めてしまうということです。
この構造は、DevelopersIOの解説記事でも指摘されている通り、「読み込み権限があれば誰でもデコードして平文データを取得できる」という点に集約されます。エンコードと暗号化を混同したまま本番環境を構築してしまうと、監査や第三者機関のセキュリティレビューで初めて問題が発覚するケースも珍しくありません。
K3sでの暗号化オプション
軽量Kubernetesディストリビューションである K3s では、K3s公式ドキュメントにある通り、--secrets-encryption フラグをサーバー起動時に指定するだけでetcdに保存されるSecretsを自動的に暗号化できます。AES-CBCの暗号化キーが自動生成され、暗号化設定ファイルがKube-APIServerに渡される仕組みです。ただし、既存のサーバーに後から有効化する場合は再起動が必要になる点には注意が必要です。
2. RBACの過剰権限が事故を生む — get/list/watchの権限スコープ設計
Secrets管理のもう一つの落とし穴は、RBAC（Role-Based Access Control）の権限スコープです。Kubernetes公式のRBACドキュメントによれば、RBACはRole・ClusterRole・RoleBinding・ClusterRoleBindingという4種類のオブジェクトで構成され、権限は「追加的」にしか付与できません。つまり、一度与えた get・list・watch の権限を後から部分的に取り消す「拒否ルール」は存在しないのです。
この特性を軽視すると、次のような事故パターンが生まれます。
- Service Account経由の権限拡散: PodにアタッチされたService AccountにClusterRoleでSecretsへの
list権限を付与すると、そのPodで動くあらゆるコンテナ・CI/CDジョブがクラスタ全体のSecretsを読み取れてしまう - Namespace境界の形骸化: 「namespaceで分離しているから安全」と考えていても、ClusterRoleBindingで横断的な権限を付与していれば境界は意味を持たない
- ワイルドカードの安易な使用:
resources: ["*"]やverbs: ["*"]の指定は、意図しないリソースへのアクセスを許してしまう
Wizのコンテナセキュリティ解説でも、最小権限原則（Principle of Least Privilege）の徹底、ワイルドカードの使用回避、そして権限の定期的な棚卸しが繰り返し強調されています。RBACは「一度設定したら終わり」ではなく、Service AccountやCI/CDパイプラインが増えるたびに見直しが必要な、継続的な運用対象です。
3. 実践対策 — etcd暗号化、External Secrets Operator、CSI Secrets Store
Secrets管理を安全にする対策は、導入コストと効果のバランスに応じて大きく3段階に整理できます。
対策1: etcd暗号化 at rest（最小コスト）
前述の EncryptionConfiguration を設定し、AES-GCMやKMSプロバイダーを利用してetcdへの保存時暗号化を有効にする方法です。既存のクラスタ構成を大きく変えずに導入でき、まず着手すべき最低ラインの対策といえます。
対策2: External Secrets Operator によるVault/クラウド連携
External Secrets Operator（ESO）は、HashiCorp Vaultや各クラウドのSecrets Managerといった外部システムから認証情報を取得し、Kubernetes Secretとして自動同期するツールです。SecretStore がアクセス方法を、ExternalSecret が取得対象を定義するという役割分担により、「どこから」と「何を」の関心を分離できます。HashiCorp Vaultの公式チュートリアルにもある通り、Vault側でアクセスポリシーと監査ログを一元管理できるため、ローテーションや失効の運用負荷を大きく下げられます。
対策3: CSI Secrets Store Driver(Secret Objectそのものを作らない)
より高いセキュリティ要件がある環境では、Secrets Store CSI Driverの採用が選択肢になります。これは SecretProviderClass というCustom Resourceを使い、Kubernetes Secretオブジェクトそのものを作成せずに、外部シークレットストアの値を直接Podのファイルシステムにボリュームとしてマウントする仕組みです。Secret Objectがetcdに一切存在しないため、前述のBase64問題自体が発生しません。
| 対策 | 導入コスト | 効果 | 向いているケース |
|---|---|---|---|
| etcd暗号化 at rest | 低 | 中 | まず着手すべき最低ライン |
| External Secrets Operator | 中 | 高 | Vault等を既に運用している組織 |
| CSI Secrets Store Driver | 中〜高 | 最高 | 私鍵・規制対象の認証情報を扱う環境 |
4. K3s / マネージド運用でのSecrets・RBACチェックリスト
本番投入前に、以下の4項目を最低限確認しておくことをおすすめします。
- 暗号化設定: EncryptionConfiguration（またはK3sの
--secrets-encryption）が有効になっているか - 監査ログ: Secretsへの
get/listアクセスが監査ログに記録され、追跡可能になっているか - ローテーション: 暗号化キーおよびSecretsそのものの定期ローテーションが仕組み化されているか
- 権限棚卸し: Service Account・RoleBinding・ClusterRoleBindingが最小権限になっているか、定期的に見直されているか
これらを自前でゼロから構築・運用しようとすると、クラスタ構築の初期コストだけでなく、継続的な監視・棚卸しの運用負荷がインフラチームにのしかかります。この設定、毎回ゼロから作りますか。KuboのようなマネージドK3s環境であれば、こうしたセキュリティ設定の土台がすでに整った状態から運用を始められます。
KuboのCaptain UIは権限設定やクラスタ構成をブラックボックス化せず可視化するため、RBACの棚卸しが属人化しがちという課題にも対応しやすくなります。EKSやAKSを自前で構築・運用する場合と比較しても、K3sベースの軽量な構成でコスト効率よくセキュリティ運用の土台を整えられる点は大きな違いです。
まとめ
KubernetesのSecretsはBase64エンコードされているだけで、暗号化ではありません。デフォルト設定のままでは、etcdにアクセスできる人間や、RBACの権限設計が甘いクラスタ内の誰もが機密情報を読み取れてしまいます。対策はetcd暗号化・External Secrets Operator・CSI Secrets Store Driverという3段階で、コストと効果のバランスを見ながら段階的に導入できます。
特に金融機関や医療機関など、データ主権やAir-Gapped環境での運用が求められる領域では、Secrets管理とRBAC設計をゼロから自前で構築・監査する負荷は決して小さくありません。そうした本番運用基盤の次の一歩として、Kubo On-Premiseのような、自社インフラ上で完全にコントロールできるマネージドK3s環境を検討する価値があります。まずはお問い合わせから、現状のSecrets・RBAC設計を見直すきっかけにしてみてください。