Dockerイメージのシークレット漏えい：APIキーの確認と初動対応

結論：イメージから消す対応と、認証情報を失効する対応は別

DockerイメージにAPIキーやパスワード、秘密鍵を入れてしまった場合、Dockerfileを直すだけでは、すでに配布した値は無効になりません。イメージの取得者が値を閲覧できた可能性と、その値で接続先を操作できる可能性を分けて確認します。

まず発行元・権限・対象イメージ・配布範囲を記録し、責任者へ報告します。認証情報の失効と対象イメージの配布停止・証跡保全を並行し、安全な作り直しと稼働環境の切り替えへ進めます。公開済み、高権限、不審利用がある場合、詳しい解析を待って失効を遅らせないでください。

本稿は新しい侵害事件やDocker全体の脆弱性を報じるものではなく、ビルド設定・秘密情報の扱いを点検する実務ガイドです。公式資料の確認日は2026年10月10日。操作メニュー、ログ、保持期間は利用するレジストリや契約で異なります。

なぜ漏れるのか：レイヤーとARG・ENV・secret mountの違い

コンテナイメージは、ファイルの追加・変更・削除を記録したレイヤーを重ねる構造です。Dockerのレイヤー解説では、作成済みのレイヤーは不変として扱われます。そのため、秘密ファイルを含めた後、別のレイヤーで削除しただけでは、以前のレイヤーまで消した根拠になりません。実行中のコンテナで見えなくても、安全とは判断できない点が重要です。

DockerのBuild variablesは、ビルド用の秘密情報にARG・ENVを使わないよう案内しています。すべてのARGが必ず残る、という意味ではありません。使い方によって履歴・メタデータ・provenance（ビルドの出所を示す情報）などに残り得るため、秘密値の運搬に頼らない設計にします。

渡し方・保管先	何に注意するか	見直す方向
DockerfileのARG	利用方法によって履歴やprovenanceなどに残り得る	ビルド時だけ必要ならsecret mount等の専用経路へ
DockerfileのENV	イメージの設定として保持され、そこから起動するコンテナへ渡る	固定値を焼き込まず、実行時の承認済みの配布経路へ
設定ファイルをCOPY	最終表示から消しても、レイヤーやキャッシュに含まれる可能性がある	ビルドへ送るファイルとコピー対象を限定する
BuildKitのsecret mount	指定したビルド命令中に一時的に利用できる。ただし処理が値をファイル・ログへ書けば別の露出が起きる	秘密情報の入力経路だけでなく、出力と成果物も点検する
起動時に外部から渡す値	それだけで過去のイメージに焼き込まれるわけではないが、アプリや監視の出力で漏れることがある	ビルド時の値と区別し、実行環境の権限・ログも守る

secret mountの仕様は、秘密情報をビルドへ一時的に渡す仕組みです。「使えばどんな処理でも秘密が残らない」という保証ではありません。認証情報を含む生成ファイル、デバッグ出力、アプリに埋め込まれた値は別に確認します。

読者別の影響：担当を分けて確認する

読者・担当	主な確認対象
個人開発者・初心者	個人のレジストリ、API発行元、課金・利用履歴。まず漏えい元のイメージ削除ではなくキーの失効へ
開発者・CI/CD担当	Dockerfile、ビルドコンテキスト、secretの渡し方、ログ、成果物、キャッシュ
SRE・レジストリ管理者	対象digest、閲覧・取得権限、ミラー、稼働環境、委託先、切り替えとロールバック
情シス・SaaS管理者	漏れた認証情報の所有者、発行元、到達できるデータ・管理機能、停止影響
セキュリティ・業務責任者	不審利用、調査範囲、報告判断、保全、復旧の承認と未確認事項

イメージを取得できる権限と、中の認証情報で操作できる権限は別です。社内限定レジストリでも、本番データを読めるキーが開発・委託先まで配布されていれば、権限境界を越える問題になります。

まず確認すること：混入・配布・権限のチェックリスト

以下は編集部が公式仕様をもとに整理した確認項目です。自社または確認権限のある委託先を対象とし、秘密値を取り出すコマンド、未知のイメージの実行、公開レジストリの探索は行いません。

1. ビルドと認証情報を識別する

• 対象プロジェクト、Dockerfileの版、CI実行ID、ビルド日時・タイムゾーンを記録する。
• ARG・ENV、コピー対象、生成設定ファイル、ログ出力に、秘密情報を入れる経路がないか確認する。
• 変数名、保管庫の識別子、キーID、発行元、所有者を台帳と照合する。秘密値自体を共有しない。
• ビルド時だけ必要な値か、実行時にも使う値かを区別する。

