Kubernetes Secrets漏えい時の初動対応｜確認方法

冒頭要約

Gitリポジトリ、CI/CDログ、チャット、チケット、アプリケーションログ、バックアップなどにKubernetes Secretの値が露出した疑いがある場合、Secretオブジェクトを削除するだけでは対応完了になりません。Secretに保存されていたAPIキー、データベースパスワード、証明書、トークンを、発行元のサービス側で失効させる必要があります。

最初に、対象クラスタ、namespace、Secret名、値の種類、発見時刻、露出場所、参照しているワークロードを記録します。次に上流の認証情報を失効・再発行し、新しい値へ切り替え、Kubernetes監査ログと接続先サービスのログで不審な利用を確認します。

この記事では、情シス、開発者、SRE、クラウド・SaaS管理者、CSIRTが、最初の15分、封じ込め、影響調査、復旧、再発防止へ進む判断基準を解説します。漏えい値の動作確認や侵入再現は行わず、防御・確認・記録に必要な内容だけを扱います。

秘密値をチケットやチャットへ貼り直さない

調査や本人確認のためでも、Secretの値をコピーして共有しないでください。識別にはクラスタ、namespace、Secret名、キー名、発見元の参照情報を使い、秘密値そのものを増やさないようにします。

Kubernetes Secretsとは：base64との違い

Kubernetes Secretsは、パスワード、OAuthトークン、SSH鍵などの機密情報をPodへ渡すためのオブジェクトです。SecretはVolumeや環境変数などを通じてコンテナから参照できますが、値を利用するアプリケーション、ログ、デバッグ出力、バックアップまで自動的に安全にする仕組みではありません。

Kubernetes公式ドキュメントは、Secretマニフェストのbase64表現は暗号化ではなく、平文と同等に機密情報として扱うよう注意しています。リポジトリへ登録されたマニフェスト、CI/CDの出力、Issueへ貼られたYAMLは、文字列が読みにくく見えても漏えいとして扱います。

「Secretが漏れた」を4種類に分ける

状況	例	最初に確認すること
値そのものが露出	マニフェスト、ログ、画面、バックアップに秘密値が含まれた	閲覧範囲、露出期間、上流サービスでの失効可否
Secretを読める権限が露出	kubeconfig、クラスタ管理者ID、サービスアカウントトークンが漏れた	対象主体のRBAC、到達できるnamespace、監査ログ
ワークロード経由で露出	アプリのデバッグ画面やログが環境変数を出力した	対象Pod、ログ転送先、同じ値を使う他環境
etcd・バックアップが露出	control planeやetcdのスナップショットへ第三者がアクセスした	保存時暗号化、復号鍵、バックアップの閲覧者と複製先

「Secretオブジェクトが見つかった」という事実と、「保存されている認証情報が第三者に使われた」という事実は分けて記録します。ただし、利用の証拠がまだ見つからなくても、値が閲覧可能だったなら失効・再発行を優先します。

読者別の影響：誰が何を確認するか

読者・担当	まず確認すること	主な責任範囲
開発者	Secretを参照するDeployment、Job、CI/CD、アプリ設定	新しい値への切り替え、動作確認、ログへの再露出防止
SRE・クラスタ管理者	クラスタ、namespace、RBAC、監査ログ、etcd暗号化	読み取り主体の特定、権限制限、段階的な再起動と復旧
情シス・SaaS管理者	APIキーやパスワードの発行元、所有者、接続先データ	失効・再発行、SaaS監査ログ、顧客・業務影響の確認
クラウド管理者	クラウドIAM、Secret管理サービス、KMS、監査ログ	権限範囲、別リソースへの到達、鍵・トークンの失効
CSIRT・SOC	発見経路、露出期間、不審利用、同時に露出した情報	優先度判断、証拠保全、調査範囲、経営・法務への報告
個人開発者	公開リポジトリ、個人クラスタ、課金、外部API	値の失効、権限・請求確認、公開履歴と複製先の確認

Secretの値が本番と開発環境で共有されている場合、発見したクラスタだけを直しても封じ込めになりません。値を軸に、同じ認証情報を使うリポジトリ、CI/CD、別クラスタ、ローカル環境、SaaS連携を確認します。

まず確認すること：最初の15分チェックリスト

1. 対象を識別する

クラスタ、namespace、Secret名、キー名を記録した。
パスワード、APIキー、トークン、証明書、秘密鍵など値の種類を特定した。
Secretの所有チーム、発行元サービス、利用目的を確認した。
本番、検証、開発のどの環境で使われているか確認した。
発見時刻、発見者、通知元、チケット番号を記録した。

