【脱・暗号鍵管理】GitHub ActionsからAWSへ安全に接続するOIDC連携の構築ステップと実務のベストプラクティス

はじめに

モダンなインフラCI/CDを構築する際、GitHub ActionsからAWSへのデプロイ作業は日常的に発生します。しかし、一昔前のように「IAMユーザーのアクセスキーとシークレットキーをGitHubのSecretsに登録する」という運用は、セキュリティリスクが非常に高く、現在では推奨されていません。

本記事では、AWSとGitHub Actionsを安全に接続するための標準仕様となった「OIDC（OpenID Connect）連携」について、初心者から中級者のインフラエンジニア向けに、具体的な設定手順と実務で役立つ設計ベストプラクティスを分かりやすく解説します。

前提知識/必要な理由

なぜ「アクセスキー」ではなく「OIDC」なのか？

従来のアクセスキーによる認証には、以下のような重大なリスクが伴います。

鍵の漏洩リスク： GitHubの環境変数（Secrets）から誤ってログに出力されたり、リポジトリにハードコードされて流出する危険がある。
管理の煩雑さ： 定期的なローテーション（鍵の更新）を、人の手、あるいは追加の自動化ロジックで運用する必要がある。
過剰な権限： 1つのアクセスキーが永続的な権限を持つため、万が一漏洩した際の影響範囲が極めて広い。

これに対し、OIDC（OpenID Connect）連携を使用すると、GitHub ActionsがAWSに対して一時的な認証情報（STS: Security Token Service）を動的に要求します。これにより、「永続的な認証情報の管理が不要」かつ「有効期限が極めて短い（最長1時間など）一時的な認証トークンでのアクセス」が実現され、セキュリティが劇的に向上します。

具体的な設定手順・設計方法

ここからは、AWSとGitHub ActionsをOIDCで連携させる具体的な手順を解説します。今回はAWSマネジメントコンソールおよびTerraformでの実装も考慮した手順をご紹介します。

ステップ1: AWS IAMで「IDプロバイダー」を作成する

まず、AWSアカウントがGitHub（token.actions.githubusercontent.com）を信頼された認証先として認識できるように、IDプロバイダー（IdP）を登録します。

AWSマネジメントコンソールにログインし、IAMサービスを開きます。
左メニューから「IDプロバイダー」を選択し、「プロバイダを追加」をクリックします。
プロバイダのタイプに「OpenID Connect」を選択します。
以下の情報を入力します。
- プロバイダのURL： https://token.actions.githubusercontent.com（「サムネイルを取得」ボタンを押して検証します）
- 対象者（Audience）： sts.amazonaws.com
「プロバイダを追加」をクリックして完了します。

ステップ2: GitHub Actions専用のIAMロールを作成する

次に、GitHub Actionsが処理を実行する際に一時的に引き受ける（AssumeRoleする）IAMロールを作成します。

IAMの「ロール」メニューから「ロールを作成」をクリックします。
信頼されたエンティティタイプで「ウェブアイデンティティ」を選択します。
「IDプロバイダー」で先ほど作成したtoken.actions.githubusercontent.comを選択し、「Audience」でsts.amazonaws.comを選択します。
次に進み、このロールに付与したいIAMポリシー（例: AmazonS3ReadOnlyAccess, AmazonEC2FullAccessなど、実行したいタスクに応じた最小権限のポリシー）をアタッチします。
ロール名（例: github-actions-oidc-role）を入力し、作成を完了します。

ステップ3: 信頼関係（Trust Relationship）を詳細に制限する

デフォルトのままだと、すべてのGitHubリポジトリからこのAWSロールにアクセスできてしまう可能性があり危険です。特定のリポジトリかつ特定のブランチからのみアクセスを許可するように、信頼関係のポリシー（Trust Policy）を編集します。

作成したIAMロールの「信頼関係」タブを開き、以下のようにJSONを書き換えます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::YOUR_AWS_ACCOUNT_ID:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:YOUR_GITHUB_ORGANIZATION/YOUR_REPO_NAME:ref:refs/heads/main"
        }
      }
    }
  ]
}

※ YOUR_AWS_ACCOUNT_ID、YOUR_GITHUB_ORGANIZATION、およびYOUR_REPO_NAMEを環境に合わせて書き換えてください。上記の設定により、「対象リポジトリのmainブランチでの実行時のみ」アクセスが許可されます。

ステップ4: GitHub Actionsのワークフローを実装する

GitHubリポジトリ側に、AWS認証を行うワークフローファイル（.github/workflows/deploy.yml）を作成します。

ここで重要なのは、GitHub OIDCトークンを取得するためにpermissions: id-token: writeを設定することです。

name: AWS OIDC Deploy Test

on:
  push:
    branches:
      - main

permissions:
  id-token: write  # OIDCトークンの取得に必須
  contents: read   # リポジトリコードのチェックアウトに必要

jobs:
  aws-connect:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repo
        uses: actions/checkout@v4

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::YOUR_AWS_ACCOUNT_ID:role/github-actions-oidc-role
          aws-region: ap-northeast-1

      - name: Verify AWS Identity
        run: |
          aws sts get-caller-identity

実務での注意点

「id-token: write」権限の設定漏れ： これが未設定だと、GitHub側で一時的なJWT（JSON Web Token）が発行されず、AWS側でSignature validation failedなどのエラーになります。必ずJobまたはWorkflowのトップレベルに明記してください。
StringLikeによるリポジトリ制限： 信頼関係のCondition設定で、リポジトリの制限（repo:org/repo:*等）を怠ると、他人のGitHub ActionsからあなたのAWSアカウントへ不正アクセスされる経路（いわゆる「Confused Deputy問題」に類似した状態）が生まれてしまいます。設定時には必ずrepo:オーガニゼーション名/リポジトリ名:*を厳しく指定してください。
CloudTrailによる監査： OIDC経由のアクセスは、すべてAWS CloudTrailにAssumeRoleWithWebIdentityイベントとして記録されます。トラブルシューティングの際やセキュリティ監査の際は、CloudTrailでイベントソースを確認してください。

まとめ

GitHub ActionsとAWSのOIDC連携を導入することで、インフラ運用における最大のセキュリティリスクの1つである「アクセスキーの漏洩問題」を根本から解決できます。設定自体も、IAMのIDプロバイダーを1度作成してしまえば、以降はIAMロールの追加とGitHub Workflowの定義だけでスムーズに実装可能です。

実務においては、信頼関係ポリシーでのリポジトリ制限を適切に設定し、常に「最小権限の原則」を意識して運用しましょう。セキュアでクリーンなCI/CDパイプラインの構築に、ぜひ本記事をお役立てください。