今回はAWS ECSサービスに関する記事です。
前回までは、GitHub SecretsへAWSアクセスキーを登録し、GitHub ActionsからAmazon ECRへコンテナイメージをPushする構成を作成しました。
この構成でも問題なく動作しますが、長期アクセスキーをGitHubへ保管する運用となるため、実運用ではあまり推奨されません。
本記事ではシリーズ第5弾として、GitHub Secretsによるアクセスキー認証をAWS純正のOIDC認証へ移行し、一時認証でECRへPushできる構成へ改善していきます。
前回記事はこちら⇩
Azure経験者がAWS ECSで同じ構成を作ってみる⑤ ～GitHub ActionsのSecretsをOIDC認証へ置き換える～
実装内容
前回記事では、ECS ExpressMode(10-12を削除し14実施) を解説しました。
- Route53
- IAMロール
- DynamoDB
- ECR
- S3
- IAMユーザー
- GitHub
- SEG
- ECSクラスター
- ECSタスク定義
- ECS Service
- ALB
- DynamoDB項目追加
- ExpressModeで構築
- IAMプロパイダー
- IAMロール(OIDC用)
- GitHub修正
今回はIAMユーザーの代替としてIAMプロパイダーおよびOIDC用のIAMロール(15-17)
を設定し、動作確認まで実施します。
本記事は前回第二弾の読者の方を対象とし、1-5まで構築済の前提で進めていきます。
第二弾のIAMユーザを差し替えるだけのため、今回用のイメージ図はありません。
各種構築
IAMプロパイダー
まずはIAMユーザーのCredencialsの代替となるIAMプロパイダーを作成していきます。
■プロパイダー設定値
- プロパイダのタイプ：OpenID Connect
- プロパイダのURL：https://token.actions.githubusercontent.com
- 対象者：sts.amazonaws.com
(1)IAMプロパイダを開く
(2)パラメータを設定
(3)IAMプロパイダ作成完了確認
IAMロール(OIDC用)
先程作成したIAMプロパイダをセットしたIAMロールを作成します。
■IAMロールの設定値
とりあえず仮の値をセットします。信頼ポリシーは作成後に編集必要です。
- 信頼されたエンティティタイプ：ウェブアイデンティティ
- アイデンティティプロバイダー：token.actions.githubusercontent.com
- Audience：sts.amazonaws.com
- GitHub organization：＜GitHubのOrganization名またはユーザー名＞
- GitHub repository：＜リポジトリ名＞
- GitHub branch：空欄
- 許可ポリシー：AmazonEC2ContainerRegistryPowerUser
- IAMロール名：GitHub-OIDC-ECR-Push
(1)IAMプロバイダの情報をセット
作成したIAMプロパイダと自身のGitHub情報を記述していきます。
※画像は例として筆者のプライベートリポジトリを記述しています
(2)許可ポリシーの追加
検索窓から絞り込んでチェックを入れます。
(3)IAMロール名の設定
この画面で信頼ポリシーはどうやっても編集できませんので、不満ですがこのまま進めます。
※編集を押すと最初の画面に戻されます
(4)IAMロール作成完了
作成したロールを開きます。
(5)信頼ポリシーの編集
信頼関係タブから信頼ポリシ－の編集 を押下します。
(6)信頼ポリシー編集後
※コレを実施しないとGitHub Actions実施時に認証が通らずコケます
StringLike以下の設定値を、以下のように修正します。
“repo:＜GitHubのOrganization名またはユーザー名＞@*/＜GitHubのリポジトリ名＞@*:*”
今回は以下のようにワイルドカードを使用して認証しています。
“StringLike”: {
“token.actions.githubusercontent.com:sub”: “repo:addache@/sandbox@:*”
}
これにより、GitHubのOrganization IDやRepository IDを意識せずに動作確認できます。
※検証用の設定です。
最後に、ARNをコピーしておきます（このあとすぐ使う）
GitHub修正
今回はWorkflowのYamlテンプレート修正および、
変数としてVariablesを利用します。
OIDC情報は特に秘匿すべきものではありませんので、Secretsへ設定するのは少々過剰。
ただ記事として提供するにあたり、一意の値を含むパラメータは変数などの形で
外出ししたほうが提供しやすいです。そのためSecretsではなくVariablesを利用します。
Variablesには公開しても問題ない設定値を格納します。
■GitHubの設定値
- Name：AWS_ROLE_ARN
- Value：＜コピーしたIAMロールのARN＞
(1)Variablesの設定画面を開く
(2)Name:Valueをセット
(3)Variables設定完了
Variablesは[vars.<Name>]で呼び出すことができます。
(5)Workflowを上書き
以下のコードへ差し替えます。
※無効化している行は最終的に削除して問題ありません
name: Build and Push Docker Image
on:
push:
tags:
- "v*"
workflow_dispatch:
env:
AWS_REGION: ap-northeast-1
ECR_REPOSITORY: ecs-sample-api
permissions:
id-token: write
contents: read
jobs:
build-and-push:
runs-on: ubuntu-latest
steps:
- name: Checkout source code
uses: actions/checkout@v4
# OIDC版
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v5
with:
role-to-assume: ${{ vars.AWS_ROLE_ARN }}
aws-region: ${{ env.AWS_REGION }}
# アクセスキー版（切り戻し用）
# - name: Configure AWS credentials
# uses: aws-actions/configure-aws-credentials@v5
# with:
# aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
# aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
# aws-region: ${{ env.AWS_REGION }}
- name: Login to Amazon ECR
id: login-ecr
uses: aws-actions/amazon-ecr-login@v2
- name: Set image tag
id: image-tag
shell: bash
run: |
if [[ "${GITHUB_REF_TYPE}" == "tag" ]]; then
echo "value=${GITHUB_REF_NAME}" >> "$GITHUB_OUTPUT"
else
echo "value=manual-${GITHUB_SHA::7}" >> "$GITHUB_OUTPUT"
fi
- name: Build and push Docker image
env:
ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
IMAGE_TAG: ${{ steps.image-tag.outputs.value }}
run: |
IMAGE_URI="$ECR_REGISTRY/$ECR_REPOSITORY"
docker build \
-t "$IMAGE_URI:$IMAGE_TAG" \
-t "$IMAGE_URI:latest" \
.
docker push "$IMAGE_URI:$IMAGE_TAG"
docker push "$IMAGE_URI:latest"なお、操作がわからない方は第二弾でWorkflowを作成しているのでそちらを参照してください。
(6)ECR：Push前の状態を表示
ECRを開いてイメージPush前の状態を確認します。
(7)GitHub ActionsからPushして、ECRを確認
新しいイメージのPush成功しました。
これでOIDC化は完了です。
利用しなくなったSecretsは削除しておきましょう。
OIDC認証でハマったポイント
GitHub OIDCでは、実際に送信されるSubject(sub)をIAMロールのTrust Policyと一致させる必要があります。
今回検証したところ、
repo:addache/sandbox:...では認証されず、
CloudTrailを見ると実際には
repo:addache@222222222/sandbox@3333333333:ref:refs/tags/v1.1.2という形式で送信されていました。
※各IDは一応伏せてます
そのため本記事では
repo:addache@*/sandbox@*:*というワイルドカード指定で認証しています。
本番環境ではOrganization ID・Repository IDを固定して利用することをおすすめします。
最後に
実運用ではIDを固定する
本番環境では、ワイルドカードではなくOrganization ID・Repository IDを固定することを推奨します。
repo:addache@222222222/sandbox@3333333333:*GitHubのIDはGitHub APIから取得できます。
固有名は差し替えてご利用ください。
gh api users/addache --jq '.id'
gh api repos/addache/sandbox --jq '.id'またはREST APIでも取得できます（公開リポジトリの場合）。
https://api.github.com/users/addache
api.github.com補足
2026年8月時点では、
GitHub OIDCのSubject ClaimにOrganization ID・Repository IDが含まれる形式となっていました。従来の記事のように
repo:owner/repository:*のみでは認証に失敗する場合があるため、CloudTrailで実際のprincipalIdを確認しながら設定を調整しました。※AWSが自動生成する信頼ポリシーもこの形になっているので注意が必要です
関連記事のご紹介
シリーズ初回記事、各種準備と設計のご紹介
シリーズ2回目記事、主にGitHubの設定方法解説
シリーズ3回目記事、ECSデプロイして動作検証まで実施
シリーズ4回目記事、ECS ExpressModeでデプロイして動作検証まで実施
コメント