AWS Cloud9を共有してデプロイ環境を構築する

結論

• チーム内で共有したCloud9でCDKをデプロイすることで環境の管理コストが削減出来る
• CDKをデプロイしたユーザーの証跡を残せるが、複数ユーザーが同時に同じCloud9を操作しているとCDKを実行したユーザーが識別出来ない可能性がある

はじめに

こんにちは。次世代システム研究室のT.Tです。

現在開発運用に携わっているサービスのシステム基盤のAWSへの移行を検証しています。AWS環境の構築にはCDKを利用していて、今回はデプロイ環境を管理する検証を進めました。

本記事では、AWS環境で一つのCloud9環境をデプロイ担当者のユーザーで共有することで、デプロイ環境の管理を効率化するために検証した内容についてご紹介します。

1.前提

AWSに以下の設定が完了している前提となっています。

1. AWS Control Towerによりマルチアカウント環境を構築している
2. IAM Identity Centerによりユーザーを一元管理している

2.デプロイ環境

2.1.運用中のデプロイ環境

運用中のサービスが稼働している環境では、サーバー構成をデプロイする際にVPN経由で各環境のCIサーバーにsshでログインし、その後共通のデプロイ用のユーザーに切り替えてデプロイコマンドを実行してデプロイしています。この構成のメリットとデメリットは以下のようになります。

メリット

• デプロイ環境を一元管理出来る
• デプロイを実行出来るユーザーを簡単に追加出来る
• デプロイ環境の初期構築のコストが比較的低い

デメリット

• どのユーザーでデプロイを実行したかの証跡が残らない
• VPNとsshが必要
• CIサーバーのコストが常に発生する

2.2.検証するデプロイ環境

検証する環境は以下の構成になります。

検証するデプロイ環境

• 各環境にデプロイ環境用のCloud9を一台構築する
• Cloud9にはSSMで接続する
• Cloud9をIdentity Centerのユーザーで共有する
• デプロイ(CDK)を実行する共通で利用するIdentity Centerのユーザーを各環境で個別に用意する

この構成のメリットとデメリットは以下のようになります。運用中のサービスと比較して、デプロイしたユーザーの操作の証跡が残る、VPNとsshが不要になる、デプロイ環境の維持コストが低いといったところがメリットになります。デプロイ環境の初期構築のコストが高いところがデメリットになります。

メリット

• デプロイ環境を一元管理出来る
• デプロイを実行出来るユーザーを簡単に追加出来る
• どのユーザーでデプロイを実行したかの証跡が残る
• VPNとsshが不要(SSMだけでデプロイ環境にログイン出来る)
• デプロイ環境の維持コストが低い(Cloud9を利用している時間しかコストが発生しない)

デメリット

• デプロイ環境の初期構築のコストが比較的高い

3.環境構築

Sandbox環境用のデプロイ環境を構築する内容で検証します。デプロイ環境の初期構築方法は以下の内容になります。ユーザー操作の証跡を残す設定はAWS Control Towerで実施済みの前提となります。

1. 共有するCloud9の作成
2. Sandboxでデプロイするユーザーの作成と権限設定
3. Cloud9の共有設定
4. CDKの設定

3.1.共有するCloud9の作成

AWS Organizationsの管理アカウントの管理者権限を持つユーザーで、管理アカウントにCloud9を作成します。ネットワーク設定の接続にはAWS Systems Manager (SSM)を選択します。

管理者権限を持つユーザーでCloud9を作成すると、このユーザーで共有設定をする場合等にCloud9にログインした際に、管理アカウントの管理者権限のCLIの認証トークンが自動で付与されて他のユーザーにも共有されてしまうので注意が必要です。この挙動を避けるためには権限を制限したユーザーでCloud9を作成する等の対策が必要です。以降の手順は管理者権限を持つユーザーでCloud9を作成した場合の手順になります。

3.2.Sandboxでデプロイするユーザーの作成と権限設定

以下の内容でIdentity Centerのユーザーの作成と権限設定を行います。Cloud9にログインしてデプロイ(CDK)を実行するユーザーがsandbox-user、CDKの実行で利用する共有のユーザーがsandbox-deployerです。環境メンバーのアクセスロールについての内容に従ってCloud9を共有するために必要な権限を設定します。

• sandbox-user
  • SandboxOperatorGroupという名前のグループを作成する
  • sandbox-userという名前のユーザーを作成し、SandboxOperatorGroupに追加する
  • SandboxOperatorという名前の許可セットを作成し、AWSマネージドポリシーのAWSCloud9Userポリシーを管理者アカウントにアタッチする
  • マルチアカウント許可 > AWSアカウントで、SandboxのAWSアカウントにSandboxOperatorGroupのグループを割り当て、SandboxOperatorの許可セットを割り当てる
• sandbox-deployer
  • SandboxDeployerGroupという名前のグループを作成する
  • sandbox-deployerという名前のユーザーを作成し、SandboxDeployerGroupに追加する
  • SandboxDeployerという名前の許可セットを作成し、CDKを実行するのに必要な権限をSandboxアカウントにアタッチする(検証では管理者権限をアタッチしています)
  • マルチアカウント許可 > AWSアカウントで、SandboxのAWSアカウントにSandboxDeployerGroupのグループを割り当て、SandboxDeployerの許可セットを割り当てる

