CodeBuildのビルド内でAssumeRole(クロスアカウントアクセス)する方法とハマった話

CodeBuildからAssumeRoleする方法はズバリこれだ！ってエントリがなかった気がするので書きました。今更感がありますがご了承ください。また、CodePipelineで少しハマったので共有目的で本エントリを書きました。

佐伯航

2019.09.18

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、佐伯です。

CodeBuildのビルド内からAssumeRoleする方法

ビルド内からAssumeRoleするための設定に焦点を置いています。その他もろもろの設定は省いていますのでその点ご注意ください。

AWSアカウントの定義

AWSアカウントは便宜上以下のような名称として定義しておきます。

AWSアカウント名	AWSアカウントID	備考
account-a	XXXXXXXX4623	account-bからAssumeRoleされるAWSアカウント
account-b	XXXXXXXX6985	account-aにAssumeRoleするAWSアカウント

account-a:IAMロールの作成

IAMロールの信頼関係にaccount-bを信頼するポリシーを設定します。設定するプリンシパルはAWSアカウントを信頼する or CodeBuildサービスロールを信頼するどちらの書き方でも動作します。

AWSアカウントを信頼する場合

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::XXXXXXXX6985:root"
        }
    }
}

IAMロールを信頼する場合

{
    "Version": "2012-10-17",
    "Statement": {
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:aws:iam::XXXXXXXX6985:role/<IAMロール名>"
        }
    }
}

IAMポリシーの権限はCodeBuildのビルド内容次第ですので省略しています。

account-b:CodeBuildサービスロールへIAMポリシーを追加

ビルド内でAssumeRoleを実行するにはIAMアクション sts:AssumeRole を許可する必要があるので、以下のIAMポリシーをインラインポリシーで追加、またはユーザー管理ポリシーを作成してCodeBuildサービスロールにアタッチします。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": "*"
        }
    ]
}

こちらもその他のIAMポリシーの権限はCodeBuildのビルド内容次第ですので省略しています。

account-b:buildspec.ymlの作成

AWS CLIのプロファイルを使用したAssumeRole

以下のようなbuildspec.ymlを作成します。内容を補足するとpre_buildフェーズでAWS CLI設定ファイルを作成、作成した設定ファイルを環境変数AWS_CONFIG_FILEに設定しています。${ASSUME_ROLE_ARN}はビルドプロジェクトの環境変数として設定しています。

version: 0.2

phases:
  install:
    runtime-versions:
      python: 3.7
  pre_build:
    commands:
      - echo "[profile account-b]" > .awscli-config
      - echo "role_arn = ${ASSUME_ROLE_ARN}" >> .awscli-config
      - echo "credential_source = EcsContainer" >> .awscli-config
      - export AWS_CONFIG_FILE=${CODEBUILD_SRC_DIR}/.awscli-config
  build:
    commands:
      - aws sts get-caller-identity
      - aws sts get-caller-identity --profile account-b

なお、.awscli-configは適当に決めた名前なのでなんでもいいですし、pre_buildフェーズで作成せず、ソース(GitHubなど)でファイルとして管理する形でも問題ありません。ランタイムは指定が必須なのでPython 3.7を選択してます。

以下はpre_buildフェーズ以降の実行結果抜粋です。aws sts get-caller-identityの実行結果でアカウントIDが変わっているのが確認できるかと思います。

[Container] 2019/09/18 09:45:20 Entering phase PRE_BUILD
[Container] 2019/09/18 09:45:20 Running command echo "[profile account-b]" > .awscli-config

[Container] 2019/09/18 09:45:20 Running command echo "role_arn = ${ASSUME_ROLE_ARN}" >> .awscli-config

[Container] 2019/09/18 09:45:20 Running command echo "credential_source = EcsContainer" >> .awscli-config

[Container] 2019/09/18 09:45:20 Running command export AWS_CONFIG_FILE=${CODEBUILD_SRC_DIR}/.awscli-config

[Container] 2019/09/18 09:45:20 Phase complete: PRE_BUILD State: SUCCEEDED
[Container] 2019/09/18 09:45:20 Phase context status code:  Message:
[Container] 2019/09/18 09:45:20 Entering phase BUILD
[Container] 2019/09/18 09:45:20 Running command aws sts get-caller-identity
{
    "UserId": "AROA27MEXAMPLEEXAMPLE:AWSCodeBuild-66809dcf-7dc1-4c9f-baab-1d028example",
    "Account": "XXXXXXXX4623",
    "Arn": "arn:aws:sts::XXXXXXXX4623:assumed-role/codebuild-service-role/AWSCodeBuild-66809dcf-7dc1-4c9f-baab-1d028example"
}