秘密値を復号・表示して照合するのではなく、Secret名、キー名、発行元の識別子、所有者台帳、デプロイ設定を使います。値の種類を特定できない場合は、未確認のまま低優先度にせず、複数の認証情報が含まれる可能性を残します。

2. 露出経路と閲覧範囲を確認する

Publicリポジトリ、社内リポジトリ、ログ、チャット、チケット、バックアップのどこで露出したか確認した。
露出開始時刻と、最後に安全を確認できた時刻を記録した。
閲覧できた利用者、外部共有、フォーク、ミラー、ログ転送先を確認した。
同じファイルやログに別のSecret、内部URL、顧客情報が含まれていないか確認した。
漏えい元の削除前に、URL、コミット、ログIDなど必要な参照情報を保全した。

Git履歴やログ保存先から見えなくしただけでは、すでに取得された値は無効になりません。公開範囲の縮小と認証情報の失効を別の作業として管理します。

3. 依存するワークロードを確認する

SecretをVolumeまたは環境変数で参照するDeployment、StatefulSet、DaemonSet、Jobを確認した。
Ingress、Operator、CI/CD、バックアップ、監視など周辺コンポーネントの参照を確認した。
同じ値を使う別namespace、別クラスタ、別リージョンを確認した。
失効時に停止する業務、復旧目標、メンテナンス責任者を確認した。
新しい値を安全に配布し、切り替えを確認できる担当者を確保した。

環境変数として読み込んだ値は、Secretオブジェクトを更新しただけでは既存プロセスへ反映されません。Volumeでも、アプリケーションが値を再読み込みするかは実装によります。Secret更新、ワークロード切り替え、旧値失効を一つの変更計画として扱います。

4. 読み取り権限とログの有無を確認する

RBACでSecretのget、list、watchを持つ利用者・グループ・サービスアカウントを確認した。
対象namespaceでPodを作成・変更できる主体を確認した。
Kubernetes Audit Logが有効か、保存期間と記録レベルを確認した。
Secretの読み取り、更新、削除と、RBAC変更のイベントを確認した。
発行元サービス側のサインイン、API利用、データアクセス、権限変更ログを確認した。

Kubernetes公式ガイドは、Secretへのlist権限が返却対象の値を取得できること、Secretを直接読めなくても、そのSecretを参照するPodを作れる主体が値へ到達できる場合があることを説明しています。RoleBindingだけでなく、Pod作成・変更権限も確認対象です。

初動対応：やること、やらないこと、記録すること

やること

対象Secretと上流の認証情報を特定し、所有者とインシデント責任者を決める。
発行元サービスで新しい認証情報を作成し、権限と有効範囲を必要最小限にする。
組織で承認された経路を使い、Kubernetes側のSecretと依存ワークロードを新しい値へ切り替える。
新しい値で業務が継続することを確認し、旧値を発行元サービス側で失効する。
旧値が使えないことを正規の管理画面と監査ログで確認する。
Kubernetes監査ログと接続先サービスのログを突き合わせ、不審な読み取りと利用を調査する。
同じ露出経路、同じRBAC、同じ保管先にある他のSecretも確認する。

漏えいがPublicな場所で発生した、強い権限を持つ、すでに不審利用がある場合は、通常の変更手順より封じ込めを優先します。停止影響が大きい場合も、漏えいした値を有効なまま放置せず、サービス所有者とCSIRTが代替経路、段階的切り替え、緊急停止を判断します。

やってはいけないこと

漏えいした値を使い、接続や権限を試さない。
Secretオブジェクトだけを削除し、発行元のAPIキーやパスワードを有効なまま残さない。
依存関係を確認せず、全Podや全クラスタを一斉に再起動しない。
記録を残さず、Secret、ログ、リポジトリ、サービスアカウントを削除しない。
base64表現や非公開リポジトリを、安全性の根拠にしない。
監査ログがないことを「利用されていない証明」にしない。
Secretの値、顧客情報、内部URLを通常のチャット、公開Issue、個人端末へ複製しない。

記録すること

事案ID:
発見日時・発見者:
対象クラスタ / namespace / Secret名 / キー名:
値の種類・発行元・所有者:
露出場所・閲覧範囲・推定期間:
参照ワークロード・他環境:
旧値の失効日時・実施者:
新しい値への切り替え日時・確認者:
確認したログ・対象期間・保存上の制約:
確認された不審操作:
影響を受けるデータ・業務・利用者:
未確認事項・次回確認期限:
エスカレーション先・判断者:

記録テンプレートへ秘密値そのものを貼らないでください。必要な証跡は、アクセス制御された保存先で、収集者、収集時刻、取得元、ハッシュなど組織の証拠保全手順に従って管理します。

ローテーションの判断順：Secret更新と失効の違い

