信頼できないトリガーに対する GitHub Actions キャッシュの読み取り専用化
本文の状態
日本語全文を表示中
詳細モードで約3分の本文を読めます。
同じ出来事の情報源
この情報源を基点に整理
GitHub Changelog
GitHub が、リポジトリへの書き込み権限なしでトリガー可能なワークフローイベントに対し、デフォルトブランチのキャッシュトークンを読み取り専用に切り替えた。これにより、外部コードによるキャッシュ汚染を防ぎ、権限昇格リスクを低減する。
Source Article
元記事を日本語で読む
本文に関係しない購読案内、埋め込み通知、サイト内プロモーションは除いています。
GitHub Actions は、リポジトリへの書き込み権限なしにトリガーできるワークフローイベントに対して、デフォルトブランチのキャッシュに対して読み取り専用トークンを発行するようになりました。これにより、キャッシュに対する最小特権の原則が適用され、キャッシュ汚染を介した一般的な権限昇経路が防止されます。
以前は、Actions サービスは pull_request_target、issue_comment、fork-pull-request の workflow_run カスケードなどのトリガーを含むすべてのワークフローイベントに対して読み書き可能なキャッシュトークンを発行していました。外部アクターが影響を与える可能性のある（例えば、スクリプト注入や「pwn リクエスト」を通じて）ワークフローコードがデフォルトブランチのキャッシュに書き込みを行うと、push や schedule といった信頼されたワークフローが後でその汚染されたエントリを復元してしまいます。これにより、これらのより信頼されたワークフロー内で任意のコードを実行したり、本番環境のシークレットを外部へ流出させたりする経路が開かれていました。
この経路を塞ぐため、GitHub は以下の 2 つがともに真である場合に読み取り専用のキャッシュトークンを発行します：
トリガーイベントが信頼できないこと。つまり、リポジトリのコラボレーター以外の誰かがそのイベントをトリガーできる状態であること。
ワークフローの実行コンテキストとキャッシュのスコープが、共有されたデフォルトブランチの SHA に由来すること。
デフォルトブランチのキャッシュに書き込みを行う最も一般的なワークフロートリガーは、完全な読み書きキャッシング権限を維持します。これらのトリガーには、push、schedule、workflow_dispatch、repository_dispatch、delete、registry_package、page_build が含まれます。また、pull_request や release のように非デフォルトブランチのスコープを使用するすべてのトリガーも、読み書きキャッシング権限を保持します。
影響を受ける人々
この変更は、デフォルトブランチの SHA コンテキストからキャッシュへ書き込む限られた数の信頼できないワークフローにおけるキャッシング機能に後退をもたらします。書き込みが制限された場合、actions/cache は実行中に警告をログ出力し、ジョブは保存せずに続行されます。復元操作には影響はありません。
これらのワークフローでキャッシングの恩恵を維持するには、push などのイベントによってトリガーされ、キャッシュへの読み書きアクセス権を持つ別個のワークフローを用意する必要があります。これにより、キャッシュへの読み取り専用アクセス権を持つ後続のワークフローがキャッシュを復元して利用できるようになります。
この変更は、github.com およびデータ居住性を備えた GitHub の両方に適用されます。詳細については GitHub Actions キャッシュドキュメントをご参照ください。また、GitHub コミュニティでの議論にもご参加ください。
「信頼できないトリガーに対する読み取り専用 Actions キャッシュ」という記事は、最初に The GitHub Blog で公開されました。
原文を表示
GitHub Actions now issues read-only cache tokens to the default branch for workflow events that can be triggered without write permissions to the repository. This applies least privilege to the cache and prevents common privilege-escalation paths through cache poisoning.
Previously, the Actions service issued read-write cache tokens for every workflow event, including triggers like pull_request_target, issue_comment, and fork-pull-request workflow_run cascades. Workflow code that an external actor can influence (e.g., through script injection or “pwn requests”) could write to the default-branch cache, and a trusted workflow such as push or schedule would later restore those poisoned entries. This opened up a path to run arbitrary code and exfiltrate production secrets in these more trusted workflows.
To close that path, GitHub now issues a read-only cache token when both of these are true:
The triggering event is untrusted, meaning someone other than a repository collaborator can trigger the event.
The workflow execution context and cache scope come from the shared default-branch SHA.
The most common workflow triggers that write to the default-branch cache keep full read-write caching. These triggers are push, schedule, workflow_dispatch, repository_dispatch, delete, registry_package, and page_build. Additionally, any trigger that uses a non-default-branch scope, such as pull_request and release, keeps read-write caching permission.
Who’s affected
This change regresses caching for a small set of untrusted workflows that write to the cache from a default-branch-SHA context. When a write is restricted, actions/cache logs a warning in the run and the job continues without saving. Restores are unaffected.
To keep the benefit of caching in these workflows, you will need to have a separate workflow triggered by an event with read-write cache access such as push which does cache saves. This will enable following workflows with read-only cache access to restore and use the cache.
This change ships to both github.com and GitHub with Data Residency. Check the GitHub Actions cache documentation to learn more, and join the discussion in GitHub Community.
The post Read-only Actions cache for untrusted triggers appeared first on The GitHub Blog.
関連記事
今日のまとめ
AIデイリーブリーフで今日の重要ニュースをまとめ読み