kanikoでAzureトークンが漏れる条件 v1.25.20への更新とCIの点検

Chainguard版kanikoのv1.25.20より前には、コンテナイメージのビルド中にMicrosoft Entra IDのアクセストークンを第三者のレジストリへ送るおそれがあります。CVE-2026-105769です。外部のプルリクエストなど、自分たちが完全には管理できないDockerfileやビルド引数を扱い、ビルドからAzureのIDを使えるCIが優先対象です。ビルドの実行イメージを修正版で作り直し、更新までの間は信頼できない入力を扱うビルドからAzureのIDを切り離してください。Azure Container Registry（ACR）を普段使っていないという理由だけでは除外できません。

Chainguardのkanikoセキュリティ告知は2026年11月2日付で、深刻度をCritical、CVSS 3.1の基本値を9.3としています。kaniko v1.25.20の公式リリースは告知に先立って公開されました。この告知が示すのはトークンが送信される条件と対応であり、特定の利用組織で不正利用が確認されたという発表ではありません。以下の確認手順は公式情報に基づく運用例です。

ビルドの実行前にベースイメージの参照先で発生する

問題は、ACRへの認証に使うヘルパーが、ホスト名の一部にAzureのレジストリ用ドメインが見つかるだけで、正規のACRと判定していたことです。見た目の似た文字列を含む第三者のホストでも判定を通過できます。そのホストへ認証情報を送るため、ヘルパーはAzure Resource Manager（ARM）用のアクセストークンを取り出し、交換用のリクエストに添付します。第三者がそのホストを管理していれば、まだ有効なトークンを受け取れます。

この判定は、Dockerfileに書かれた命令を実行した後に起きるものではありません。外部イメージを参照するFROMやCOPYの処理が引き金になり、RUNがないDockerfileや、成果物をレジストリへpushしない検査ジョブも対象になり得ます。ヘルパーはレジストリに接続する前に資格情報を解決するので、相手が認証を要求する必要もありません。ベースイメージの取得までしか許していないビルドであっても、参照先を誰が決められるかを確認する必要があります。

kanikoに組み込まれたヘルパーは、Dockerの設定に対象レジストリの認証情報がなく、GoogleのレジストリやAmazon ECRにも該当しない場合などに参照されます。したがって、利用者が明示的にACR用ヘルパーを設定していなくても経路が残ります。Docker設定でcredsStoreをacr-envにしている場合は、すべてのレジストリに対して独立した実行ファイルが参照される別経路もあります。Docker設定を点検するときは、組み込みと独立実行のどちらが動くかを分けてください。

AzureのIDをビルドが取得できるかを確認する

影響判定では、まずビルド定義の版と、入力を変更できる主体を確認します。外部の開発者がDockerfileを編集できる場合だけでなく、ビルド引数でFROMの参照先を差し替えられる場合も対象です。たとえば社内で固定したDockerfileを使っていても、そこに渡すベースイメージ名を外部の変更から受け取る構成では、ファイルの管理者だけを調べても判断できません。ジョブが実際に解決するイメージ参照をたどります。

次に、ビルド環境から利用できるAzureのIDを調べます。Chainguardが挙げているのは、環境変数で渡すサービスプリンシパルの資格情報、AKSのWorkload Identityなどから渡るフェデレーション用トークン、Azure VMやAKSノードのメタデータサービスなどを経由するマネージドIDです。環境変数にクライアントシークレットが見当たらない場合でも、マウントされたトークンやメタデータへの到達経路があれば、認証を取得できることがあります。

読者が確認する単位は、クラスタ全体よりも個々の実行経路です。同じCIでも、外部PR用のジョブ、マージ後の公開ジョブ、キャッシュを準備するジョブで、Podのサービスアカウント、マウント、ネットワーク、実行するイメージは異なります。外部PRが公開ジョブを直接起動できなくても、外部入力を処理する検査ジョブにAzureのIDが渡っていれば、トークン漏えいを防げません。ビルドの用途ごとに、入力の出どころと利用できるIDを一緒に記録します。

漏えいするのはARM用トークンです。利用できる操作は、そのトークンに対応するIDへ割り当てた権限に依存します。たとえば実際のACRに対してAcrPush相当の権限があれば、第三者が有効期間内のトークンを使ってレジストリの資格情報を取得し、イメージをpushする可能性があります。他方、すべての利用者のレジストリが変更可能になるという意味ではありません。影響範囲はリソースの割り当てと、対象期間にそのIDが実際に持っていた権限を基に判断します。