操作	目的	完了条件
新しい認証情報を発行	旧値に依存しない復旧経路を用意する	権限、有効期限、利用先が承認済みである
Kubernetes Secretを更新	ワークロードへ新しい値を配布する	対象環境のSecretが更新され、秘密値をログへ出していない
ワークロードを切り替える	実行中プロセスに新しい値を利用させる	ヘルス、業務処理、監視で新しい値の利用を確認した
旧値を失効する	第三者を含む旧値の利用を止める	発行元で無効となり、旧値による利用が受け付けられない
露出元を修正する	再配布と再検知を防ぐ	履歴、ログ設定、テンプレート、権限の原因を修正した

Secretオブジェクトの削除は、外部サービスが発行した値の失効とは異なります。データベースパスワードならデータベース側、クラウドAPIキーならクラウドIAM、SaaSトークンならSaaS管理画面で旧値を止めます。

値が証明書や暗号鍵の場合は、単純な再発行だけでなく、信頼先、証明書チェーン、署名対象、復号可能なデータ、過去のバックアップへの影響も確認します。判断できない場合は、鍵管理担当者とCSIRTへエスカレーションします。

影響調査：監査ログで確認する観点

Kubernetes監査ログは、クラスタ内で「誰が、いつ、どのリソースへ、どの操作を要求したか」を追うための重要な証跡です。一方、Secretの値が外部APIへ実際に使われたかは、接続先サービスのログも確認しなければ分かりません。

Kubernetes側

Secretへのget、list、watchと通常時からの変化。
Secretの作成、更新、削除、namespace間の複製。
Role、ClusterRole、RoleBinding、ClusterRoleBindingの変更。
対象Secretを参照するPod、Job、Deploymentの作成・変更。
サービスアカウント、トークン、Admission設定、監査設定の変更。
通常と異なる利用者、サービスアカウント、送信元、時刻のAPI操作。

監査方針がMetadataレベルの場合、主体、時刻、リソース、verbなどは記録できますが、リクエスト・レスポンス本文は含みません。Secretの値をログへ残すことが目的ではないため、初動で安易に高い記録レベルへ変更せず、機密性とログ量を考慮して監査方針を設計します。

接続先サービス側

データベース、クラウド、SaaS、外部APIへの通常と異なる接続。
IAM、権限、トークン、回復情報、連携アプリの変更。
データの大量閲覧、エクスポート、削除、共有範囲変更。
新しいリソース、ユーザー、キー、永続的なアクセス経路の作成。
利用量、請求、クォータ、エラー率の急な変化。
ログ保存、監視、通知設定の変更や欠損。

ログの対象期間は、発見時刻だけでなく、露出開始時刻、最後に安全を確認できた時点、保存期間を基準に決めます。ログが無効、保存期間外、閲覧権限不足の場合は、その制約を未確認事項として残します。

判断基準：危険度とエスカレーション条件

優先度	条件	推奨する判断
緊急	クラスタ管理、クラウドIAM、顧客データ、Secret管理基盤へ到達できる	即時失効、CSIRT招集、関連ID・Secret・ログの拡大調査
緊急	不審なAPI利用、データ取得、権限変更、永続化、ログ変更がある	侵害の可能性として封じ込め、証拠保全、経営・法務判断へ接続
高	Publicリポジトリ、公開ログ、外部共有へ露出した	利用の証拠を待たず失効し、フォーク・複製・同時露出を確認
高	露出期間、値の種類、利用先、権限範囲のいずれかが不明	未確認リスクとして失効・再発行し、所有者と依存先を特定する
中	閲覧範囲が限定され、権限が小さく、不審利用が確認されていない	ローテーション、ログ確認、原因修正を完了して判断根拠を残す
低	ダミーまたは失効済みで、実環境へ権限がないことを確認できた	根拠を記録し、誤配置と検知ルールを改善する

次のいずれかに当てはまれば、担当チームだけで閉じずにエスカレーションします。

顧客・従業員情報、決済、医療、契約上の機密へアクセスできる。
クラスタ管理者、クラウド管理者、Secret管理、IAM変更の権限がある。
同じ値を複数環境・複数組織で共有している。
不審な読み取り、データアクセス、権限変更、課金、ログ欠損がある。
露出期間、閲覧者、依存先、失効完了のいずれかを説明できない。
サービス停止と漏えい継続のトレードオフを担当者だけで判断できない。

よくある誤解

「base64なので値は読めない」

base64はバイナリを文字列で表現する符号化であり、暗号化ではありません。Kubernetes公式ガイドも、base64で表現されたSecretマニフェストを共有・コミットしないよう注意しています。

「etcdを暗号化すればSecret漏えいは防げる」

etcd暗号化は、etcdやバックアップへ直接アクセスされた場合の保護に役立ちます。しかし、正規のKubernetes APIでSecretを読める主体、Secretを参照するPod、アプリケーションログからの露出は別の対策が必要です。

