【ITニュース解説】GitHub Actions OIDC to AWS: dropping long-lived access keys

現在の多くのプロジェクトでは、GitHub ActionsがAWSにアクセスするために、「AWS_ACCESS_KEY_ID」や「AWS_SECRET_ACCESS_KEY」のような、長期間有効な認証情報をGitHubのシークレットに保存している場合が多い。しかし、これらのキーは一度漏洩すると、攻撃者によって無期限に利用されてしまうという大きなセキュリティリスクを抱えている。スクリーンショットで盗まれたり、更新を忘れて古いキーが残存したりするなど、様々な脆弱性があるため、このような長期的なキーの利用はセキュリティ上の大きな「負債」となる。

この問題を根本的に解決するのが、「GitHub Actions OIDC to AWS」という仕組みだ。OIDCはOpenID Connectの略で、これにより、長期的なアクセスキーを使うことなく、必要な時にだけ発行される「一時的な認証情報」でAWSに安全にアクセスできるようになる。

OIDCの仕組みは以下の通りだ。GitHub Actionsのワークフローが実行される際、GitHubのトークンサービスは、そのワークフローが正規のものであることを証明する「署名付きのJWT（JSON Web Token）」という情報を発行する。このJWTは、特定のワークフローやリポジトリに関する情報が詰まった身分証明書のようなものだ。AWSは、このJWTを受け取ると、事前に設定された「IDプロバイダー」を通じて、そのJWTがGitHubから発行された正規のものであることを検証する。秘密のキーを交換するのではなく、信頼できる第三者（GitHub）からの身分証明書（JWT）を信じる形だ。AWSがこのJWTを信頼すると、「AWS STS（Security Token Service）」というサービスが、そのワークフローが必要とする権限を持った「一時的な認証情報」を発行する。この一時認証情報は、デフォルトでは1時間など短期間しか有効でなく、ワークフローの実行が終われば自動的に無効になるため、長期的なキーのように漏洩のリスクを抱えることがなくなる。

このOIDCの仕組みをAWSで利用するには、まず「OIDCプロバイダー」というものをAWSアカウントに一度だけ作成する必要がある。これは、AWSがGitHubのトークンサービスを信頼するための設定で、GitHubのトークン発行元である「https://token.actions.githubusercontent.com」というURLを、AWSのIAM（Identity and Access Management）のIDプロバイダーとして登録する。このプロバイダーはAWSアカウント全体で共有されるため、複数のリポジトリやワークフローからAWSにアクセスする場合でも、一度設定すれば使い回せる。プロジェクトごとに重複して作成しようとするとAWSに拒否されるため、注意が必要だ。

OIDCプロバイダーの設定が完了したら、次にIAMロールの「信頼ポリシー」を設定する。これがセキュリティの大部分を担う重要な部分だ。信頼ポリシーとは、誰がこのIAMロールを引き受ける（AssumeRole）ことを許可するかを定義するものだ。OIDCを使う場合、このポリシーの中で、GitHubから発行されたJWTがどのリポジトリ、どのブランチ、どの環境からのものかを厳密に指定する必要がある。例えば、「repo:my-org/my-repo:environment:production」のように、組織名、リポジトリ名、さらにデプロイ先の環境名までを正確に指定することで、その特定のコンテキストからのみロールの引き受けを許可する。

