この記事は、ニフティグループ Advent Calendar 2024 18日目の記事です
1. はじめに
こんにちは。ニフティ新卒１年目のSREチームに所属している滝川です。
AWS環境でTerraformを使ったCI/CDパイプラインを構築する際、認証情報の管理は避けて通れない課題です。これまで、”AWS Access Key方式”を使用する方法が一般的でしたが、セキュリティや運用の面から、最近ではIAMロールを活用する方法が注目されています。
この記事をご覧の方は、アクセスキー方式ではなくIAMロールを用いて認証を行いたい方、もしくは以下のようなエラーの解消を試みている方々だと思います。
|
1 |
Error: Credentials could not be loaded, please check your action inputs: Could not load credentials from any providers |
このエラーはGitHub ActionsがAWSリソースにアクセスするための適切な認証情報を見つけられない状況を示しています。
上記の課題はIAMロールを用いた認証方法の実装することで解決すると思います。手順を詳細に説明しているのでぜひ最後までお読みください。
2. 従来の認証方法: AWS Access Keyの使用
1. 仕組み
AWS Access Keyは、AWSアカウントのアクセス許可を設定するためのキーです。Access Key ID と Secret Access Key をGitHub Secretsに登録し、GitHub Actionsで環境変数として使用します。
以下は典型的なGitHub Actionsの設定例です。
|
1 2 3 4 5 6 |
- name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v2 with: aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} aws-region: ap-northeast-1 |
GitHub Secretsには以下を保存します。
- AWS_ACCESS_KEY_ID: IAMユーザーで作成したAccess Key ID
- AWS_SECRET_ACCESS_KEY:IAMユーザーで作成したSecrets Access Key
2. 課題
- セキュリティリスク
- 長期的に有効なクレデンシャルであるため、流出した場合のリスクが大きい。
- 一度流出すると、取り消すまで悪用される可能性がある。
- 権限の制御が難しい
- IAMユーザー単位での権限付与になるため、CI/CD専用の細かな権限設定が難しい。
- 必要以上の権限が付与されやすく、最小権限の原則に反する可能性がある。
3. 新しい認証方法: IAMロールとGitHub Secrets
1. 仕組み
AWSのIAMロールを使えば、長期的なアクセスキーを使わずに安全に認証を行えます。GitHub ActionsがAWSに一時的な権限をリクエストすることで、最小限の権限で操作を行います。
以下のように設定します。
|
1 2 3 4 5 |
- name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v2 with: role-to-assume: ${{ secrets.AWS_ROLE_ARN }} aws-region: ap-northeast-1 |
GitHub Secretsには以下を保存します。
- AWS_ROLE_ARN: 作成したIAMロールのARN
3.2 メリット
- セキュリティ向上
- GitHub Actionsでのみ有効な一時的な権限を使用するため、クレデンシャル流出のリスクが低減。
- 一時的な認証情報は短期間で失効するため、万が一流出しても影響を最小限に抑えられる。
- 最小権限の適用が容易
- IAMロールに対して必要最小限の権限を設定可能。
- Assume Roleを使用することで、特定のリソースやサービスに対する権限を細かく制御できる。
- CI/CD処理に必要な操作のみを許可するIAMポリシーを柔軟に設定可能。
4. 比較: AWS Access Key と IAMロール
| 項目 | AWS Access Key | IAMロール |
|---|---|---|
| 運用負荷 | 高い | 低い |
| 追跡 | 難しい | 容易 |
| 最小権限の適用 | 難しい | 容易 |
5. 実装手順
Step 1: IAM OIDC IDプロバイダを追加
- OpenID Connectを選択
- プロバイダのURLにhttps://token.actions.githubusercontent.com
- 対象者にsts.amazonaws.com
- プロバイダを追加をクリック
Step 2: IAMロールを作成
AWS CLIまたはAWSコンソールでIAMロールを作成します。以下の設定を行います。
- IAMロールの信頼関係を設定
ロールを信頼するエンティティとしてGitHub Actionsを指定します。
12345678910111213141516171819202122{"Version": "2012-10-17","Statement": [{"Effect": "Allow","Principal": {"Federated": "arn:aws:iam::xxxxx: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:xxxxx/*"]}}}]}
- ポリシーのアタッチ Terraformに必要な権限（例: S3, EC2, IAM）のみを付与します。
Step 3: GitHub Secretsに登録
GitHubのsetting→Actions secrets and variables→actionsからsercretsに以下の値を登録
- AWS_ROLE_ARN: Step2で作成したIAMロールのARN
Step 4: GitHub Actionsの設定
.github/workflows/terraform.yml（任意のファイル）で環境変数を定義する。
下記はterraformのCIの実装例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
name: Terraform CI on: push: branches: - main jobs: terraform: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v3 - name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v2 with: role-to-assume: ${{ secrets.AWS_ROLE_ARN }} - name: Setup Terraform uses: hashicorp/setup-terraform@v2 with: terraform_version: 1.9.8 - name: Terraform Init run: terraform init - name: Terraform Plan run: terraform plan |
6. まとめ
従来のAWS Access Keyを用いた認証方法には、セキュリティと運用の課題がありましたが、IAMロールを活用することで、認証情報を容易でセキュアに設定することができます！
ぜひ、この方法を試してみてください！
