Open2021/07/30にコメント追加9

CDK Pipelinesの調査メモ

pirosikick 2021/07/30に更新

original APIとmodern APIがある
- original API: CdkPipelineコンストラクタ
- modern API: CodePipelineコンストラクタ
modern APIのほうが、デフォルトがいい感じ、拡張性に優れている、並列デプロイのサポート、複数のsynth inputsをサポート、CodeBuildをより制御できる
なるべくmodern APIに移行してね、とのこと
- マイグレーションガイド aws-cdk/ORIGINAL_API.md at master · aws/aws-cdk

At a glance

アプリのCDを開始するには、まずStageのサブクラスを作る
- コンストラクタ内でアプリケーションのStackをインスタンス化する
CodePipelineのインスタンスを作って、作りたい環境の分だけpipeline.addStage(stage)する
self-mutating
- StackやStageを書き換えると自身（Pipeline）を書き換えて、変更を反映する
- （そりゃそうやろと思ったが、self-mutatingみたいな名前つけるほどのことなのかよく理解できていない）

CDK Versioning

prereleaseの機能を使うので、以下の設定をcdk.jsonに追記する

{
  // ...
  "context": {
    "@aws-cdk/core:newStyleStackSynthesis": true
  }
}

Provisioning the pipeline

cdk deployの前に必ずgit commit & git pushすること
cdk deploy PipelineStack
- 1度目だけ管理者権限が必要。それ以降は不要なので、すぐ管理者権限を取り除いたほうがいい

Working on the pipeline

self-mutation機能はパイプライン開発の邪魔になることもあるので、selfMutation: falseでself-mutatingを無効化できるので、開発時に使ってね、とのこと。

Defining the pipeline

Synth and sources

CodePipelineコンストラクタは、synthパラメタを引数に取る
- cdk synth後のcdk.outディレクトリに吐かれるコンテンツを生成するためのもの
ShellStepコンストラクタ
- commandsに出力するためのコマンドを配列で書く
- cdkのディレクトリがリポジトリの直下にない場合は、commandsでcd ディレクトリしつつ、primaryOutputDirectoryにcdk.outのパスを別途指定する

CodePipeline Sources

ソースの置き場所を指定。CodePipelineクラスのファクトリメソッドを使う

// connectionを使う例（推奨）
// AWSコンソールで認証する
CodePipelineSource.connection('org/repo', 'branch', {
  connectionArn: 'arn:aws:codestar-connections:us-east-1:222222222222:connection/7d2469ff-514a-4e4f-9003-5ca4a43cdc41',
});

// Githubで発行したトークンを使う
// トークンはrepo, admin:repo_hookスコープを持っている必要がある
CodePipelineSource.gitHub('org/repo', 'branch', {
  // This is optional
  authentication: SecretValue.secretsManager('my-token'),
});

Additional inputs

additionalInputsに追加の入力を指定できる
- ShellStep or CodePipelineSource
（CDKのコードと、アプリケーションのコードを分離する、みたいなことができちゃう感じ？）

CDK application deployments

Stageの追加
- Stage: ターゲットとなる環境にデプロイされる対象
pipeline.addState(Stage)で追加できる

// Do this as many times as necessary with any account and region
// Account and region may different from the pipeline's.
pipeline.addStage(new MyApplicationStage(this, 'Prod', {
  env: {
    account: '123456789012',
    region: 'eu-west-1',
  }
}));

デプロイ先環境が別アカウントの場合、そのアカウントのbootstrapが事前に必要

Deploying in parallel

デフォルトでは各Stageは直列にデプロイされる
並列でデプロイしたい場合は、addWaveを使う

const europeWave = pipeline.addWave('Europe');
europeWave.addStage(new MyApplicationStage(this, 'Ireland', {
  env: { region: 'eu-west-1' }
}));
europeWave.addStage(new MyApplicationStage(this, 'Germany', {
  env: { region: 'eu-central-1' }
}));

Deploying to other accounts / encrypting the Artifact Bucket

別リージョン・アカウントへの透過的に実行するけど、CodePipelineコンストラクタにcrossAccountKeys: trueを付ける必要がある
- artifact bucketの暗号化を有効にする設定
（鍵の生成等は勝手にやってくれる感じ？）

Validation

addStage, addWaveのpre, postオプション
- stage, waveの前後で任意のアクションを実行できる
Validationを追加するのに使うといい
ManualApprovalStepをpreに置くことで、手動による承認ステップを挟むことができる

Using CloudFormation Stack Outputs in approvals

CloudFormation Stackの出力を承認時に利用可能
ShellStepのenvFromCfnOutputsで指定できる

class MyApplicationStage extends Stage {
  public readonly loadBalancerAddress: CfnOutput;
  // ...
}

const lbApp = new MyApplicationStage(this, 'MyApp', { /* ... */ });
pipeline.addStage(lbApp, {
  post: [
    new ShellStep('HitEndpoint', {
      envFromCfnOutputs: {
        // Make the load balancer address available as $URL inside the commands
        URL: lbApp.loadBalancerAddress,
      },
      commands: ['curl -Ssf $URL'],
    });
  ],
});

Running scripts compiled during the synth step

synthの出力をstageのpre/postで使う方法について
synthの出力だけじゃなくて、他のビルドステップの出力を利用できる

const synth = new ShellStep('Synth', { /* ... */ });
const pipeline = new CodePipeline(this, 'Pipeline', { synth });

