背景
GitHub Actions + AWS CodeDeployでEC2にWebアプリを自動デプロイするハンズオンをやりました。GitHub ActionsからAWSへの認証にアクセスキーを一切使わない、OIDC(OpenID Connect)によるキーレス認証の設定が中心的な学びでした。
1. OIDCプロバイダーの登録は1アカウントにつき1回だけ
プロバイダータイプ: OpenID Connect
プロバイダーURL: https://token.actions.githubusercontent.com
対象者(Audience): sts.amazonaws.com
このプロバイダー登録はAWSアカウント単位で一度行えば、以降どのリポジトリのGitHub Actionsからでも信頼関係を結べます。別のハンズオン(ECS向けなど)で既に登録済みならスキップ可能、という再利用性の高い設定です。
2. IAMロールの信頼ポリシーでリポジトリとブランチを限定する
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::ACCOUNT_ID: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:OWNER/REPO:ref:refs/heads/main"
}
}
}
sub条件で「どのリポジトリの、どのブランチから来たトークンか」を限定できます。これにより、たとえ別のリポジトリでOIDC認証を試みても、このIAMロールにはAssumeRoleできません。アクセスキーの漏洩リスクがそもそも存在しない設計です。
3. Variables(機密でない値)とSecrets(機密情報)を使い分ける
GitHub Variables: EMPLOYEE_ID, AWS_ROLE_ARN, AWS_ACCOUNT_ID
ロールARNやアカウントIDは機密情報ではないため、暗号化されるSecretsではなくVariablesに保存します。パスワード類だけをSecretsに入れる、という使い分けのルールが明示されている点が実務的です。
4. actions/setup-javaがsettings.xmlを自動生成する
- uses: actions/setup-java@v4
with:
server-id: github
GitHub Packagesの認証情報を含むMavenのsettings.xmlを、server-id: githubの指定だけで自動生成してくれます。パスワード設定を手書きする必要がなく、GitHub Actionsのワークフロー定義がシンプルに保たれます。
5. デプロイパッケージはZIP化してS3経由でCodeDeployに渡す
deploy.zip
├── webapp.war ← Tomcatのwebapps/に配置
├── appspec.yml ← CodeDeployの設定
└── scripts/
├── stop_server.sh
├── start_server.sh
└── validate_service.sh
GitHub ActionsはビルドしたWARとCodeDeploy用のappspec.yml・スクリプト群をZIPにまとめてS3にアップロードし、CodeDeployにそのS3パスを指定してデプロイをトリガーします。GitHub Actions自体はEC2に直接アクセスせず、あくまでCodeDeployへの「デプロイ指示」だけを行う設計です。
まとめ
OIDC認証によるアクセスキー不要のAWS接続と、IAMロールの信頼ポリシーでリポジトリ・ブランチを限定する設計が、このハンズオンでの核心でした。GitHub Packagesの認証もactions/setup-javaの1行で自動化されており、CI/CDパイプライン全体で手動の認証設定がほぼ発生しない構成になっています。