技術記事 2026/7/4

GitHub ActionsからAWSへ“鍵を置かずに”デプロイする — OIDC連携とCI/CDの最小構成

GitHub ActionsのSecretsに長期アクセスキーを貼るのをやめる。OIDCで短命トークンを使いAWSへ鍵を渡さずにデプロイする最小構成と、信頼ポリシー（aud＋sub）を安全に絞る勘所を実務目線で整理します。仕様は現行時点の記述として公式もご確認ください。

#AWS
#CI/CD
#GitHub Actions
#OIDC
#IAM

GitHub ActionsのSecretsに、AWSの長期アクセスキーを貼り付けていないでしょうか。CI/CDからAWSへデプロイするとき、アクセスキーをそのまま保管する構成は広く使われてきましたが、鍵の漏洩やローテーションの負担という弱点を抱えます。これを解くのが OIDC（OpenID Connect＝ID連携の標準的な仕組み）です。本記事では、GitHub ActionsからAWSへ長期アクセスキーを置かずにデプロイする最小構成と、信頼ポリシーをどう絞れば安全かという勘所までを、実務の判断軸で整理します。なお、コマンドや仕様はバージョンで変わるため、本記事は現行仕様時点（2026年6月）の記述として読み、細部は公式ドキュメントも併せてご確認ください。

なぜ長期アクセスキーをCIに置きたくないのか

GitHub ActionsからAWSを操作する素朴な方法は、IAMユーザーのアクセスキーを発行し、リポジトリのSecretsに登録することです。動きはしますが、次の弱点があります。

漏洩リスク：長期間有効なキーがCIの設定に残り続け、ログ流出や設定ミスで外部に出れば、誰でもAWSを操作できてしまいます。
ローテーションの負担：安全のためには定期的にキーを作り替える必要がありますが、手作業のローテーションは抜け漏れが起きがちです。
権限過多になりやすい：「とりあえず動かす」ために広い権限を付けたまま放置されやすく、事故時の影響範囲が大きくなります。

CI/CDはpush→ビルド→デプロイを自動化する仕組みであり、その入口に長期間有効な鍵を置くほど、トラブル時の被害は大きくなります。この「鍵を置く」という前提そのものを外す選択肢が、OIDCによる連携です。

OIDC連携で何が変わるか

OIDCは、サービス間でID（身元）を安全に受け渡すための標準的な仕組みです。GitHub Actionsはこの仕組みのトークン発行者として、ワークフロー実行のたびに短命のトークンを発行できます。AWS側にそのGitHubを信頼するIAM OIDCプロバイダと、引き受け先のIAMロールを用意しておくと、ワークフローはこの短命トークンと引き換えに AssumeRoleWithWebIdentity（STSの操作）でロールを引き受け、一時的なクレデンシャルを取得します。

ポイントは、AWSが受け取るのが「その実行限りの短命トークン」であって、長期アクセスキーではないことです。保管すべき鍵が存在しないため、漏洩やローテーションという問題自体がなくなります。

GitHub ActionsがOIDCで短命トークンを発行し、AWSのIAM OIDCプロバイダで信頼を確認してAssumeRoleWithWebIdentityでIAMロールを引き受け、デプロイする流れを示した横長のフロー図。長期アクセスキーは渡らないことを示す — 図1: OIDCでロールを引き受けるまでの流れ（長期キーは渡さない）

最小構成の手順

鍵を置かないデプロイは、大きく3ステップで構成できます。手順は最小限にとどめ、細部は公式ドキュメントの現行版を確認してください。

AWSにIAM OIDCプロバイダを作成する：プロバイダのURLはGitHubの発行元（token.actions.githubusercontent.com）です。このプロバイダURLはアカウント内で一意のため、アカウントに一度だけ作成すれば足り、リポジトリごとに作る必要はありません。なお、古い記事にある「サムプリント（thumbprint）を取得して登録する」手順は、現行では実質的に不要です。AWSは信頼された認証局（CA）でGitHubのエンドポイントのTLS証明書を検証しており、サムプリントは信頼CA署名でない場合のフォールバックとして扱われます。
引き受け用のIAMロールと信頼ポリシーを作る：このロールがデプロイの実行主体になります。信頼ポリシーで「どのリポジトリ・どのブランチからの引き受けを許すか」を絞ります（絞り方は次章が核心です）。
ワークフローからロールを引き受ける：公式アクション aws-actions/configure-aws-credentials をOIDCモードで使います。アクセスキーは渡さず、引き受けるロールのARNとリージョンだけを渡します。

ワークフローの最小例は次のとおりです（現行仕様時点）。OIDCトークンを要求するため permissions に id-token: write が必須で、これが無いと失敗します。リポジトリを取得する actions/checkout を併用する場合は contents: read も付けます。