pipeline.addStage(/* ... */, {
  post: [
    new ShellStep('Approve', {
      // Use the contents of the 'integ' directory from the synth step as the input
      input: synth.addOutputDirectory('integ'),
      commands: ['cd integ && ./run.sh'],
    }),
  ],
});

ちょっと長くなったので、この後は分割して投稿する

pirosikick 2021/07/30

Customizing CodeBuild Projects

CDK pipelinesはShellStepごとにCodeBuildのプロジェクトを生成している
CdeBuildStepコンストラクタを使えば、より細かく設定できる
また、CodePipeineのcodeBuildDefaultsにCodeBuildのデフォルト値を設定できる

pirosikick 2021/07/30

Arbitrary CodePipeline actions

Stepを継承、ICodePipelineActionFactoryを実装すれば、独自のCodePipelineアクションを定義できる

pirosikick 2021/07/30

Using Docker in the pipeline

TODO

pirosikick 2021/07/30

CDK Environment Bootstrapping

environment（環境） = account + region
最低2つの環境: Pipelineがプロビジョンされる環境、アプリケーションがデプロイされる環境
- 2つの環境が同一ということもある
- 分けるのが推奨
環境は、bootstrapが必要
2つの環境が別の場合、両方にbootstrapが必要 & trust releationshipの追加が必要
CDK PipelineはクロスアカウントのCI/CDに対応しているモダンなbootstrapが必要
- cdk.jsonに"@aws-cdk/core:newStyleStackSynthesis": trueがあり、cdk.jsonと同一ディレクトリでcdk bootstrapする場合は、自動的にモダンなものにスイッチする
- そうでない場合、CDK_NEW_BOOTSTRAP=1をつけて、cdk bootstrapする

# アカウント = 111111111111, region = us-east-1のbootstrap
$ env CDK_NEW_BOOTSTRAP=1 npx cdk bootstrap \
    [--profile admin-profile-1] \
    --cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess \
    aws://111111111111/us-east-1

アプリケーションのデプロイ先の別の環境をbootstrapする場合、--trustにPipelineのアカウントを指定

# アカウント = 222222222222, region = us-east-1のbootstrap
# アカウント = 111111111111のPipelineからデプロイするので--trust 111111111111を付けている
$ env CDK_NEW_BOOTSTRAP=1 npx cdk bootstrap \
    [--profile admin-profile-2] \
    --cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess \
    --trust 11111111111 \
    aws://222222222222/us-east-2

Vpc.fromLookup()等のlookupしたい場合は、--trust-for-lookup Pipelineのアカウントを付ける

$ env CDK_NEW_BOOTSTRAP=1 npx cdk bootstrap \
    [--profile admin-profile-2] \
    --cloudformation-execution-policies arn:aws:iam::aws:policy/AdministratorAccess \
    --trust-for-lookup 11111111111 \
    aws://222222222222/us-east-2

--trust付ける場合、Pipeline側のアカウントはデプロイ先のアカウントに対して--cloudformation-execution-policiesで指定した権限を持つことになるので、注意
管理者権限はbootstrap時、最初のPipelineのデプロイ時だけ使用して、あとは使わない
AdministratorAccessの利用について
- PipelineのAdministratorAccessはすべてのAWSリソースをデプロイ可能にするために付けている
- CDKのコード全てが信頼できる状態じゃないと、変なリソースをデプロイされたりするので、依存関係はちゃんと管理する。また、適切なポリシーでAdministratorAccessを利用する
- CDK実行ロールにパーミッションバウンダリーを実装すること

pirosikick 2021/07/30

[新機能]IAMの委譲権限を制限可能なPermissions Boundaryが登場したので試してみた | DevelopersIO

TODO

pirosikick 2021/07/30

Context Lookups

有効なAZの数、Route53 Hosted Zone IDなど、cdk synth時に自動で調べる
cdk bootstrap --trust-for-lookup=<account>

pirosikick 2021/07/30

Security Considerations

Confirm permissions broadening

stageのデプロイ前にcdk diffで新たにIAM権限の付与等が行われていないか確認したい
ConfirmPermissionsBroadeningをstageのpreに挟む
- cdk diffの結果、何も無ければ自動でOK
- なにかあれば、マニュアルの承認が必要

const stage = new MyApplicationStage(this, 'MyApplication');
pipeline.addStage(stage, {
  pre: [
    new ConfirmPermissionsBroadening('Check', { stage }),
  ],
});

SNSトピックを付けることもできる

import * as sns from '@aws-cdk/aws-sns';
import * as subscriptions from '@aws-cdk/aws-sns-subscriptions';
import * as pipelines from '@aws-cdk/pipelines';

const topic = new sns.Topic(this, 'SecurityChangesTopic');
topic.addSubscription(new subscriptions.EmailSubscription('test@email.com'));

const stage = new MyApplicationStage(this, 'MyApplication');
pipeline.addStage(stage, {
  pre: [
    new ConfirmPermissionsBroadening('Check', {
      stage,
      notificationTopic: topic,
    }),
  ],
});

pirosikick 2021/07/30

ここまでの疑問点

--trustを付けた場合の適切な--cloudformation-execution-policiesのポリシーはなに？
- 結局管理者権限にならない？それかPowerUserみたいなやつをつければいいのかな？
Permission Boundaryってなに？