GitHub Actions向けのOIDC Roleとは？

OIDC roleは、GitHubがあなたのworkflowに発行する短命のトークンをtrust policyが受け入れるIAM roleで、pipelineが保存されたクレデンシャルなしにAWSにデプロイできるようにします。

長期のクラウドキーをCIのsecretsに保存することはセキュリティの負債です。OIDC (OpenID Connect) はそれをフェデレーテッドな信頼で置き換えます: GitHubがidentity providerとして動作し、あなたのworkflowが実行を記述する署名されたトークンを得て、AWSがそのトークンを一時的なクレデンシャルと交換します。結果は、キーレスで監査可能なdeployです。

トークン交換の仕組み

workflowの間、GitHubはrepository、branch、environmentのようなclaimを含む署名されたOIDCトークンを鋳造します。workflowはそれをAWS STSに提示し、STSはroleのtrust policyに対してトークンを確認し、一致すれば一時的なクレデンシャルを返します。

信頼のセットアップ

• GitHubをIAMのOIDC identity providerとして登録する。
• そのproviderを参照するtrust policyを持つroleを作成する。
• subクレームを介して、信頼を特定のrepo、branch、environmentにスコープする。
• deployが必要とするもののために、least-privilegeのpermission policyをアタッチする。

claimが制限を可能にするもの

トークンがrepo、ref、environmentを運ぶため、trust policyは例えば1つのrepositoryのmain branchだけを要求できます。別のrepoから漏洩したworkflowはroleをassumeできず、blast radiusを劇的に狭めます。

なぜチームが採用するか

OIDCはCIから最も価値の高いsecret、つまりクラウドキーを取り除きます。ローテーションするものも、漏洩するものもなく、すべてのassumeがログに残ります。同じパターンがGoogle Cloud (Workload Identity Federation) とAzure (federated credentials) で機能します。

CI/CDでの役割

GitHub Actionsでは、workflowにid-token: write パーミッションを付与し、それからrole ARNとともにconfigure-aws-credentials actionを使います。actionがトークン交換を処理し、後続のステップのために一時的なクレデンシャルをエクスポートします。AWSのaccess keyがあなたのrepositoryのsecretsに触れることは一切ありません。

重要なポイント

• OIDCは、GitHub Actionsが署名されたトークン経由で、保存されたキーなしにAWS roleをassumeできるようにします。
• trust policyは、特定のrepo、branch、environmentにアクセスをスコープできます。
• 同じフェデレーションのパターンがGoogle CloudとAzureにも存在します。

関連ガイド