ここで最も注意すべき点は、信頼ポリシーを「repo:my-org/*」のようなワイルドカードで設定しないことだ。このような設定は、組織内のどのリポジトリからでもそのロールを引き受けられるようにしてしまい、セキュリティが緩いリポジトリや、悪意のあるサードパーティ製アクションを実行しているリポジトリからもアクセスが許可されるリスクがある。必ず特定の正確なリポジトリ、そして可能であれば特定の環境名まで指定することで、最大限のセキュリティを確保するべきだ。

信頼ポリシーを厳密に設定できたとしても、そのIAMロールに付与するAWS権限が広範だと意味がない。例えば、「すべてのリソースに対するあらゆる操作」を許可するような設定は避けるべきだ。ワークフローが本当に必要とする最小限の権限のみを付与する「最小権限の原則」を厳守する必要がある。例えば、あるワークフローが特定のECRにイメージをプッシュするだけなら、そのECRへのプッシュ権限だけを付与する。ステージング環境と本番環境のデプロイにはそれぞれ別のIAMロールを用意したり、Terraformの「計画（plan）」と「適用（apply）」で異なる権限セットを持つロールを使用するなど、用途に応じてロールと権限セットを細かく分離することが推奨される。

GitHub Actionsのワークフローファイル側にも設定が必要だ。OIDCトークンをGitHubから要求するためには、ジョブまたはワークフローレベルで「permissions: id-token: write」という権限を明示的に記述する必要がある。この設定がないと、OIDCトークンを取得できずにワークフローが失敗する。また、actions/checkout のようにリポジトリのコードを読み取るアクションを使う場合は、「contents: read」も一緒に記述する必要がある。

AWSとの連携には「aws-actions/configure-aws-credentials」というGitHub Actionを利用する。このアクションを使って、どのIAMロールを引き受けるか（role-to-assume）、どのAWSリージョンを使用するか（aws-region）などを指定する。セキュリティの観点から、このアクションのバージョンは「@v4」のようなメジャーバージョン指定ではなく、特定のコミットSHA（識別子）に固定することが強く推奨される。これにより、もしアクション自体に脆弱性が含まれたり、悪意のある変更が加えられたりしても、意図しないコードが実行されるリスクを最小限に抑えられる。

ワークフローが失敗した場合、そのエラーメッセージを注意深く確認することが重要だ。よくある2つのエラーパターンとその原因は異なる。一つは「アクションがACTIONS_ID_TOKEN_REQUEST_URL環境変数を取得できない」というエラーで、これは通常「permissions: id-token: write」が不足していることを意味する。もう一つは「Not authorized to perform sts:AssumeRoleWithWebIdentity」というエラーで、これはOIDCトークンはAWSに到達したものの、IAMロールの信頼ポリシーで拒否されたことを意味する。IAMロールのARNが間違っているか、信頼ポリシー内の条件がトークンの情報と一致していない可能性が高い。

デプロイの監査可能性を確保することも非常に重要だ。aws-actions/configure-aws-credentialsアクションのrole-session-nameには、GitHub Actionsの実行ID（github.run_id）や実行者（github.actor）など、ワークフロー実行に紐づく一意の情報を設定する。これにより、AWSのCloudTrail（監査ログサービス）に記録されるセッション情報から、どのGitHub Actionsのワークフロー実行が、いつ、どのような操作をAWSで行ったのかを簡単に追跡できるようになる。もしセキュリティインシデントが発生した場合でも、「誰がこれをデプロイしたのか」を迅速に特定できる。

最後に、長期的なアクセスキーからOIDCへの移行は、一度にすべてを完了させるのが難しい場合が多い。組織内のすべてのリポジトリやワークフローがOIDCに移行するまでには、ある程度の移行期間を設ける必要がある。この期間中は、OIDCに移行済みのリポジトリと、まだ古い静的なキーを使っているリポジトリを明確に区別し、進捗を管理することが重要だ。GitHub CLIなどのツールを使って、組織内のリポジトリにAWS関連のシークレットが残っていないかを定期的に監査するべきだ。すべてのワークフローがOIDCに切り替わったことを確認した後、初めてGitHubのシークレットから古い静的なキーを削除する。さらに、そのキーを使用していたIAMユーザーも完全に削除することで、誤って古いキーが再利用されるリスクを排除できる。焦ってキーを削除してしまうと、まだOIDCに移行していないワークフローが突然動かなくなり、予期せぬ障害につながる可能性があるため、細心の注意を払って移行を進めることが求められる。

このOIDCの導入は、AWSとGitHub Actionsを連携させる際のセキュリティを劇的に向上させるものであり、システムエンジニアとして学習・実践する価値は非常に高い。