先週こんな記事を書いたんですが、CIに関する部分が抜けてたのでこっちで追記版を記載します。
AWSの複数アカウントを簡単にセキュアに管理し、利用する
CIに関する部分も追加してあります。
請求を一括管理(Consolidated Billing)
- 請求はProdアカウントで一括管理します。
複数のAWSアカウントの利用料金を代表1アカウントで支払う「Consolidated Billing」の設定方法
Rootアカウントはほぼ使わない
- コンソールログインにバーチャルMFA(Authy)を設定します。
- APIでアクセス可能なセキュリティクレデンシャル(アクセスキーとシークレットキー)は発行しません。
AWSアカウント作ったらこれだけはやっとけ!IAMユーザーとAuthyを使ったMFAで2段階認証
CIでのデプロイに使う IAM User
- Rootやコンソールユーザーとは別に IAM User を作成します。
- セキュリティクレデンシャル(アクセスキーとシークレットキー)はデプロイする内容に応じて必要な範囲のみ権限を開けます。
- この IAM Usr は
password=no
でコンソールにログインできないようにしておきます。 - 注意点として、たとえば CircleCI だと、ひとつのリポジトリに設定できるAWSのクレデンシャルはひとつ(ブランチごとにデプロイ先を分けても、それはすべて同一アカウント内というユースケースなのだと思う)なので、ブランチごとにクレデンシャルを切り替えて使うようにひとひねりしてあげる必要があります。
CircleCIでブランチごとのデプロイ先を別々のAWSアカウントに切り替える
例として、hugoなどの静的サイトジェネレーターで生成したhtmlを、AWS CLIでS3にデプロイするとしたら以下のような感じになります。
どこにどういうツールでデプロイするかによって、使うツールなどは変わってくるので、そこらへんは別途色々書きたいと思います。
- 本番アカウントのCIユーザーのクレデンシャルを「リポジトリ > AWS Permissions」に登録しておく
- ステージング、開発アカウントのCIユーザーのクレデンシャルは「リポジトリ > Environment variables」に個別登録しておき、デプロイ時に参照し、profileに追加して使う
- 以下のcircle.ymlではステージングアカウントのキーが環境変数
STGAWSKEY
STGAWSSECRET
、開発アカウントのキーが環境変数DEVAWSKEY
DEVAWSSECRET
に登録されていることを前提にしてます。
- 以下のcircle.ymlではステージングアカウントのキーが環境変数
circle.yml
machine:
timezone: Asia/Tokyo
dependencies:
override:
- sudo pip install awscli
post:
- aws configure set region ap-northeast-1
deployment:
production:
branch: master
commands:
- aws s3 sync public/ s3://sec9.co.jp/ --delete
staging:
branch: staging
commands:
- echo "[staging]" >> ~/.aws/credentials
- echo "aws_access_key_id="$STGAWSKEY >> ~/.aws/credentials
- echo "aws_secret_access_key="$STGAWSSECRET >> ~/.aws/credentials
- echo "region=ap-northeast-1" >> ~/.aws/credentials
- aws s3 sync public/ s3://stg.sec9.co.jp/ --delete --profile staging
development:
branch: development
commands:
- echo "[development]" >> ~/.aws/credentials
- echo "aws_access_key_id="$DEVAWSKEY >> ~/.aws/credentials
- echo "aws_secret_access_key="$DEVAWSSECRET >> ~/.aws/credentials
- echo "region=ap-northeast-1" >> ~/.aws/credentials
- aws s3 sync public/ s3://dev.sec9.co.jp/ --delete --profile development
正直言うともうちょっといい方法ないかなというアイデア募集中
コンソールを利用するユーザーは IAM User か クロスアカウントでSwitchしたRole
- 本番アカウントで IAM User を発行し、本番アカウント以外ではクロスアカウントアクセスの Role を作成しておきます。
まとめ
- 今回もこの記事は「小規模に複数アカウントを運用するとき」にいかに簡易によりセキュアに管理できるかなと考えた内容なので、運用する規模によってベスト・プラクティスは変わるでしょうし、そんなこと色々考えるのも楽しいですね。