[レポート]クロスアカウントのCI/CDパイプラインを自動化 #DOP402 #reinvent

こんにちは、おんづか（@onzuka_muscle）です。

re:Invent2021からだいぶ空きましたがセッションレポートです。

YouTubeで動画が公開されてますので本レポートで概要把握された方はこちらもぜひ！

セッション概要

Automating cross-account CI/CD pipelines

DESCRIPTION

When building a deployment strategy for your applications, using a multi-account approach is a recommended best practice. This limits the area of impact for changes made and results in better modularity, security, and governance. In this session, dive deep into an example multi-account deployment using infrastructure-as-code (IaC) services such as the AWS CDK, AWS CodePipeline, and AWS CloudFormation. Also explore a real-world customer use case that is deploying at scale across hundreds of AWS accounts.

アプリケーションのデプロイメント戦略を構築する際には、マルチアカウントのアプローチを使用することが推奨されるベストプラクティスです。これにより、変更の影響範囲が限定され、モジュール性、セキュリティ、ガバナンスの向上につながります。このセッションでは、AWS CDK、AWS CodePipeline、AWS CloudFormationなどのInfrastructure-as-Code（IaC）サービスを使用したマルチアカウント展開の例を深く掘り下げます。また、何百ものAWSアカウントで大規模なデプロイを行っているお客様の実際のユースケースをご紹介します。

SPEAKERS

Matteo Rinaudo Natalie White

SESSION LEVEL

400 - Expert

アジェンダ

• DevOpsの考え方と変革について
• マルチアカウント戦略における重要な考慮事項について
• クロスアカウントCI CDパイプラインの自動化と、それを成功させるために必要なすべてのステップをライブデモで紹介（本レポートでは割愛）
• アプリケーション開発以外の領域で、クロスアカウントCI CDパイプラインを大規模に行うことについて

DevOps transformation

それぞれの段階には目的があり、メリットとデメリットがあります。

• （左）AWSマネジメントコンソールやAWS CLIは、サービスの使い始めは便利で細かい設定を覚えるのにも良い
  • しかし、手動で行うためエラーが起こりやすく使いづらいし、何度も繰り返すとなると時間がかかる
• （真ん中）CloudFormationであれCDKであれ、リソースとアプリケーションをプログラム的に繰り返しデプロイできるようになれば、インフラとアプリケーションのデプロイにまつわるプロセスをtransformationする素晴らしい方法となる
  • 1つのアカウントにすべてをデプロイすることはとても簡単に実現できる
  • その場合、ロールの権限を細かく設定しないと1人のユーザーが全てのリソースにアクセスできてしまう
  • そのアカウントに複数のアプリケーション環境をデプロイしている場合、開発環境と本番環境と同じアクセス権を持つことになる
• （右）AWSアカウントで分離を実現するために、マルチアカウントのデプロイメントを使用することを開始する
  • 開発者は必要なものにアクセスできるようになり、開発者がデプロイすべきでないものをデプロイしないように保護することができる
• 新しいサービスや新しい機能、新しいアプリケーションを使い始めたら、またそのサイクルが始まる
• 本セッションでは、このマルチアカウント戦略（右）に焦点を当てている

Multi-account considerations

• Resource isolation
  • すべての異なるワークロードのために、個別のAWSアカウントを作成することを選択できる
• Area of impact
  • アカウントの停止やセキュリティ侵害が発生した場合について、影響の及ぶ範囲を軽減することができる
• Service limits
  • マルチアカウント戦略でない場合は、一つのアカウント内にある複数のワークロードそれぞれでサービス制限を気にする必要がある
• Workloads visibility
  • マルチアカウント戦略は、他のユーザーがアカウントにあるリソースを消費したり、発見したりするのを制限するという意味でワークロードの可視化に役立つ
• Data isolation
  • 監査用のアカウント、分析用のアカウント、といった目的をもって独立したアカウントを用意する
  • バックアップのようなシステムの復元が必要な場合に使用するデータを保存する独立したアカウントを用意する

Multi-account deployment flow

マルチキャスト戦略のソフトウェア開発ライフサイクルの側面について、以下の構成を一例として説明します。

• SDLCのアカウントレイアウトをデザイン（図の白枠）
  • どのようにコントロールプレーンを分離するか
  • コントロールプレーン（アプリケーションやワークロードをデプロイするための構成で、構築したメカニズムやプロセスなどを管理する）となるAWSアカウントを持つことを検討する（図のTooling account）
  • CI/CDのフェーズを経てアプリケーションがデプロイされ、必要なすべてのテストを実行（受け入れテスト、進行テスト、負荷テストなど）、顧客からフィードバックを得るためのアカウント（Pre-production account）
• アプリケーションを構築し、テストし、デプロイするプロセスや仕組みの構築
  • まずは各アカウントのIAMロール、つまりAWSのアイデンティティとアクセス管理
  • Tooling accountのIAMロールが、Pre-production accountやProduction accountのロールを引き受けて、必要なリソースをデプロイすることができるよう構成する
