CI/CD パイプライン構築コース

GitHub Actions × AWS OIDC — 秘密鍵を置かないデプロイ認証

GitHub Actionsが短命のOIDCトークンで自分の実行元を証明し、AWSが条件一致したIAMロールだけを一時的に貸し出す仕組みです。

TL;DR

  1. 長期アクセスキーをGitHub Secretsに保管しない。
  2. リポジトリ・ブランチ・環境の条件をIAM信頼ポリシーで限定する。
  3. GitHub側のid-token: writeとAWS側のロール権限を分けて考える。

01OIDCの認証は「証明→検証→一時発行」

GitHubとAWSが、鍵の保管ではなく署名付きトークンで接続する。

OIDCの認証は「証明→検証→一時発行」
GitHubとAWSが、鍵の保管ではなく署名付きトークンで接続する。

ジョブはGitHubのOIDC Providerからトークンを受け取り、AWS STSのAssumeRoleWithWebIdentityを呼ぶ。AWSはトークンと信頼ポリシーを照合し、一時認証情報を返す。

段階実行者内容
トークン取得GitHub Actions実行元を示すOIDCトークンを取得
ロール引受AWS STSAssumeRoleWithWebIdentityを呼ぶ
検証・発行AWS IAM信頼条件一致時だけ一時認証情報を返す

OIDCはGitHubがAWSへ恒久的にログインする仕組みではなく、条件つきで短命の認証情報を受け取る仕組み。

02長期アクセスキーとの違い

漏れると長く使える合鍵ではなく、都度発行される期限付きの入館証へ替える。

長期アクセスキーとの違い
漏れると長く使える合鍵ではなく、都度発行される期限付きの入館証へ替える。

OIDCトークンはジョブ実行時に取得し、AWS認証情報も一時的である。静的なAWS_ACCESS_KEYをSecretsへ置く方式より、保管・ローテーション・誤公開の攻撃面を減らせる。

観点静的アクセスキーOIDC
保管GitHub Secretsに長期保存原則不要
有効期間ローテーションまで継続ジョブ向けの一時情報
制約鍵の管理範囲に依存信頼ポリシーで実行元を限定

Secretsに入れないことだけで満足せず、IAMロールの信頼条件もリポジトリ・ブランチ単位で絞る。

03最小権限は二つの場所で決める

トークンを発行する権限と、AWSで何を操作できるかは別の設定。

最小権限は二つの場所で決める
トークンを発行する権限と、AWSで何を操作できるかは別の設定。

GitHub Actionsにはid-token: writeと必要なcontents権限を明示する。AWSの信頼ポリシーではリポジトリ・ブランチ等の条件を絞り、IAMポリシーではECR、SSM、ECSなど必要な操作だけを許可する。

設定箇所限定するもの例
GitHub permissionsトークン発行id-token: write
IAM信頼ポリシー誰がロールを引受けるかrepo・branch・environment
IAMポリシーAWSで何を操作できるかECR・SSM・ECSの必要操作のみ

GitHub側でトークンを発行できても、AWS側のIAMポリシーが許さない操作は実行できない。

結論

  1. OIDCは静的キーを置かないための認証方式。
  2. 信頼ポリシーで「誰が」、IAMポリシーで「何を」を絞る。
  3. stgだけでなく、デプロイ対象の全環境で設定を揃える。