[Container] 2019/09/18 09:45:22 Running command aws sts get-caller-identity --profile account-b
{
    "UserId": "AROAYRMEXAMPLEEXAMPLE:botocore-session-1568799923",
    "Account": "XXXXXXXX6985",
    "Arn": "arn:aws:sts::XXXXXXXX6985:assumed-role/assume-role-from-codebuild/botocore-session-1568799923"
}

[Container] 2019/09/18 09:45:24 Phase complete: BUILD State: SUCCEEDED

環境変数による設定

ツールによってはAWS CLIのプロファイル指定をサポートしていない場合もあるかもしれないので、aws sts assume-roleコマンドから一時クレデンシャルを取得して環境変数にセットする方法についても記載します。jqなどを使用して取得した一時クレデンシャルを環境変数に設定しています。

version: 0.2

phases:
  install:
    runtime-versions:
      python: 3.7
  pre_build:
    commands:
      - aws sts get-caller-identity
  build:
    commands:
      - credentials=$(aws sts assume-role --role-arn ${ASSUME_ROLE_ARN} --role-session-name "RoleSessionFromCodeBuild" | jq .Credentials)
      - export AWS_ACCESS_KEY_ID=$(echo ${credentials} | jq -r .AccessKeyId)
      - export AWS_SECRET_ACCESS_KEY=$(echo ${credentials} | jq -r .SecretAccessKey)
      - export AWS_SESSION_TOKEN=$(echo ${credentials} | jq -r .SessionToken)
      - aws sts get-caller-identity

以下はpre_buildフェーズ以降の実行結果抜粋です。

[Container] 2019/09/18 09:40:04 Entering phase PRE_BUILD
[Container] 2019/09/18 09:40:04 Running command aws sts get-caller-identity
{
    "UserId": "AROA27MEXAMPLEEXAMPLE:AWSCodeBuild-cad340c8-820f-4de9-a5bb-f75feexample",
    "Account": "XXXXXXXX4623",
    "Arn": "arn:aws:sts::XXXXXXXX4623:assumed-role/codebuild-service-role/AWSCodeBuild-cad340c8-820f-4de9-a5bb-f75feexample"
}

[Container] 2019/09/18 09:40:07 Phase complete: PRE_BUILD State: SUCCEEDED
[Container] 2019/09/18 09:40:07 Phase context status code:  Message:
[Container] 2019/09/18 09:40:07 Entering phase BUILD
[Container] 2019/09/18 09:40:07 Running command credentials=$(aws sts assume-role --role-arn ${ASSUME_ROLE_ARN} --role-session-name "RoleSessionFromCodeBuild" | jq .Credentials)

[Container] 2019/09/18 09:40:08 Running command export AWS_ACCESS_KEY_ID=$(echo ${credentials} | jq -r .AccessKeyId)

[Container] 2019/09/18 09:40:08 Running command export AWS_SECRET_ACCESS_KEY=$(echo ${credentials} | jq -r .SecretAccessKey)

[Container] 2019/09/18 09:40:08 Running command export AWS_SESSION_TOKEN=$(echo ${credentials} | jq -r .SessionToken)

[Container] 2019/09/18 09:40:08 Running command aws sts get-caller-identity
{
    "UserId": "AROAYRMEXAMPLEEXAMPLE:RoleSessionFromCodeBuild",
    "Account": "XXXXXXXX6985",
    "Arn": "arn:aws:sts::XXXXXXXX6985:assumed-role/assume-role-from-codebuild/RoleSessionFromCodeBuild"
}

[Container] 2019/09/18 09:40:09 Phase complete: BUILD State: SUCCEEDED

ハマった話

他のAWSアカウントのECRへイメージをPUSH→CodePipelineの開始を実現したくて以下の設定を行いました。

ECRリポジトリはリポジトリポリシーで他AWSアカウントからのPUSHを許可
- Amazon ECR リポジトリポリシーの例
CloudWatch EventsルールはAWSドキュメントの通りに作成

しかし、CodeBuild内でdocker pushコマンドでECRへのイメージPUSHは問題なく実行できるが、CodePipelineが開始されない事象が発生しました。

ECR PUSHトリガーでCodePipelineが開始される仕組み

CodePipelineはSourceにECRを指定し、リポジトリに指定したタグが付与されたイメージがPUSHされるとパイプラインを開始する、といった設定が可能です。この仕組みはCloudWatch Eventsで実現されています。

CloudWatch イベントを使用してパイプラインを開始する (Amazon ECR ソース)

ECRのイベント

ECRのイベントはCloudWatch Eventsではサポートされておらず、CloudTrail 経由で配信されたイベントとなります。

なぜCloudWatch Eventsがトリガーされないのか

実際に自AWSアカウントからECRへPUSHした場合と他AWSアカウントからECRへPUSHした場合で何が変わるのかCloudTrailから確認しました。結論から言ってしまうと 2019/09/18時点では他AWSアカウントからECRへPUSHした際はCloudTrail経由でもイベントが配信されず、CloudWatch Eventsルールのトリガーとして設定できない というのが答えのようです。通りで動かないはずだ...。