3.3.CLIの設定

AWS CDK CLIのセキュリティ認証情報を設定するの内容に従ってCLIの認証情報を設定します。

$ aws configure sso
SSO session name (Recommended): SandboxDeployer
SSO start URL [None]: https://XXXXXXXXXXXX.awsapps.com/start
SSO region [None]: ap-northeast-1
SSO registration scopes [sso:account:access]: sso:account:access

3.4.Cloud9の共有設定

環境と同じアカウントのユーザーを招待するの内容に従ってCloud9の共有設定します。Assumed Roleの名前が必要なのでCLIで取得します。

$ aws iam list-roles --query 'Roles[*].RoleName' | grep Sandbox
    "AWSReservedSSO_SandboxOperator_XXXXXXXXXXXXXXXX",

管理者権限を持つユーザーでCloud9にログインします。Cloud9のコンソールの右上にあるShareボタンを押すと共有設定画面が表示されます。Invite Membersに権限を付与したいユーザーのSTSのARNを追加するとCloud9を共有出来ます。

arn:aws:sts::XXXXXXXXXXXX:assumed-role/AWSReservedSSO_SandboxOperator_XXXXXXXXXXXXXXXX/sandbox-user

共有設定が完了したら、管理者権限の認証トークンを削除するためにCloud9を一度停止します。停止後は管理者権限を持つユーザーでログインしない、またはログインした場合はCloud9を都度停止するように注意します。

4.検証

4.1.CDKの設定

CDKのチュートリアルに従って、CDKを実行出来るようにするための初期設定をします。s3バケットを一つ作るアプリを用意します。

$ mkdir ~/hello-cdk
$ cd ~/hello-cdk
$ cdk init app --language typescript

lib/hello-cdk-stack.ts

import * as cdk from 'aws-cdk-lib';
import { aws_s3 as s3 } from 'aws-cdk-lib';

export class HelloCdkStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    new s3.Bucket(this, 'MyFirstBucket', {
      versioned: true
    });
  }
}

4.2.CDKの実行

CDKを実行するための認証トークンを取得してCDKを実行します。認証はsandbox-deployerのユーザーで行います。

$ aws sso login --profile SandboxDeployer-XXXXXXXXXXXX --no-browser
...
Successfully logged into Start URL: https://XXXXXXXXXXXX.awsapps.com/start
$ cdk deploy --profile SandboxDeployer-XXXXXXXXXXXX

4.3.証跡の確認

CloudTrailにどのように証跡が残っているか確認します。管理アカウントでsandbox-deployerの証跡を確認するとGetRoleCredentialsというイベントが残っています。sandbox-deployerをCDKの実行ユーザーとしてだけ使うようにしておけば、このイベントでCDKを実行したことが確認出来ます。

管理アカウントのsandbox-deployerの証跡

Sandboxアカウントでsandbox-deployerの証跡を確認するとGetCallerIdentityとAssumeRoleというイベントが残っており、このイベントでCDKを実行したことが確認出来ます。CloudFormationのCreateBucketの証跡も残っているので、操作の内容も確認することが出来ます。

Sandboxアカウントのsandbox-deployerの証跡

SandboxアカウントのCloudFormationの証跡

どのユーザーが実行したかの証跡を確認するために、CDKを実行した時間のsandbox-userの証跡を確認するといくつかのイベントが確認出来ます。イベントの詳細な内容を見ると、StartSessionイベントでデプロイ用のCloud9に接続したことが確認出来ました。

    "requestParameters": {
        "target": "i-XXXXXXXXXXXXXXXXX",
        "documentName": "AWS-StartSSHSession"
    },

他のイベントの詳細を確認してみましたが、sandbox-userが直接CDKを実行したことを特定する証跡までは残っていませんでした。

sandbox-userがCDKを実行した時の証跡は、lsコマンド等の操作をした時も同じような証跡になるようです。そのため、CDKを実行した時間帯に一人だけデプロイ用のCloud9で操作している場合は証跡だけでCDKを実行したユーザーを特定出来ますが、他のユーザーも操作している場合はどのユーザーがCDKを実行したかは特定出来ないようです。この挙動が許容出来ない場合は注意が必要です。

5.まとめ

Cloud9でデプロイ環境を共有することで、デプロイ環境を一元管理しながらデプロイしたユーザーの証跡を残せる仕組みを構築出来ました。また、このデプロイ環境では、デプロイを実行するユーザーではAWS Consoleにログインして直接AWSリソースを変更出来ないようになっており、CDKで更新する場合もデプロイ権限を持っているユーザーの認証が必要なため、そのユーザーの認証をシステム管理者にしか持たせないことで、承認されていないシステム構成の変更を防ぐことが出来ます。

デプロイ実行時に複数ユーザーがデプロイ用のCloud9で操作している場合は、デプロイを実行したユーザーを特定出来ない問題があるため、今後はその部分の改善も必要になりそうです。

次世代システム研究室では、アプリケーション開発や設計を行うアーキテクトを募集しています。アプリケーション開発者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、ぜひ 募集職種一覧 からご応募をお願いします。

皆さんのご応募をお待ちしています。

参考リンク

• AWS Cloud9 で共有環境を使用する