2. 配布先をタグ名だけで追わない

• レジストリのパッケージ名、タグ、image digest（内容に結び付いた識別子）、対象プラットフォームを記録する。
• CIの公開履歴、ミラー、保存済み成果物、開発端末、稼働環境、委託先への提供を確認する。
• レジストリの公開・組織内・個別許可と、取得可能だった利用者・サービス主体を確認する。
• ビルダーの内部キャッシュ、外部キャッシュの保存先と閲覧権限を確認する。

GitHub Container registryの公式資料も、同じイメージを指定する方法としてdigestを説明しています。タグだけが更新されても、以前に取得したコピーの置き換えを確認したことにはなりません。複数プラットフォームのイメージでは、公開された集合と個別の対象を対応付けます。

Dockerのキャッシュ資料には、内部キャッシュに加えてレジストリ等へ保存する外部キャッシュがあります。最終イメージとキャッシュは同じ保存先とは限りません。ただし、secret mountを使っただけでキャッシュに秘密値が残ると断定せず、実際のコピー・出力・保存方式を照合します。

3. 値の有効性・権限・利用記録を確認する

• 発行元の正規管理画面で、有効・失効・期限切れ、スコープ、所有者、依存サービスを確認する。
• 本番・開発・別サービスで同じ値を使っていないか、構成台帳を調べる。
• 発行元のAPI利用・権限変更・データアクセス・課金の記録を確認する。
• ログの有無、保存期間、取得できない項目を記録する。取得ログがないことを「誰も読んでいない証明」にしない。

初動対応：失効・配布停止・保全を並行する

やること

1. 責任者へ報告し、認証情報を止める。 OWASPのシークレット管理指針は、露出した秘密情報の迅速な失効を求めています。公開済み・高権限・不審利用では、詳細調査や再ビルド完了を待たず、発行元で失効・権限制限を判断します。停止影響が大きければ、所有者と責任者が緊急停止または承認済みの短い切り替えを決め、期限と残リスクを残します。
2. 配布を制限し、必要な記録を保全する。 対象イメージの新規公開・配布を止め、取得範囲を制限します。管理画面、公開履歴、対象digest、CIログ、利用記録をアクセス制御された場所へ保全し、削除・保持は担当者の承認で行います。保全のために公開を続ける必要はありません。
3. 影響を確認し、安全な認証へ切り替える。 同じ値の利用先と接続先の記録を確認し、新しい認証情報は最小権限・環境分離で配布します。新しい値を同じDockerfileへ戻したり、疑わしいビルドログへ再出力したりしません。
4. 新しいイメージを検証して展開する。 混入原因を修正し、確認済みの入力・ビルド環境から作り直します。対象キャッシュの再利用可否を確認し、新しいdigestを記録。業務処理・接続・監視を確認し、旧イメージを自動で再展開しないようロールバック設定も見直します。

やってはいけないこと

• タグ削除、非公開化、Dockerfile修正だけで、認証情報の失効も済んだと判断する。
• 出所や権限が未確認のイメージを、普段の端末で実行して確かめる。
• イメージ、ビルドログ、秘密値を、無断で外部解析・生成AI・公開Issueへ送る。
• 証跡と依存先を確認せず、すべてのキャッシュ、イメージ、アカウントを一括削除する。
• 発行した新しいキーを同じ混入経路へ戻す、失効した旧値をロールバック用に復活させる。

鍵の種類が署名鍵・TLS秘密鍵・データの暗号鍵の場合は、APIキーと同じ手順で済むとは限りません。信頼先、証明書、署名済み成果物、復号に関わるデータを鍵管理担当者へ引き継ぎます。証拠保全の初動も参照してください。

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

確認した状況	判断と引き継ぎ
有効な本番キー・高権限・顧客データへのアクセス、または不審利用がある	CSIRT・発行元・業務責任者へ直ちに連絡。失効・権限制限と影響調査を並行
公開配布、委託先への提供、取得者・公開期間・権限が不明	解析待ちで低優先度にしない。漏えい疑いとして担当を決め、配布と認証情報を保護
非公開のビルダー内に限定できるが、有効な値が混入	ビルダー・キャッシュ・ログの閲覧者と発行元を確認し、失効・切り替えを計画
失効済み、または接続先で権限を持たない試験値と確認できた	確認根拠を記録。同じ混入経路に別の有効な秘密情報がないか確認

これは編集部の実務判断の整理であり、サービス共通の期限・法的な報告義務を定める表ではありません。個人情報・顧客データや契約上の影響が疑われる場合、法務・個人情報保護担当を含めて報告要否を判断します。NIST SP 800-61 Rev. 3を参考に、検知・対応・復旧の担当を結び付けて進めます。

