cdk bootstrapは実行端末じゃなく認証情報のアカウントで決まる

  • AWS
  • CDK
  • Infrastructure

この記事は、構成と文章の整理にAIを使っています。
あくまで読みやすくするための補助で、内容そのものをAIにすべて任せて書いているわけではありませんが、ところどころ相談しながら整えています。

CDK Pipelinesでクロスアカウントデプロイをやるとき、「bootstrapってどこから実行すればいいんだっけ」って毎回ちょっと迷う。答えは単純で、実行する端末やログイン先のアカウントは関係なくて、その時の認証情報がどのアカウントの権限を持っているかだけが問題になる。

bootstrapの本質

cdk bootstrapは対象アカウント/リージョンにCDKToolkitというCloudFormationスタックを作るだけの処理。中身はアセット用のS3バケット、Dockerイメージ用のECRリポジトリ、デプロイ用のIAMロールあたり。アカウント/リージョンの組み合わせごとに一回やればいい。

なので、パイプラインアカウントの端末からでも、プロファイルを切り替えてアプリケーションアカウントの認証情報でコマンドを叩けば、それは「アプリケーションアカウント側でbootstrapを実行した」ことになる。

やり方は2通り。

プロファイル切り替え

ターミナル
aws sts get-caller-identity --profile app-dev


cdk bootstrap aws://<APP_ACCOUNT_ID>/ap-northeast-1 \
  --trust <PIPELINE_ACCOUNT_ID> \
  --trust-for-lookup <PIPELINE_ACCOUNT_ID> \
  --cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess \
  --profile app-dev

AssumeRoleしてから実行

ターミナル
aws sts assume-role \
  --role-arn arn:aws:iam::<APP_ACCOUNT_ID>:role/OrganizationAccountAccessRole \
  --role-session-name cdk-bootstrap


# 取得した一時クレデンシャルを環境変数にセットしてから
cdk bootstrap aws://<APP_ACCOUNT_ID>/ap-northeast-1 \
  --trust <PIPELINE_ACCOUNT_ID> \
  --trust-for-lookup <PIPELINE_ACCOUNT_ID> \
  --cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess

結果としてアプリケーションアカウントの権限で実行できていれば、どちらでもいい。

--trustと--trust-for-lookupの違い

--trustはデプロイ先(アプリ側)アカウントのbootstrapコマンドに付与して、パイプラインアカウントIDを指定する。これで「パイプラインアカウントのCDKロールが、このアカウント内のPublishing/Deployment用ロールをAssumeしてよい」という信頼関係ができる。

--trust-for-lookupはそれより権限が絞られたオプションで、既存VPCやAZ情報のようなコンテキストルックアップ専用の信頼設定。デプロイ権限までは渡さない。

flowchart LR
    A[パイプラインアカウント] -- AssumeRole --> B[アプリアカウント: Publishing/Deployment Role]
    A -- AssumeRole 制限付き --> C[アプリアカウント: Lookup Role]
    B --> D[CDKデプロイ実行]
    C --> E[VPC/AZ情報などの参照のみ]

相互にtrustを設定する必要はない。あくまでアプリ側が「このパイプラインアカウントを信頼する」という片方向の設定。

ただしこれだけでは足りなくて、パイプライン側でもPipelineロールに対して、各ターゲットアカウントのロールをsts:AssumeRoleできるIAMポリシーを別途アタッチする必要がある。ここが抜けていると、bootstrap自体は成功してもデプロイ時にAssumeRoleでコケる。

CDK v2はモダンシンセサイザーがデフォルトになっているので、feature flagやバージョン制約は気にしなくていい。cdk bootstrapをそのまま実行すれば--trustも--trust-for-lookupも普通に使える。

再実行と権限まわりの注意

既にbootstrap済みの環境に対してもう一回cdk bootstrapを実行するのは基本的に安全で、CDKToolkitスタックへの追記・更新になる。存在確認は

ターミナル
aws cloudformation describe-stacks --stack-name CDKToolkit --region ap-northeast-1 --profile app-dev

で見れる。

ただし、既存の--trust設定に別のアカウントを追加するような再bootstrapの場合、実行者にiam:UpdateAssumeRolePolicyDocument権限がないと失敗することがあるらしい。permissions boundaryなどでIAM操作が制限されている環境では実機で確認したほうがいい(自分の環境ではまだ踏んでいない)。

実行ポリシーはAdministratorAccessのままでいいのか

サンプルコードは大体--cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccessで書かれてるけど、これはdev/stagingで動作確認するぶんには手軽。本番環境ではアカウント固有の絞ったカスタムポリシー(例: arn:aws:iam::<ACCOUNT_ID>:policy/ProdDeploymentPolicy)に差し替えている例もある。最初はAdministratorAccessで動かして、本番だけ絞る、というのが現実的そう。