自AWSアカウントからECRへPUSHした際のCloudTrailログ

detail-typeなどのフィールドが存在しており、CloudWatch Eventsのイベントフォーマットになっています。

CloudWatch イベントのイベントパターン

{
    "version": "0",
    "id": "432cea0a-d3bd-6dd9-b351-07ac1example",
    "detail-type": "AWS API Call via CloudTrail",
    "source": "aws.ecr",
    "account": "XXXXXXXX4623",
    "time": "2019-09-17T13:10:10Z",
    "region": "ap-northeast-1",
    "resources": [],
    "detail": {
        "eventVersion": "1.05",
        "userIdentity": {
            "type": "AssumedRole",
            "principalId": "AROAIBLEXAMPLEEXAMPLE:1568725740989028000",
            "arn": "arn:aws:sts::XXXXXXXX4623:assumed-role/saiki.ko/1568725740989028000",
            "accountId": "XXXXXXXX4623",
            "accessKeyId": "ASIAI3EXAMPLEEXAMPLE",
            "sessionContext": {
                "sessionIssuer": {
                    "type": "Role",
                    "principalId": "AROAIBLEXAMPLEEXAMPLE",
                    "arn": "arn:aws:iam::XXXXXXXX4623:role/saiki.ko",
                    "accountId": "XXXXXXXX4623",
                    "userName": "saiki.ko"
                },
                "webIdFederationData": {},
                "attributes": {
                    "mfaAuthenticated": "false",
                    "creationDate": "2019-09-17T13:09:02Z"
                }
            },
            "invokedBy": "AWS Internal"
        },
        "eventTime": "2019-09-17T13:10:10Z",
        "eventSource": "ecr.amazonaws.com",
        "eventName": "PutImage",
        "awsRegion": "ap-northeast-1",
        "sourceIPAddress": "AWS Internal",
        "userAgent": "AWS Internal",
        "requestParameters": {
            "repositoryName": "example",
            "imageTag": "latest",
            "registryId": "XXXXXXXX4623",
            "imageManifest": "<長い一行のJSONなので省略>"
        },
        "responseElements": {
            "image": {
                "repositoryName": "example",
                "imageManifest": "<長い一行のJSONなので省略>",
                "registryId": "XXXXXXXX4623",
                "imageId": {
                    "imageDigest": "sha256:55e7a6f2bb43e38cc34285af03b4973d61f523d26cd8a57e9dexampleexample",
                    "imageTag": "latest"
                }
            }
        },
        "requestID": "313be446-508c-4c85-b4b4-8a1d3example",
        "eventID": "27556aba-1342-43bb-85bb-f17e2example",
        "resources": [
            {
                "accountId": "XXXXXXXX4623",
                "ARN": "arn:aws:ecr:ap-northeast-1:XXXXXXXX4623:repository/example"
            }
        ],
        "eventType": "AwsApiCall"
    }
}

他AWSアカウントからECRへPUSHした際のCloudTrailログ

必須となる各フィールドが存在しておらず、単なるCloudTrailログが出力されるようです。

{
    "eventVersion": "1.05",
    "userIdentity": {
        "type": "AWSAccount",
        "principalId": "AIDAI6UEXAMPLEEXAMPLE",
        "accountId": "XXXXXXXX6985"
    },
    "eventTime": "2019-09-17T14:57:56Z",
    "eventSource": "ecr.amazonaws.com",
    "eventName": "PutImage",
    "awsRegion": "ap-northeast-1",
    "sourceIPAddress": "AWS Internal",
    "userAgent": "AWS Internal",
    "requestParameters": {
        "repositoryName": "example",
        "imageTag": "latest",
        "registryId": "XXXXXXXX4623",
        "imageManifest": "<長い一行のJSONなので省略>"
    },
    "responseElements": {
        "image": {
            "repositoryName": "example",
            "imageManifest": "<長い一行のJSONなので省略>",
            "registryId": "XXXXXXXX4623",
            "imageId": {
                "imageDigest": "sha256:acd3ca9941a85e8ed16515bfc5328e4e2f8c128caa72959a58a127b7801ee01f",
                "imageTag": "latest"
            }
        }
    },
    "requestID": "06dbd894-f139-40ae-a6b1-72979example",
    "eventID": "9197e795-b1c5-4ca3-a793-011b1example",
    "resources": [
        {
            "accountId": "XXXXXXXX4623",
            "ARN": "arn:aws:ecr:ap-northeast-1:XXXXXXXX4623:repository/example"
        }
    ],
    "eventType": "AwsApiCall",
    "recipientAccountId": "XXXXXXXX4623",
    "sharedEventID": "6f71b837-5700-491c-b87d-64422example"
}

