すべての Kubernetes クラスターには,組み込みの「Secret」オブジェクトが付属しています。セキュリティっぽいですね。セキュリティのような気がします。それはセキュリティではありません。
Kubernetes Secret は,デフォルトでは etcd に格納されている単なる Base64 エンコード文字列であり,クラスターにアクセスできる誰でも読み取ることができ,次のワンライナーで簡単にデコードできます。 Base64 -d`。保存時の暗号化を明示的に有効にしていない限り (ほとんどのチームは有効にしていません),データベース パスワード,API トークン,TLS 秘密キーは暗号化されずにクラスターのコントロール プレーン データストアに保存されます。 「シークレット」を含む Kubernetes マニフェストを Git にコミットすると,その資格情報はリポジトリの履歴に永久に残ります。
これは,新世代の機密管理ツールが解決するために登場した問題であり,2026 年にはエコシステムが大幅に成熟しています。このガイドでは,Kubernetes 環境でシークレットを管理するための 6 つの最も重要なツールについて説明します。ツールが何を行うのか,何を行わないのか,チームの成熟度レベルにどれが適しているのかを説明します。
関連資料: CI/CD パイプラインを介した機密漏洩が心配な場合は,ベスト CI/CD パイプライン ツールのまとめ を参照してください。コンテナーのセキュリティの全体像については,脆弱性スキャン ツール ガイド をご覧ください。
Kubernetes のデフォルトのシークレットでは不十分な理由
ツールの説明に入る前に,Kubernetes Secret に何が欠けているのかを正確に把握しておく価値があります。ギャップを理解することで,適切なソリューションを選択できるからです。
デフォルトでは保存時の暗号化はありません。 etcd は Kubernetes Secret を暗号化せずに Base64 として保存します。 保存時の暗号化 の有効化はクラスターレベルの構成手順であり,マネージド Kubernetes プロバイダー (EKS,GKE,AKE) の処理方法が異なり,多くの自己管理クラスターでは完全にスキップされます。
シークレットのローテーションはありません。 Kubernetes Secret には,バッキング資格情報が変更されたことを認識するための組み込みメカニズムはありません。データベース パスワードを外部でローテーションすると,シークレットを手動で更新して影響を受けるポッドを再起動するまで,ポッドは古いパスワードを使用し続けます。
シークレット アクセスの監査ログはありません。 標準 Kubernetes 監査ログにはシークレット オブジェクトの変更が記録されますが,ほとんどの構成では個々の読み取りはログに記録されません。つまり,「どのサービスがいつこのトークンにアクセスしたか?」には答えることができません。
設計上,Git に敵対的です。 標準的なアドバイスは,「決して Secret を Git にコミットしない」です。しかし,すべてをコードとして表示することが目標である GitOps の世界では,これは維持するのが難しい例外です。
鈍器としての RBAC。 Kubernetes RBAC を使用すると,名前空間レベルで Secret オブジェクトへのアクセスを許可または拒否できます。 「サービス A はシークレット X を読み取ることができますが,シークレット Y は読み取ることができません」または「このシークレットは 24 時間で期限切れになります」を表現することはできません。
これらはいずれも Kubernetes を放棄する理由ではありません。Kubernetes 上で専用のシークレット管理ツールを使用する理由にはなりません。
TL;DR — 機能の比較
| 道具 | 保存時の暗号化 | 動的な秘密 | 監査ログ | K8s ネイティブ | マルチクラウド | 価格設定 |
|---|---|---|---|---|---|---|
| HashiCorp 保管庫 | ✅ | ✅ | ✅ | ⚠️ (エージェント経由) | ✅ | OSS 無料 / HCP 有料 |
| 外部シークレット オペレーター | ✅ (バックエンド経由) | ✅ (バックエンド経由) | ✅ (バックエンド経由) | ✅ | ✅ | 無料/OSS |
| 封印された秘密 | ✅ | ❌ | ❌ | ✅ | ❌ | 無料/OSS |
| AWS Secrets Manager | ✅ | ✅ | ✅ | ⚠️ (ESO/CSI経由) | ❌ (AWS のみ) | シークレットごとの価格設定 |
| ドップラー | ✅ | ❌ | ✅ | ✅ (オペレーター) | ✅ | 無料→有料レベル |
| 非現実的 | ✅ | ✅ | ✅ | ✅ (オペレーター) | ✅ | OSS・クラウド有償 |
⚠️ = 追加のコンポーネントが必要です
1. HashiCorp Vault — 企業秘密のゴールドスタンダード
HashiCorp Vault は,他のすべての機密管理ツールが測定されるベンチマークです。エンタープライズ環境で 10 年近くにわたって実戦テストされており,その機能セットはその奥深さを反映しています。
Vault の中核機能は 動的シークレット です。これは,オンデマンドで生成され,自動的に期限切れになる資格情報です。静的な PostgreSQL パスワードを保存する代わりに,Vault は,要求しているサービスごとに,構成可能なリース期間 (1 時間など) 有効な一意のユーザー名とパスワードのペアを生成します。リースの有効期限が切れると,資格情報は取り消されます。これにより,クラス全体の資格情報の無秩序な拡散が排除され,侵害の封じ込めが劇的に容易になります。
Kubernetes の場合,Vault Agent Injector または Vault Secrets Operator が統合パスです。インジェクターは,Vault エージェントをポッドに自動的にサイドカーする変更 Webhook として実行され,ポッドの Kubernetes サービス アカウントを使用して Vault に対して認証を行い,共有メモリ内ボリュームにシークレットを書き込みます。新しいアプローチである Vault Secrets Operator (VSO) は,Vault シークレットをネイティブの Kubernetes Secret オブジェクトに同期します。これはオペレーターにとってより馴染みのあるものですが,etcd に一時的に存在するシークレットが犠牲になります。
Vault の秘密エンジンは,広範囲をカバーしています。
- データベース認証情報 (PostgreSQL,MySQL,MongoDB など)
- AWS,GCP,Azureの動的認証情報
- PKI および TLS 証明書の生成
- SSH証明書の署名
- Kubernetes サービス アカウント トークン
Vault の優れた点: 動的な認証情報,きめ細かいアクセス ポリシー,包括的な監査ログ,成熟したプラグイン エコシステム。誰がいつアクセスしたかを完全に記録したコンプライアンス グレードのシークレット管理が必要な場合,多くの場合,Vault が唯一の合理的な選択肢となります。
注意すべき点: Vault の運用は複雑です。高可用性モードで実行するには,ストレージ バックエンド (現在は Raft が推奨されています),封印解除手順,およびアップグレード パスに細心の注意を払う必要があります。学習曲線は本物です。プラットフォームのエンジニアリング時間の予算。
価格: オープンソース バージョンは無料で,ほとんどのニーズをカバーします。 HashiCorp Cloud Platform (HCP) Vault は,クラスター時間とシークレット オペレーションに基づいて価格設定されるマネージド オファリングです。 2023 年の BSL ライセンス変更 により,Terraform 用の OpenTofu フォークが導入されましたが,Vault のフォークに相当するもの (OpenBao) はまだ成熟しています。
📚 推奨書籍: Hacking Kubernetes Andrew Martin および Michael Hausenblas 著 — 秘密の漏洩シナリオを含む Kubernetes の攻撃対象領域について優れた内容をカバーしています。
2. 外部シークレット オペレーター (ESO) — K8s ネイティブ統合レイヤー
外部シークレット オペレーター は,根本的に異なるアーキテクチャ上のスタンスを採用しています。シークレット ストア自体ではなく,Kubernetes と既存の外部ストアとの間のブリッジです。 ESO は,AWS Secrets Manager,GCP Secret Manager,Azure Key Vault,HashiCorp Vault,1Password,Doppler,および増え続けるその他のバックエンドのリストからのシークレットをネイティブ Kubernetes Secret オブジェクトに同期します。
中心的な抽象化は ExternalSecret カスタム リソースです。
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: database-credentials
spec:
refreshInterval: 1h
secretStoreRef:
name: aws-secrets-manager
kind: ClusterSecretStore
target:
name: db-creds
data:
- secretKey: password
remoteRef:
key: production/db/password
ESO はこのリソースを監視し,AWS Secrets Manager (または任意の場所) からシークレットを取得し,標準の Kubernetes シークレットを作成します。アプリケーションは他の Kubernetes Secret と同じように「db-creds」を読み取ります。コードを変更する必要はありません。 「refreshInterval」がオンになると,ESO はシークレットを自動的に再取得して更新します。
ESO が 2026 年に非常に人気がある理由: ESO は既存の投資とうまく機能します。組織にはすでに AWS Secrets Manager (または Vault,または GCP Secret Manager) があります。ESO は,アプリケーション コードや既存のシークレット ローテーション ワークフローを変更することなく,それらのシークレットを Kubernetes で使用できるようにするだけです。
ESO または Vault Secrets Operator? Vault を実行している場合,VSO は Vault 固有のより緊密な統合 (Vault 動的シークレット,Vault PKI) を備えています。クラウド プロバイダーのネイティブ シークレット ストアを使用している場合は,ESO がよりクリーンな選択肢です。多くのチームは,クラウドに保存された静的シークレットの ESO と,Vault 管理の動的認証情報の VSO の両方を実行しています。
価格: ESO は無料のオープンソース (Apache 2.0) であり,強力なコミュニティの支援を受けた CNCF サンドボックス プロジェクトによって維持されています。
3. 封印されたシークレット — GitOps に適した暗号化されたシークレット
Bitnami の Sealed Secrets は,実際の平文を保存せずに,Kubernetes Secret マニフェストを Git に保存するにはどうすればよいかという特定の問題を解決します。答えは非対称暗号化です。
Sealed Secrets コントローラーはクラスター内で実行され,秘密キーを保持します。 「kubeseal」 CLI は,クラスターの公開キーを使用して Kubernetes Secret マニフェストを暗号化し,「SealedSecret」 CRD を生成します。この暗号化されたマニフェストは Git に安全にコミットできます。クラスターの秘密キーのみがマニフェストを復号化でき,その特定のクラスター内でのみ復号化できます (デフォルトでは,暗号文は名前空間 + 名前にバインドされています)。
# Encrypt a secret for Git storage
kubectl create secret generic db-creds \
--from-literal=password=s3cr3t \
--dry-run=client -o yaml | \
kubeseal --format=yaml > db-creds-sealed.yaml
# This file is safe to commit
git add db-creds-sealed.yaml
SealedSecret をクラスターに適用すると,コントローラーはそれを復号化し,対応する Secret オブジェクトを作成します。
Sealed Secrets が得意とすること: GitOps ワークフロー。 Argo CD または Flux を使用していて,すべてのクラスター リソース (シークレットを含む) を Git に宣言的に保存したい場合,Sealed Secrets はそのモデルに完全に適合します。クラスター内コントローラーを超える外部依存関係は必要ありません。
実行できないこと: 標準の Kubernetes イベントを超えるローテーション,動的認証情報,または監査ログ。 Sealed Secrets は Git ストレージ ソリューションであり,完全なシークレット管理プラットフォームではありません。パスワードが変更された場合は,再暗号化して再度コミットします。
秘密キーのバックアップは重要です。 コントローラーの秘密キーを紛失すると,封印された秘密を復号化できなくなります。 「sealed-secrets-key」シークレットを別の安全な場所にバックアップします。
価格: 完全に無料でオープンソース (Apache 2.0)。
4. Kubernetes を使用した AWS Secrets Manager
ワークロードが主に EKS 上で実行される (または AWS サービスに頻繁に接続する) 場合は,AWS Secrets Manager と Secrets Store CSI Driver または外部 Secrets Operator の組み合わせが自然に適合します。秘密は AWS の管理され,暗号化され,監査ログに記録されたストアに保存され,必要に応じて Kubernetes に取り込まれます。
Secrets Store CSI Driver (SSCSID) は CNCF が管理するアプローチです。シークレットは CSI ボリュームを介してファイルとしてポッドに直接マウントされ,Kubernetes Secret オブジェクトとして etcd に書き込まれることはありません。これは最もセキュリティの高いパスです。シークレットはポッド メモリに存在しますが,Kubernetes Secret ストアには存在しません。
volumes:
- name: secrets-store
csi:
driver: secrets-store.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: aws-secrets
AWS Secrets Manager のネイティブ機能には,サポートされているサービス (RDS,Redshift,DocumentDB,カスタム ローテーション用の Lambda 経由) の自動ローテーション,クロスアカウント アクセス,コンプライアンス監査証跡のための CloudTrail の緊密な統合が含まれます。
コストに関する考慮事項: AWS Secrets Manager は,月ごとのシークレットごと,および API 呼び出しごとに料金がかかります。多くの小さな秘密を抱えた大規模な艦隊の場合,コストがかさむ可能性があります。シークレット関連の AWS 支出の管理戦略については,クラウドコスト最適化ガイド を参照してください。
最適な用途: AWS エコシステムにすでに投資しており,緊密な IAM 統合とネイティブ RDS 認証情報のローテーションを必要とする EKS ネイティブのチーム。
5. Doppler — 開発者ファーストの SaaS シークレット プラットフォーム
Doppler は,運用の複雑さよりも開発者のエクスペリエンスを優先する SaaS ファーストのアプローチを採用しています。 Doppler の UI (または CLI/API 経由) でシークレットを定義し,環境 (開発,ステージング,運用) ごとにシークレットを整理すると,Doppler Kubernetes オペレーターがシークレットを Kubernetes Secret に自動的に同期します。
オペレーターは Doppler に変更をポーリングし,対応する Kubernetes Secret を更新し,オプションでシークレットが変更されたときにポッドの再起動をトリガーします。セットアップは単一の Helm チャートのインストールです。
helm repo add doppler https://helm.doppler.com
helm install --generate-name doppler/doppler-kubernetes-operator
Doppler が優れている点: Kubernetes と並行したローカル開発と CI/CD の統合。 Doppler CLI は環境ファイルを完全に置き換え (「doppler run – your-command」),ローカル,CI,実稼働環境全体で同じシークレットを提供します。 CI/CD パイプライン の場合,Doppler と GitHub Actions,CircleCI などのネイティブ統合により,シークレットをパイプライン環境変数にコピーする必要がなくなります。
Doppler でカバーされないもの: 動的データベース認証情報。 Doppler は,バージョン履歴と監査ログを備えた静的シークレット ストアです。Vault のようなシークレット生成エンジンではありません。
価格: Doppler は小規模チーム向けに無料枠を提供します。有料プランには,SSO,アクセス要求,コンプライアンス機能が追加されます。現在のレベルについては,Doppler の価格設定ページ を確認してください (価格の変更,予算を立てる前に確認してください)。
6. Infisical — オープンソースの Vault の代替手段
Infisical は,Vault/Doppler の複占に対する最も強力なオープンソースの挑戦者です。 Web UI,CLI,SDK,および Kubernetes オペレーターを提供します。デプロイ可能なセルフホストまたはクラウド サービスとして利用できます。
Infisical は 2024 年に動的シークレットのサポートを追加し,Vault のデータベース シークレット エンジンと同様のデータベース資格情報の生成をターゲットにしました。 Infisical Kubernetes オペレーターは,構成可能な更新間隔で,「InfisicalSecret」 CRD をネイティブ Kubernetes Secret に同期します。
SaaS レベルの UX (Web ダッシュボード,アクセス要求ワークフロー,監査ログ) が必要だが,コンプライアンス要件により外部 SaaS を使用できないチームにとって,Infisical セルフホストは魅力的です。 Vault よりも操作が大幅に簡単で,開発者にとってより使いやすいオンボーディング エクスペリエンスを備えています。
価格: オープンソース コアは無料です。クラウドホスト型バージョンには,無料利用枠と高度な機能の有料プランがあります。セルフホステッド エンタープライズ ライセンスは,コンプライアンスが重視される環境で利用できます。
📚 Kubernetes セキュリティ アーキテクチャについて詳しくは,Amazon の Kubernetes Security and Observability を参照してください。シークレット,RBAC,ネットワーク ポリシー,およびランタイム セキュリティが 1 つのまとまったフレームワークでカバーされています。
実装のヒント
保存時の暗号化から開始します。 追加のツールを追加する前に,保存時の Kubernetes etcd 暗号化を有効にします。管理対象クラスターの場合,これは多くの場合,単一のチェックボックスです。自己管理型クラスターの場合は,公式ガイド に従ってください。これにより,ベースラインのセキュリティ体制が直ちに向上します。
シークレットに最小権限の RBAC を採用します。 どのサービス アカウントがシークレット オブジェクトに対する「get」,「list」,または「watch」権限を持っているかを監査します。多くの Helm チャートのデフォルトのサービス アカウントは過剰にプロビジョニングされています。外部ストアにローテーションする前に,RBAC を締めてください。
シークレットの命名規則を早めに計画してください。 シークレットは急速に増殖します。一貫した階層 ({env}/{service}/{credential-type}) により,すべてのツールにわたって自動化,RBAC ポリシー,ローテーション ワークフローが大幅に簡素化されます。
秘密の回転テストをスキップしないでください。 どのツールを選択する場合でも,必要になる前に回転ドリルを実行してください。アプリケーションがダウンタイムなしで新しい認証情報を取得することを確認します。 Vault または ESO を使用した動的シークレットを使用すると,静的シークレットを手動で更新するよりもこれが大幅に簡単になります。
シークレットの拡散を監視します。 プラットフォームが成長するにつれて,シークレットが蓄積されます。シークレット管理レポートをプラットフォーム エンジニアリング ダッシュボードに統合します。シークレット アクセス パターンを追跡できる可観測性ツールについては,Kubernetes モニタリング ツール ガイド を参照してください。
どのチームにどのツールを?
小規模チーム,クラウドネイティブ (AWS/GCP/Azure): 外部シークレット オペレーターがクラウド プロバイダーのネイティブ シークレット ストアに接続することから始めます。最小限の運用オーバーヘッド,堅牢な監査統合,無料。
GitOps ファースト チーム (Argo CD / Flux): GitOps に保存された構成のシールドされたシークレットと,暗号化されても Git に存在すべきではない機密性の高いランタイム認証情報の ESO との組み合わせ。
コンプライアンス要件がある企業 (SOC 2,PCI,HIPAA): HashiCorp Vault — セルフホスト型 Raft クラスターまたは HCP Vault 管理のいずれか。監査ログ,動的な資格情報,およびきめ細かいポリシー エンジンは,他の場所で複製するのが困難です。
開発者エクスペリエンスに重点を置いた混合環境 (K8s + ローカル + CI/CD): 環境間で統合された DX のための Doppler,またはデータ常駐性が重要な場合は Infisical 自己ホスト型。
マルチクラスター環境を管理する大規模なプラットフォーム チーム: Vault またはクラウドネイティブ ストアによってサポートされる,K8s 側の抽象化レイヤーとしての外部シークレット オペレーター。真実の情報源を 1 つのストアに集中させ,ESO をクラスター全体のユニバーサル アダプターとして使用するのは,2026 年の十分に実証されたパターンです。
関連: AI コーディング ツールによって Kubernetes マニフェストおよび CI/CD パイプラインに導入されるセキュリティ リスクについては,2026 年の vibe コーディング セキュリティ リスク に関するガイドを参照してください。
## よくある質問
Kubernetes シークレットはデフォルトで暗号化されますか?
いいえ。Kubernetes Secret はデフォルトで Base64 でエンコードされ,暗号化ではなくエンコードされます。保存時の暗号化を明示的に有効にしない限り,データは暗号化されずに etcd に保存されます。常にクラスター構成を確認し,実稼働ワークロード用の外部シークレット管理ツールを検討してください。
シールされたシークレットと外部シークレット オペレーターの違いは何ですか?
Sealed Secrets は,安全な Git ストレージのために Secret マニフェストを暗号化します。これは GitOps ソリューションです。外部シークレット オペレーターは,外部ストア (Vault,AWS Secrets Manager など) からライブ シークレットを取得し,そこからネイティブ Kubernetes シークレットを作成します。これらはさまざまな問題を解決するため,一緒に使用されることがよくあります。
動的シークレットとは何ですか?なぜ重要ですか?
動的シークレットは,無期限に保存される静的なパスワードではなく,自動有効期限付きでオンデマンドで生成される認証情報です。 HashiCorp Vault は,Kubernetes の動的シークレットの主なソースです。動的資格情報が侵害された場合,その資格情報は独自のスケジュールで期限切れになります。これにより,長期間存続する静的シークレットと比較して,侵害の爆発範囲が大幅に制限されます。
Kubernetes には Doppler または HashiCorp Vault を使用する必要がありますか?
Doppler は,開発者のエクスペリエンスと迅速な導入で勝利を収めています。 Vault は,動的な認証情報,詳細な監査ログ,きめ細かいポリシーなど,エンタープライズ コンプライアンスに優れています。小規模から中規模のチームの場合,多くの場合,ドップラーの方が早い方法です。 SOC 2,PCI DSS,または HIPAA 環境の場合,通常は Vault がより防御可能な選択肢となります。
シークレットがコンテナー ログに漏洩するのを防ぐにはどうすればよいですか?
シークレットを環境変数ではなくファイルとしてマウントします (環境変数は /proc を通じて公開し,エンドポイントをデバッグできます)。 Secrets Store CSI ドライバーを使用して etcd を完全にバイパスします。 Trivy のシークレット スキャナーなどのツールを使用して,CI/CD パイプライン内の誤ったシークレット コミットをスキャンします。セットアップの詳細については,脆弱性スキャン ツール ガイド を参照してください。
小規模な Kubernetes チームにとって最適なシークレット管理ツールは何ですか?
クラウド プロバイダーのネイティブ シークレット ストアによってサポートされる外部シークレット オペレーターから始めます。最小限の運用オーバーヘッド,確実な監査ログ,無料。統合された開発/CI/運用シークレット エクスペリエンスも必要な場合は,Doppler の無料枠を追加してください。
AWS Secrets Manager を Kubernetes と統合するにはどうすればよいですか?
AWS Secrets Manager を指す ClusterSecretStore を持つ外部シークレット オペレーターを使用します。 EKS では,ポッドレベルの IAM 認証に IRSA (サービス アカウントの IAM ロール) を使用します。静的な認証情報は必要ありません。非 EKS クラスターでは,特定のシークレット ARN をスコープとする Secretsmanager:GetSecretValue を持つ IAM ユーザーを使用します。