【入門編】CircleCI OIDC連携でAWSの静的クレデンシャルを廃止！安全な認証の完全ガイド – バージョン管理・CI/CD活用バイブル

こんにちは！チームのインフラや自動化を支えるあなたへ。
今回は、CircleCIとAWSの連携において、セキュリティの常識を根底から覆す「OIDC（OpenID Connect）連携」について、徹底的に解説していきます。

これをマスターすれば、AWSのアクセスキー漏洩の恐怖から完全に解放され、毎日のパイプライン管理が劇的に安全でスマートになりますよ。さあ、一緒にモダンな認証の世界へ踏み出しましょう！

—

1. なぜ「IAMユーザーのアクセスキー」を今すぐ捨てるべきなのか？

CircleCIなどのCI/CDツールからAWSリソース（S3へのデプロイ、EKSへのプッシュ、Lambdaの更新など）を操作する場合、これまで一般的に使われてきたのが「AWS IAMユーザーの長期的なアクセスキー（Access Key ID & Secret Access Key）」です。

あなたも、CircleCIの「プロジェクト環境変数」に `AWS_ACCESS_KEY_ID` と `AWS_SECRET_ACCESS_KEY` を登録した経験があるのではないでしょうか？

しかし、このアプローチには3つの重大なリスクが潜んでいます。

1. 漏洩のリスク: 万が一、CircleCIのログや環境変数が外部に露出した場合、あるいは開発者のローカル端末からキーが流出した場合、AWS環境への不正アクセスの扉が開いてしまいます。
2. ローテーションの地獄: セキュリティベストプラクティスでは、アクセスキーは定期的に（例えば90日ごとに）ローテーション（再発行・更新）することが推奨されますが、これを手動や半自動で運用するのは大変な手間です。
3. 権限の過剰付与: 利便性を優先するあまり、広範な権限を持った「万能なアクセスキー」をCI/CDに与えてしまいがちです。

救世主「OIDC（OpenID Connect）」とは？

そこで登場するのが、今回解説する OIDC連携 です。

OIDCを使うと、CircleCIでジョブが実行されるたびに、AWS側が「今、CircleCIで動いているこの特定のジョブは、本当に信頼できるものか？」を暗号学的に検証し、その場限りの「一時的なAWSクレデンシャル」を動的に発行してくれます。

つまり、「AWSのパスワード（シークレットキー）をCircleCIに保存する必要が一切なくなる」のです。これぞ、現代のDevOpsにおけるマストハブなセキュリティプラクティスです。

—

2. 全体像の理解：AWSとCircleCIはどう信頼し合うのか？

仕組みはシンプルです。信頼関係（Trust）を一度構築してしまえば、あとはすべて自動で行われます。

1. CircleCIのビルド開始: ジョブが走ると、CircleCIは自らを証明するデジタル署名入りのトークン（OIDCトークン / JWT）を生成します。
2. AWSへの一時クレデンシャル要求: CircleCI上のAWS CLIやAWS公式Orbが、そのトークンを添えてAWSのSTS（Security Token Service）にアクセスします。
3. 信頼関係の検証: AWSは、事前に登録された設定に基づき、「お、このトークンは信頼できるCircleCI組織から発行されたものだな」と検証します。
4. 一時権限の付与: 検証に成功すると、AWSは数十分〜数時間だけ有効な一時的なアクセスキーとシークレット、セッショントークンをCircleCIに返却します。

これで、シークレットを永続的に保存・管理するリスクから完全に解放されます。

—

3. ステップバイステップ：OIDC連携の構築手順

それでは実際に、AWSとCircleCIをOIDCで結びつける手順を一緒に見ていきましょう。

ステップ1：AWS側で「IDプロバイダー（IdP）」を作成する

まず、AWSマネジメントコンソールで「IAM（Identity and Access Management）」を開き、CircleCIを外部IDプロバイダーとして登録します。

1. IAMダッシュボードのサイドメニューから [アクセス管理] > [アイデンティティプロバイダー] を選択し、[プロバイダーを追加] をクリック。
2. プロバイダーのタイプで [OpenID Connect] を選択。
3. 以下の情報を入力します：

プロバイダーのURL: `https://oidc.circleci.com/orgs/<あなたのCircleCI組織ID>`

(※ `<あなたのCircleCI組織ID>` は、CircleCIのOrganization Settings > Overview で確認できるUUIDです)

対象者 (Audience): 上記の組織IDと同じものを入力します。

4. [プロバイダーを追加] をクリックして完了です。

ステップ2：IAMロールと信頼ポリシー（Trust Policy）の作成

次に、CircleCIのジョブが引き受ける（AssumeRoleする）ためのIAMロールを作成します。ここがセキュリティの肝です。

「特定のCircleCI組織の、特定のプロジェクト（あるいは特定のブランチ）からのみ、このロールを奪える」という厳密な条件を設定します。