ワークアラウンド

他AWSアカウントから直接ECRへイメージをPUSHするのではなく、前述のCodeBuildのビルド内から対象のAWSアカウントへAssumeRoleした上でECRへイメージをPUSHすることでイベントが配信されます。これでCodePipelineが開始されます。

まとめ

AssumeRoleの方法よりはハマりポイントについて共有する目的で書きました!

なぜ動かないのか色々試した結果、素直にCloudTrailのログを見ることで原因究明の糸口になりました。今回はCloudWatch Eventsがなぜトリガーされないのかを調べましたが、デバッグ方法が限られる、且つAWSサービス同士を連携するようなサービスでハマった場合、まずはCloudTrailのログを確認してみるのがいいかもしれません。

どなたかの参考になれば幸いです。

CodeBuildのビルド内でAssumeRole(クロスアカウントアクセス)する方法とハマった話

CodeBuildのビルド内からAssumeRoleする方法

AWSアカウントの定義

account-a:IAMロールの作成

account-b:CodeBuildサービスロールへIAMポリシーを追加

account-b:buildspec.ymlの作成

AWS CLIのプロファイルを使用したAssumeRole

環境変数による設定

ハマった話

ECR PUSHトリガーでCodePipelineが開始される仕組み

ECRのイベント

なぜCloudWatch Eventsがトリガーされないのか

自AWSアカウントからECRへPUSHした際のCloudTrailログ

他AWSアカウントからECRへPUSHした際のCloudTrailログ

ワークアラウンド

まとめ

イベント

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【4/18リモート】クラスメソッドのフリーランスエンジニア会社説明会〜AWS/システムアーキテクト/Android案件特集〜を開催します

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！

EVENT【4/19（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【4/25（木）リモート】Google Cloudに携わるエンジニアのキャリア～クラスメソッド会社説明会～

EVENT【4/30（火）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/9（木）】組織的なクラウド統制はじめの一歩

EVENT【4/24（水）リモート】会社員からフリーランスエンジニアへ、変化の時の体験談 [パネルトーク] フリーランストーク#10

CodeBuildのビルド内でAssumeRole(クロスアカウントアクセス)する方法とハマった話

CodeBuildのビルド内からAssumeRoleする方法

AWSアカウントの定義

account-a:IAMロールの作成

account-b:CodeBuildサービスロールへIAMポリシーを追加

account-b:buildspec.ymlの作成

AWS CLIのプロファイルを使用したAssumeRole

環境変数による設定

ハマった話

ECR PUSHトリガーでCodePipelineが開始される仕組み

ECRのイベント

なぜCloudWatch Eventsがトリガーされないのか

自AWSアカウントからECRへPUSHした際のCloudTrailログ

他AWSアカウントからECRへPUSHした際のCloudTrailログ

ワークアラウンド

まとめ

イベント

EVENT【5/14（火）】アノテーションの中途向けオンライン会社説明会を開催します

EVENT【5/23（木）】ユースケースに学ぶAWS運用のノウハウ～可視化から統制まで～

EVENT【5/16（木）】Snowflakeを触ってみよう！初めての方向けハンズオンセミナー

EVENT【4/18リモート】クラスメソッドのフリーランスエンジニア会社説明会 〜AWS/システムアーキテクト/Android案件特集〜 を開催します

EVENT【5/10（金） 名古屋】クラスメソッドグループの会社説明会を開催します！

EVENT【4/19（金）】認証機能の開発工数削減をデモで体験！次世代認証基盤サービス『Auth0 by Okta』導入実践ウェビナー

EVENT【4/25（木）リモート】Google Cloudに携わるエンジニアのキャリア～クラスメソッド会社説明会～

EVENT【4/30（火）リモート】クラスメソッドの会社説明会を開催します

EVENT【5/9（木）】組織的なクラウド統制 はじめの一歩

EVENT【4/24（水）リモート】会社員からフリーランスエンジニアへ、変化の時の体験談 [パネルトーク] フリーランストーク#10

関連記事

[小ネタ]CloudWatch Agent で Agent 自身のプロセス監視を行なう

LambdaからCloudWatchに自動で送信されるメトリクスを使ってアラームの作成を試してみた

Glueの実行時間が指定した値を超えた場合に通知を受け取る方法

Amazon WorkspacesへのCloudWatchエージェントの利用およびWorkspacesイメージ作成時の注意点

EVENT【4/18リモート】クラスメソッドのフリーランスエンジニア会社説明会〜AWS/システムアーキテクト/Android案件特集〜を開催します

EVENT【5/10（金）名古屋】クラスメソッドグループの会社説明会を開催します！

EVENT【5/9（木）】組織的なクラウド統制はじめの一歩