GitLab CI/CD（GitLabが提供するCI/CDパイプライン機能）からAWSリソースを操作する構成を運用しているエンジニアに向けた内容です。IAMユーザーのアクセスキーをCI/CD変数に登録して使っている場合、その認証方式には設計上のリスクが潜んでいます。今回はOIDC（OpenID Connect、外部サービス間でIDトークンをやり取りして認証する仕組み）を使った代替構成の技術的な仕組みと、移行判断の基準を整理します。
IAMユーザーのアクセスキーは、発行した瞬間から失効させるまで有効な永続クレデンシャル（認証情報）です。CI/CDのログに誤って出力されたり、リポジトリに混入したりすると、手動でローテーション（鍵の更新・無効化）するまで悪用され続けるリスクがあります。これはCI/CDパイプラインのセキュリティ設計における典型的な弱点です。
OIDC連携が解決する問題
OIDCフェデレーション（複数のシステム間でID情報を連携させる仕組み）を使うと、GitLabはAWSに対して短命なトークンで身元を証明できます。AWSはそのトークンを検証し、有効期限付きの一時クレデンシャルをSTS（Security Token Service、一時的な認証情報を発行するAWSのサービス）経由で払い出します。
認証の流れは次の5段階です。
- GitLabがCI/CDジョブ用のOIDCトークンを発行する
- パイプラインがそのトークンをAWSに送信する
- AWSがトークンの発行元がGitLabであることを検証する
- 対象プロジェクトが要求したIAMロールを引き受けられるか確認する
- AWS STSが一時クレデンシャルを返却する
この一時クレデンシャルは自動的に失効するため、GitLab側に恒久的な秘密情報を保存する必要がなくなります。これがアクセスキー方式との最大の違いです。
実装の骨格を段階的に見る
まず、AWS側にGitLabをOIDCプロバイダとして登録します。Terraform（インフラをコードで定義するIaCツール）を使うと次のように書けます。
resource "aws_iam_openid_connect_provider" "gitlab" {
url = var.gitlab_url
client_id_list = [var.gitlab_url]
thumbprint_list = [data.tls_certificate.gitlab.certificates[0].sha1_fingerprint]
}これだけでは不十分です。「GitLabというサービス自体を信頼する」設定と、「どのGitLabプロジェクトにどのIAMロールを許可するか」は別の設定になります。後者を担うのがIAMのTrust Policy（信頼ポリシー）です。
Trust Policyでは、トークンに含まれるaud（想定される受信者）、sub（プロジェクトとブランチの識別子）、namespace_id（GitLabの名前空間を示す数値ID）といったクレーム（トークン内の属性値）を条件式で検証します。namespace_idはプロジェクト名や組織名が変更されても値が変わらない数値識別子なので、条件判定の軸として安定しています。プロジェクト名だけで制御すると、リネーム時に意図せず権限が漏れる設計ミスにつながりかねません。
権限設計はロール単位の最小化がポイント
OIDC移行のもう一つの論点は、IAMロールの粒度です。1つの共有ロールに全権限をまとめるのではなく、リポジトリやパイプラインの役割ごとにロールを分割する設計が紹介されています。
| リポジトリ | 主な権限 | 設計意図 |
|---|---|---|
| backend | ECRへのイメージpush | デプロイ権限は持たせない |
| frontend | ECRへのイメージpush | 同上 |
| infrastructure | Terraformでのインフラ操作 | アプリ実行環境への権限は分離 |
| deploy | ECRのイメージ確認とEKSへのデプロイ | pushは不可、read系のみ |
deployロールにはecr:DescribeImagesやecr:DescribeRepositoriesのような参照系アクションのみを与え、pushは許可しません。これは最小権限の原則（必要な操作だけを許可する設計方針）をIAMロール単位で徹底する具体例です。1つのロールが全パイプラインの権限を持つ構成は、どこか1つのジョブ設定が漏洩・改ざんされた際の被害範囲を広げてしまいます。
他の認証方式との比較で見える立ち位置
OIDC連携は目新しい技術ではありません。GitHub Actionsも同様のOIDC連携機能をAWSやGCP向けに提供しており、Kubernetes環境でのIRSA（IAM Roles for Service Accounts）もほぼ同じ発想です。共通するのは「長期クレデンシャルを配布せず、実行時に短命トークンへ交換する」という設計思想です。
日本国内でもAWS Organizationsでマルチアカウント運用をしているチームでは、CI/CDから各アカウントへのクロスアカウントアクセスをアクセスキーで運用しているケースが残っています。棚卸しの際に、GitLab・GitHub・CircleCIなどCI基盤側がOIDCプロバイダをサポートしているか確認しておくと、移行の優先順位付けがしやすくなります。
今日確認できること
移行を検討する前に、まず自分たちの環境で何が起きているかを確認しておくと判断しやすくなります。
- GitLab CI/CDのプロジェクト設定でCI/CD変数を開き、AWS_ACCESS_KEY_IDのような永続キーが登録されていないか棚卸しする
- AWSのIAMコンソールで「アイデンティティプロバイダ」にGitLabのOIDCエンドポイントがすでに登録済みか確認する
- 既存IAMロールのTrust Policyでaud・sub・namespace_idの条件が絞られているか、それとも広範なワイルドカードになっていないか点検する
- 1つのIAMロールが複数のパイプライン(push・deploy・infra操作)を兼用していないか洗い出す
- IAMユーザーのアクセスキーの発行日・最終使用日をIAMの認証情報レポートで確認し、ローテーション運用が形骸化していないか見る
まとめ
GitLab CI/CDとAWSの認証をOIDC化する構成は、永続クレデンシャルの保管・漏洩・ローテーションという運用負債を仕組みごと取り除く設計判断です。IAMのTrust Policyでaud・sub・namespace_idを検証し、リポジトリごとにロールを分けることで、権限の境界をトークンの中身に基づいて厳密に管理できます。
既存の構成にIAMアクセスキーが残っている場合は、まずCI/CD変数とIAM認証情報レポートを見比べて、どのキーがどのパイプラインで使われているかを洗い出すところから始めてみてください。棚卸しの結果次第で、OIDC移行の優先順位や段階的な切り替え計画が立てやすくなるはずです。