1. IAMの [ロール] メニューから [ロールを作成] を選択。
2. 信頼されたエンティティタイプで [ウェブアイデンティティ] を選択。
3. 先ほど作成したIdentity Providerを選択し、Audienceを設定します。
4. ロールを作成後、信頼ポリシー（Trust Policy）を以下のように編集します。

{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Principal”: {
“Federated”: “arn:aws:iam::<あなたのAWSアカウントID>:oidc-provider/oidc.circleci.com/orgs/<あなたのCircleCI組織ID>”
},
“Action”: “sts:AssumeRoleWithWebIdentity”,
“Condition”: {
“StringEquals”: {
“oidc.circleci.com/orgs/<あなたのCircleCI組織ID>:aud”: “<あなたのCircleCI組織ID>”
},
“StringLike”: {
“oidc.circleci.com/orgs/<あなたのCircleCI組織ID>:sub”: “org/<あなたのCircleCI組織ID>/project/<あなたのCircleCIプロジェクトID>/user/”
}
}
}
]
}

> 💡 先輩エンジニアのワンポイントアドバイス
> 上記の `StringLike` の `sub`（サブジェクト）部分に注目してください。これにより、「特定のプロジェクトIDから実行されたジョブ以外からは、絶対にこのAWSロールを使わせない」という強固な縛りを入れることができます。プロジェクト単位でロールを分けるのがベストプラクティスです。

5. 最後に、このIAMロールに必要な権限（例: `AmazonS3FullAccess` や、デプロイ用のカスタムポリシーなど）をアタッチしておきます。

—

4. CircleCI設定ファイル（.circleci/config.yml）の書き方

さあ、AWS側の準備が整いました。いよいよCircleCIの設定ファイルに手を入れます。
環境変数からシークレットを排除し、公式のAWS Orbを使ってスマートに認証を行いましょう。

以下の設定例を参考にしてください。

version: 2.1

AWSとの連携を簡単に行うために公式のAWS Orbを利用します
orbs:
aws-cli: circleci/aws-cli@4.1.3

jobs:
deploy-to-s3:
docker:

image: cimg/base:stable

steps:

checkout

# 1. OIDCを使ってAWSの仮免許（一時クレデンシャル）を取得する
# ここでIAMユーザーのアクセスキーは一切登場しません！

aws-cli/setup:

role-arn: “arn:aws:iam::<あなたのAWSアカウントID>:role/<作成したIAMロール名>”
aws-region: “ap-northeast-1”

# 2. 認証が通っていることを確認し、AWSコマンドを実行する

run:

name: AWSの接続確認とS3へのデプロイ
command: |
# ちゃんと一時クレデンシャルで認証されているか確認（デバッグに便利）
aws sts get-caller-identity

# 例：ビルド成果物をS3バケットに同期する
# aws s3 sync ./dist s3://my-awesome-app-bucket/
echo “安全にAWSへデプロイできました！”

workflows:
deploy-workflow:
jobs:

deploy-to-s3:

context:
# 必要に応じてコンテキストを利用（OIDCではシークレット不要ですが、定数管理に便利です）

aws-production-context

filters:
branches:
only: main

—

5. 精度高いHelloWorld的動作確認：パイプラインを回してみよう！

設定が完了したら、実際にコードをコミットしてCircleCIでパイプラインを走らせてみましょう。

1. `.circleci/config.yml` をリポジトリにプッシュします。
2. CircleCIのダッシュボードでジョブの実行ログを開きます。
3. `aws-cli/setup` ステップのログを展開してみてください。次のような流れが確認できるはずです：

CircleCI内部でOIDCトークンが生成されたこと。
そのトークンを添えてAWS STSに `AssumeRoleWithWebIdentity` リクエストが送られたこと。
無事に一時セッションが取得され、環境変数（`AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY`, `AWS_SESSION_TOKEN`）に自動でセットされたこと。

ジョブが「Success」になり、`aws sts get-caller-identity` の出力にあなたが作成したIAMロールのARNが表示されていれば、OIDC連携の完全な成功です！お疲れ様でした！

—

まとめ：安全なCI/CDの第一歩を踏み出そう

今回は、CircleCIとAWSのOIDC連携について、IAMユーザーの廃止というセキュリティ上のメリットから、具体的なAWS側の設定、そしてCircleCIの設定ファイルの実装まで一気通貫で解説しました。

もう、アクセスキーの有効期限切れや漏洩に怯える必要はありません。
コードベース（設定ファイル）側で「どのプロジェクトからアクセスされたか」を厳密に制御できます。

これをマスターすれば、あなたのチームのセキュリティレベルは一段も二段も跳ね上がります。ぜひ今日の業務に取り入れて、より安全で快適なCI/CDライフを手に入れてくださいね。それでは、また次回の技術解説でお会いしましょう！