復旧と完了判断：新しいイメージに替えたら終わりではない

• 発行元で旧値の失効を確認し、必要な関連権限・セッションの対応も確認した。
• Dockerfile、ビルド入力、ログ、成果物の混入原因を修正し、新しい値を同じ経路へ戻していない。
• 新しいdigestと稼働環境を対応付け、業務処理・接続・監視を担当者が確認した。
• レジストリ、ミラー、キャッシュ、端末、委託先の対応済み・未確認を分けて記録した。
• 接続先の利用記録と確認期間を残し、ログ欠損や調査できない範囲を隠していない。
• 再展開・ロールバックの設定を見直し、残作業の所有者・期限・受け入れ判断を記録した。

第三者が取得したすべてのコピーを、こちらから確実に消せるとは限りません。コピーの完全回収を待つのではなく、認証情報を使えなくする対応と、配布・稼働環境の是正を分けて完了判定します。ログだけで未利用を証明できない場合も、その制約を引き継いでください。

記録テンプレート

チケットへ転記する項目の例です。秘密値や機密性の高い内部構成は書かず、保全先は組織内の承認された参照方法で示します。

項目	記録する内容
事案・発見	事案ID、発見日時・タイムゾーン、担当・報告先
対象ビルド	プロジェクト、Dockerfileの版、CI実行ID、対象digest・プラットフォーム
認証情報	種類、識別子、発行元、所有者、有効状態・権限。値そのものは記載しない
配布	レジストリ・ミラー・キャッシュ・稼働環境・委託先、閲覧範囲、推定期間
保全・制限	記録の取得元・時刻・担当・保全先、配布制限の承認と結果
失効・復旧	旧値の失効時刻、新しいdigest、切り替え先、業務確認・承認者
影響	確認したログと期間、不審利用、停止影響、調査の制約
残作業	未確認先、担当、期限、次回確認、クローズの判断根拠

よくある誤解：予防策にも守備範囲がある

.dockerignoreを追加すれば過去のイメージも安全？

いいえ。ビルドコンテキストの公式資料では、.dockerignoreはビルダーへ送るファイルの除外に使います。過去の配布物や履歴、別経路で渡すARG・ENVまで直す機能ではありません。使われるコンテキストと除外ファイルを確認し、不要な秘密ファイルを送らない運用にします。

マルチステージビルドなら秘密は絶対に残らない？

いいえ。マルチステージビルドは、必要な成果物だけを最終イメージへ移せる仕組みです。コピーする成果物に秘密が含まれる、途中のステージを配布する、ログや外部キャッシュへ出す場合は別の確認が必要です。

digestで固定すれば漏えいは防げる？

digestは対象の識別・展開確認に役立ちますが、中身が安全である証明ではありません。秘密情報を含むイメージを固定すれば、その同じ問題を使い続けます。ハッシュと暗号化の違いも確認してください。

関連用語・次に読むページ

次にしたいこと	CyberLensのページ
用語を理解する	Secrets Management、Container Registry、Credential Rotation
開発環境全体を点検する	開発ツール・OSSサプライチェーン確認チェックリスト
発行元やGitの漏えいに対応する	GitHub secret leak対応チェックリスト、サービスアカウントキーの初動対応
Kubernetesで配布している	Kubernetes Secrets漏えい時の初動対応
報告と対応を作業化する	漏えい疑い初動テンプレート、インシデント対応の基礎
安全な教材で判断を練習する	GitHub secret leak初動ミニCTF。Dockerから秘密を取り出す演習ではなく、失効・報告の判断を練習する

公式情報・参考情報

以下を2026年10月10日に確認しました。仕様の説明と、本稿の編集部チェックリストは区別しています。利用環境の対応機能・メニュー・契約上のログ取得範囲は、各提供元の現行資料へ照合してください。

• Docker Docs: Build variables — ARG・ENVと残り得る情報。
• Docker Docs: Build secrets — secret mountとビルド時の入力。
• Docker Docs: Understanding the image layers — レイヤーとファイルシステム変更。
• Docker Docs: Build context — .dockerignoreと送信対象。
• Docker Docs: Cache storage backends — 内部・外部キャッシュ。
• Docker Docs: Multi-stage builds — 最終イメージへ移す成果物。
• GitHub Docs: Working with the Container registry — アクセス権とdigestでの指定。
• OWASP: Secrets Management Cheat Sheet — 失効・ローテーション・監査。
• NIST SP 800-61 Rev. 3 — 2025年4月公表のインシデント対応指針。