• IAMロールを記述する（図の左下）
  • AWS CloudFormationやAWS CDK
  • 通常、社内のセキュリティチームや開発者のチームがこのロールをプログラム的に記述する
• ソースコードリポジトリにはAWS CodeCommitを使っている、パイプラインオーケストレーションにはAWS CodePipelineを使用している（図の中央、図の左上）
  • 開発者は、継続的インテグレーションの観点から静的コード分析などを実行するために、AWS CodePipelineを設定する
  • パイプラインの各アカウントにどのようにロールを割り当てるか、パイプラインがソースコードリポジトリからコードを取り込みデプロイするフローを設定する
• データプレーン（=Pre-production accountやProduction account）について（図の右側）
  • フロントエンドにAmazon API Gateway、バックエンドにAWS lambdaを使用するとする
  • まず自分たちのマシンを使って、アプリケーションを構築し、テストし、ローカルにデプロイする
  • ローカルでCloudFormation Linterや（CloudFormationテンプレートをチェックするツール）、CloudFormation Guard（独自にルールを定義し、ポリシーへの適合性をチェックするツール）を使う
  • AWS CodeBuildを使うと、開発者が自分のマシンで行った上記のテストを実行できる
  • 開発者はTooling accountのソースコードリポジトリの特定のブランチにコントリビューションできる
  • リード開発者またはコントロールプレーンを管理しているチームがブランチの変更をその後のフローに乗せて良いか判断できるようにAWS CodePipelineを設定する

これはコントロールプレーン（=Tooling account）とデータプレーン（=Pre-production accountやProduction account）に複数のAWSアカウントを利用する方法についてのハイレベルなビジョンであり、あくまで一例です。

（この後にデモがありますが本ブログでは割愛します。YouTube見てください！）

Multi-account at scale

セキュリティ、管理、ガバナンスの観点で適切なガードレールを考える必要があります。

数百・数千のアカウントがあったとして、手動でガードレールを設定するのは厳しいので、先に見たようなアプリケーションであるかのようにガードレールの展開も扱いましょう。

• アカウントごとに必要なセキュリティ管理とガバナンスの制御を行い、思い通りに構成することが目標
• ライフサイクルの管理も必要、展開するリソースにはすべてライフサイクルがあるのでどのように大規模に行うかについても確認する
• 継続的デリバリプロセスを使用して、すべてのセキュリティコントロールを構築し、テストし、最終的にデプロイしすることを考える
  • 最初に必要なのはツールの選択、ここまで紹介したようにAWS CloudFormationやAWS CDKがある
  • コントロールプレーン（Parent organization tooling account）・データプレーン（Business unit accounts）で使うIAMロールをコードで記述し展開する
  • 今回データプレーンに展開したいのは組織内のすべてのアカウントで有効にしたいセキュリティコントロールになる
  • セキュリティコントロールの記述に取り組むチーム（図の左下）が展開する
  • ここでもCloudFormation LinterやCloudFormation Guardを利用したローカルでのテストを実行する
  • AWS CodePipelineはソースコードリポジトリから来るあらゆる変更をリスニングし、適用した設定に基づいてすべてのアカウントにデプロイする
  • セキュリティコントロールは、例えば、Security Hub、GuardDuty、Config Rules、Systems Manager

パイプラインの中を詳しく見てみましょう

• AWS CodePipeline
  • オーケストレーター
• AWS CodeCommit
  • 誰がいつ変更したのかを監査するために、すべての変更がコードで記述されている必要がある
• AWS CodeBuild
  • デプロイ先によって静的コード解析・コードチェックとしてのポリシーなど
• AWS CloudFormation
  • セキュリティコントロールの展開（Security Hub、GuardDuty、etc...）
• Lambda
  • 実行したいすべてのテストをコードで記述し、監査ログやセキュリティチームのメンバー全員に結果を提示する
    • ex）S3バケットのサーバー側の暗号化が有効になっているか
    • ex）S3バケットのバージョン管理が有効になっているか

次のフェーズでは、検証プロセスを実施します。

• パイプラインの実行を一時停止して、セキュリティチームのメンバーが、テスト結果をすべて確認する時間を持てるようにパイプラインに手動承認のステップを組み込む
  • すべての結果を受けて彼らは変更を承認するか拒否するかを選択する
  • 承認した場合、設定したパイプラインはすべてのアカウントにすべてのセキュリティコントロールを展開する

これで、セキュリティコントロールを構築し、テストし、展開するメカニズムができました。

• 組織内の誰もがセキュリティコントロールの全てのコードを参照でき、リポジトリにコントリビュートできるように権限が与えられる
  • これによってセキュリティチームは他の活動に使える時間が増え、更に人間による精査を置き換えるための機能の構築を進めることができる

おわり

『DevOps transformationは「人」「プロセス」そして「製品」に関わることである』という言葉でセッションは締められました。

皆様がクロスアカウントのCI/CDパイプラインを検討・構築される際に本レポートが少しでも参考になれば嬉しいです。

参考

公開されたリポジトリ