「Secretを更新すれば全Podがすぐ新しい値を使う」

反映方法は参照方法とアプリケーション実装で異なります。特に環境変数として読み込んだ値は、実行中プロセスへ自動反映されません。ワークロード所有者が切り替えと動作確認を計画します。

「監査ログに何もないので悪用されていない」

監査が有効だったか、対象操作が記録されるレベルか、保存期間内か、接続先サービスのログも確認したかを分けます。ログがないことと、操作がなかったことは同じではありません。

「外部Secret管理を使えばローテーションは不要」

Secrets Store CSI DriverやExternal Secrets Operatorは、保管と配布を改善できますが、発行元での失効、依存アプリの再読み込み、権限、監査、障害時の復旧は引き続き設計が必要です。

再発防止：Secretの保管・権限・監査を見直す

権限を小さくする

人とワークロードのSecret get、list、watchを必要最小限にする。
namespaceを分け、Secretを必要としないコンテナへマウントしない。
Pod作成・変更権限からSecretへ到達できる経路を含めてレビューする。
共有サービスアカウントやクラスタ管理者権限を減らす。
所有者、利用目的、依存先、更新期限を台帳化する。

長期の秘密値を減らす

可能なら短期トークン、Workload Identity、マネージドIDを使う。
APIキーやパスワードに有効期限、スコープ、送信元制限を設定する。
自動ローテーションと段階的切り替えを平時にテストする。
外部Secret管理を使う場合も、Kubernetesへ同期・マウントされた後の露出を確認する。
Git、CI/CD、ログ、コンテナイメージに秘密値を含めない検査を行う。

保存と監査を強化する

保存時暗号化を構成し、既存Secretにも適用されているか確認する。
KMSを使う場合は、復号権限、鍵ローテーション、障害時の復旧を確認する。
Secret操作は必要なメタデータを監査し、機密値をログ本文へ残さない。
監査ログを改ざんされにくい保存先へ送り、保存期間と時刻同期を確認する。
Sealed Secretsなどを使う場合は、復号鍵の保護と漏えい時の再暗号化計画も用意する。

再発防止の完了条件は「Secretを作り直した」ではありません。次回は露出しにくく、露出しても短時間で失効でき、誰がどの範囲へアクセスできたか説明できる状態を目指します。

次に確認すること	CyberLensのページ
KubernetesのSecret管理を理解する	Kubernetes Secrets、etcd暗号化、RBAC
外部Secret管理を比較する	Secrets Store CSI Driver、External Secrets Operator、Sealed Secrets
漏えい対応を作業化する	GitHub secret leak対応チェックリスト、漏えい疑い初動テンプレート、GitHubトークン漏えい初動テンプレート
似た認証情報漏えいを確認する	サービスアカウントキー漏えい時の初動対応、AWSアクセスキー漏えい時の初動対応
判断の基礎を学ぶ	インシデントレスポンス入門、認証と認可の違い、ハッシュと暗号化の違い
知識を確認する	Kubernetes Secrets関連の5問クイズ

公式情報・参考情報

Kubernetes: Good practices for Kubernetes Secrets - 保存時暗号化、最小権限、短期Secret、監査、base64の注意点をまとめた公式ガイド。
Kubernetes: Secrets - Secretの用途、Podからの参照方法、機密性に関する公式仕様。
Kubernetes: Auditing - Kubernetes API操作の主体、時刻、対象、送信元を確認する監査機能の公式文書。
Kubernetes: Role Based Access Control Good Practices - Secretの読み取りやPod作成権限を含む最小権限の公式ガイド。
Kubernetes: Encrypting Confidential Data at Rest - etcd保存時暗号化、既存データへの適用、鍵管理上の注意を扱う公式文書。
NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations - インシデント対応を組織のリスク管理へ組み込む指針。
OWASP: Secrets Management Cheat Sheet - Secretのライフサイクル、ローテーション、失効、監査、インシデント対応の実務ガイド。

まとめ

Kubernetes Secretsの漏えいを疑ったら、クラスタ、namespace、Secret名、値の種類、発行元、露出場所、依存ワークロードを記録します。新しい認証情報へ安全に切り替えた後、旧値を発行元で失効し、Kubernetes監査ログと接続先サービスのログで影響を確認します。

Secretオブジェクトの削除、base64表現、etcd暗号化のいずれか一つだけでは、漏えい対応は完了しません。RBAC、Pod作成権限、長期認証情報、外部Secret管理、監査、ログへの再露出を見直し、確認できた事実と未確認事項を分けてエスカレーションしてください。

Kubernetes Secrets漏えい時の初動対応：確認・ローテーション・影響調査

冒頭要約