permissions:
  id-token: write
  contents: read      # checkout を使う場合
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v6   # 現行メジャー
        with:
          role-to-assume: arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME
          aws-region: ap-northeast-1
      # 以降は aws cli / cdk deploy などを実行

aws-actions/configure-aws-credentials は現行のメジャーバージョンが v6 系です。古い記事ではv1〜v4が使われていることがありますが、現行版に合わせます。タグは更新に追従する @v6 と、固定する @v6.1.0 のどちらも利用できます。バージョン番号や引数は変わりうるため、導入時に公式のREADMEで現行版を確認してください。

安全に絞る勘所

OIDCに切り替えれば自動的に安全になる、というわけではありません。安全性は信頼ポリシーの絞り込みで決まります。ここを緩くすると、長期キーを置く以上に危険な状態になり得ます。信頼ポリシーのConditionで最低限おさえるのは、次の2点です。

絞る対象	何を指定するか	緩いと何が起きるか
`aud`（audience）	`StringEquals` で既定値 `sts.amazonaws.com` に固定	想定外のトークンを受け入れる余地が残る
`sub`（subject）	リポジトリ＋ブランチ/環境まで厳密に固定	任意のブランチ・PR・タグ・環境から引き受け可能になる

sub の指定が甘いと、意図しない経路からロールを引き受けられてしまいます。たとえば repo:OWNER/REPO:* のようにワイルドカードで止めると、任意のブランチ・タグ・プルリクエスト・環境から引き受け可能になり、事故の入口になります。本番デプロイ用のロールであれば、次のように特定のブランチに固定します。

{
  "Condition": {
    "StringEquals": {
      "token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
      "token.actions.githubusercontent.com:sub": "repo:OWNER/REPO:ref:refs/heads/main"
    }
  }
}

本番環境だけに限定したい場合は、sub を repo:OWNER/REPO:environment:production の形にし、GitHubのEnvironments保護ルール（承認ゲートなど）と組み合わせると、引き受けの前に人手の承認を挟めます。

特に注意したいのが pull_request の扱いです。sub に repo:OWNER/REPO:pull_request を許すと、フォークや任意のプルリクエストからロールを引き受けてデプロイが走り得ます。プルリクエストをトリガーに本番デプロイ権限を渡す構成は避けるべきです。

ここで鮮度の注意が一点あります。2026年7月15日以降に作成されたリポジトリでは、sub がリポジトリ名ではなく不変の数値ID（repo:OWNER@組織ID/REPO@リポジトリID:... の形）を含む形式に変わります。リネームに強くするための変更です。信頼ポリシーの sub をリポジトリ名のベタ書きで決め打ちにせず、自分のリポジトリが実際に発行するトークンの sub を確認し、公式の現行記述に合わせてください。

そして、信頼ポリシーで引き受けを絞ったうえで、ロール自体の権限も最小限にします。デプロイに必要な操作だけを許可しておけば、万一引き受けられても被害を限定できます。「OIDCにしたから安全」ではなく、「aud と sub を厳密に絞り、ロールを最小権限にして初めて安全」と捉えるのが正確です。受託で客先のAWSへデプロイする運用では、長期キーを預かること自体が漏洩リスクと管理責任になります。OIDCで鍵レス化し、信頼ポリシーを客先のリポジトリ・ブランチに絞れば、預かる鍵をなくしたうえで「どこからデプロイできるか」を設計で固定できます。

まとめ

GitHub ActionsからAWSへのデプロイは、長期アクセスキーをやめてOIDC連携にすることで、保管すべき鍵そのものをなくせます。鍵を置かない構成は、IAM OIDCプロバイダの作成（アカウントに一度・サムプリントは現行不要）、引き受けロールと信頼ポリシー、公式アクションによる引き受けの3ステップで組めます。安全の条件は、aud と sub を厳密に絞り、ロールを最小権限にすることです。なお、GitHub以外のCI環境でも、X.509証明書を使うIAM Roles Anywhereなどで鍵レス化を設計できますが、本記事の最小構成からは外します。

インフラをコードで管理する仕組み（IaC）で土台を作り、本記事の鍵レスなCI/CDで安全に「出す」ようになると、次の関心は「壊れたときに気づく」「無駄なコストを抑える」へと移ります。CloudWatchのOpenTelemetryメトリクス対応による可観測性や、AWS FinOps Agent によるコスト最適化は、自動デプロイで回り始めた基盤を実務で支える組み合わせになります。まずは検証用のリポジトリとロールを一つ用意し、鍵を置かないデプロイを小さく試すところから始めてみてください。コマンドや仕様の最新情報は、導入時に公式ドキュメントでご確認ください。

出典

GitHub Docs「Configuring OpenID Connect in Amazon Web Services」 https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services
AWS IAM User Guide「Create an OpenID Connect (OIDC) identity provider in IAM」 https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html
aws-actions/configure-aws-credentials（README） https://github.com/aws-actions/configure-aws-credentials