この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
あけましておめでとうございます。広島の吉川です。
[GitHub Actions]aws-actions/configure-aws-credentialsを使ってOIDCプロバイダを介したSwitchRoleをする | DevelopersIO
において、
"Condition": {
"StringLike": {
"vstoken.actions.githubusercontent.com:sub": "repo:{GITHUB_ORGANIZATION_NAME}/{GITHUB_REPO_NAME}:*"
}
}
のCondition指定をもし行わなかった場合、どのようなリスクがあるのか気になったので検証してみました。
TLDR
Conditonが無条件の場合、あらゆるGitHubリポジトリからAssumeRoleできてしまうと思われるため、必ず"token.actions.githubusercontent.com:sub"のConditionを指定してリポジトリを制限するようにする。
検証してみた
前提
- GitHub Actions用IDプロバイダ
は作成済みとします。
IAMポリシー作成
検証用のIAMポリシーを作成します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "sts:GetCallerIdentity",
"Resource": "*"
}
]
}
sts:GetCallerIdentityのみ許可しています。
IAMロール作成
上のポリシーをアタッチしたIAMロールを作成します。
信頼関係を下記のように編集します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::{AWS_ACCOUNT_ID}:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity"
}
]
}
あえてConditionを設定しないようにします(実践では必ず指定してください)。
GitHub Actions workflowファイルを作成
# .github/workflows/build.yml
name: Build
on: push
env:
AWS_ROLE_ARN: arn:aws:iam::{AWS_ACCOUNT_ID}:role/{IAM_ROLE_NAME} # 作成したIAMロールのARN
permissions:
id-token: write
contents: read
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- uses: aws-actions/configure-aws-credentials@v1
with:
role-to-assume: ${{ env.AWS_ROLE_ARN }}
aws-region: ap-northeast-1
- run: aws sts get-caller-identity
PushしてGitHub Actionsを動作させる
自分のリポジトリにPushして動作検証します。
するとこのようにAssumeRoleできてしまいます。
Conditionの"token.actions.githubusercontent.com:sub"でリポジトリ制限をしていないため、おそらく他人のリポジトリでもAssumeRole可能であり、危険な状態と考えられます。
[重要]GitHub Actions OIDC+IAMロール自体は安全性の高い手法
本記事は設定ミスに気をつけましょうという趣旨であり、GitHub Actions OIDC+IAMロールの手法が危険と言いたいわけではありません。
むしろ従来のアクセスキーを払い出してセットする方法よりも安全性は高く、aws-actions/configure-aws-credentials@v1に取り込まれたこともあり現在はこちらが推奨であると思われます。
- GitHub ActionsでAWSの永続的なクレデンシャルを渡すことなくIAM Roleが利用できるようになったようです | DevelopersIO
- ついにaws-actions/configure-aws-credentials@v1にOIDCでAssumeRoleできる機能が取り込まれました! | DevelopersIO
人間が作業する以上(本件に限らず)すべてにおいて設定ミスの可能性をゼロにはできません。例えば、リソースの操作はできるだけCloudFormationなどIaCを利用して手作業を減らすことが有効かもしれません。また、日頃からGuardDutyなど設定しておき、万一何かあった際にはすぐに気づいてリカバーできる体制をつくることも重要と思われます。
【初心者向け】AWSの脅威検知サービスAmazon GuardDutyのよく分かる解説と情報まとめ | DevelopersIO