[要注意]GitHub Actions OIDC+AWS IAMロールで”token.actions.githubusercontent.com:sub”条件を書き忘れてはいけない

2022.01.04

あけましておめでとうございます。広島の吉川です。

[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に取り込まれたこともあり現在はこちらが推奨であると思われます。

人間が作業する以上(本件に限らず)すべてにおいて設定ミスの可能性をゼロにはできません。例えば、リソースの操作はできるだけCloudFormationなどIaCを利用して手作業を減らすことが有効かもしれません。また、日頃からGuardDutyなど設定しておき、万一何かあった際にはすぐに気づいてリカバーできる体制をつくることも重要と思われます。

【初心者向け】AWSの脅威検知サービスAmazon GuardDutyのよく分かる解説と情報まとめ | DevelopersIO