更新ではソース版と配備する実行イメージを照合する

kanikoの認証ヘルパー修正PRにより修正版には認証ヘルパーが同梱され、ホストと任意のポートとして解釈できる値のうち、正規のACR用ドメインやmcr.microsoft.comだけが対象になります。対象外のホストではトークンを取得せず、認証情報がないものとして扱います。元のヘルパーはメンテナンスされておらず、告知時点で修正版リリースはありません。旧ヘルパーの依存バージョンだけを上げることを、kanikoの修正の代わりにはできません。

Chainguardの告知によると、リポジトリ自体は実行バイナリやコンテナイメージを公開していません。ソースから配備する組織は、v1.25.20以降からexecutor、キャッシュを温めるwarmer、独立したdocker-credential-acr-envのうち実際に利用するものを作り直します。Goモジュールとして組み込んでいる場合は、github.com/chainguard-dev/kanikoをv1.25.20以降へ更新し、組み込み先を再ビルドします。別の配布元から入手する場合は、配布元がどのソース版または修正を含めたかを確認します。

CIの変更レビューでは、新しいイメージが作られたことだけでなく、外部PR用のテンプレート、マージ後のテンプレート、キャッシュ用ジョブのどれがそのイメージを参照するかを確認します。タグが同じまま置き換わる環境では、起動したジョブのイメージダイジェストを、修正を含むビルド記録と照合します。runnerのローカルキャッシュや予備テンプレートが古いイメージを指していれば、検証環境だけ新しくなっていても修正を適用できたとは言えません。

更新後の動作確認は、通常のビルドで必要な正規レジストリから取得できることと、正規ではない参照に対してAzureの認証を試みないことを分けます。後者を検証する場合は、本番のIDを付けず、管理下の検証環境で無害な認証スタブや通信の記録を使います。非正規のホストからイメージを取得できなかったという結果だけでは、認証用の通信がなかった証拠になりません。正規のpullが失敗する場合は、配備したイメージ、Docker設定、IDの割り当てを個別に見直し、認証の宛先制限を緩めて切り抜けないようにします。

更新を待つ間は信頼できないビルドからIDを外す

Chainguardは、Azureの資格情報やフェデレーショントークン、MSI_ENDPOINTなどをビルド環境から除き、ビルドPodからインスタンスのメタデータサービスへアクセスできないようにする方法を挙げています。環境変数の削除だけを行った場合は、実行環境が別の方法でトークンを取得できないかも確認します。外部入力のビルドと社内の公開ビルドを分けられるなら、前者にAzureのIDが付かない状態を優先します。クラスタ内の別の用途まで一律に遮断する必要があるかは、実行環境の共有状況で判断します。

組み込みのACR認証を使っていない場合には、kanikoコンテナでAZURE_ENVIRONMENTをnoneなど存在しないクラウド名にする回避策も案内されています。トークン取得前に処理が止まる代わりに、そのヘルパーでは正規ACRにも認証できなくなります。独立した実行ファイルに対しては、全体のcredsStoreを使う代わりに自社のホストだけへcredHelpersを設定する方法があります。この設定変更だけでは、組み込みヘルパーの経路まで閉じられません。どの暫定措置を使ったかと、残る認証経路を記録し、修正版の導入を続けます。

過去のジョブはトークンの有効期間と権限で調べる

旧版を使い、AzureのIDが取得できる状態で信頼できないDockerfileをビルドした場合、Chainguardはその間に発行されたトークンを漏えいしたものとして扱うよう案内しています。IDの元の資格情報を交換しても、既に発行されて第三者へ渡ったアクセストークンは有効期限まで残り得ます。交換だけで対応を終えず、疑わしいジョブの時間と使われたIDを絞り、Entra IDのサインインログとAzureのアクティビティログを照合します。

照合では、ACRへの予期しないpush、ロール割り当ての変更、ストレージアカウントのキーやシークレットの取得など、IDの権限で実行可能だった操作を優先します。不審な操作が見つかった場合は、当該IDで取得できた秘密情報の交換に加え、不明なイメージが配備に使われていないかも確認します。調査に使う時刻、イメージのダイジェスト、ビルドIDを残し、アクセストークンそのものはチケットに貼りません。

この対応を完了とする目安は、修正済みのビルダーが各ジョブで動くこと、外部入力から不要なAzureのIDを利用できないこと、旧版の利用期間について調査範囲が決まっていることです。ビルダーを更新したことと、過去のトークンや成果物の調査を終えたことを別々に記録すれば、担当者が変わっても次の作業を判断できます。