AWSマルチアカウント管理術

Yappli Meetup 〜Site Reliability Engineering〜＠アカツキ(https://yappli.connpass.com/event/124728/)
で発表した内容です｡

Transcript

1. AWSマルチアカウント管理術 AWS事業本部 カタリストセールス部 2019/05/22(⽔) 加藤 諒 1
2. スライドは後で⼊⼿することが出来ますので 発表中の内容をメモする必要はありません。 写真撮影をする場合は フラッシュ・シャッター⾳が出ないようにご配慮ください Attention
3. 3 ⾃⼰紹介 名前: 加藤 諒 役割: プリセールス AWS技術⽀援 経歴: 他業種 → オンプレ SIer → クラスメソッド
4. 4 みなさん⽇々何個の AWSアカウントを扱っていますか︖
5. 5 マルチアカウントのメリット・必要性 • 権限の最⼩化 • 本番環境にはCI/CDやGitOpsでしかアクセスさせない → セキュアな環境 • プロジェクトAのメンバーは､Bにアクセス不可 • コスト分析 • プロジェクト､環境(dev, stg, prd)毎にコストを出せる • タグ付けでもできるけど､ぶっちゃけ⾟い • 負荷テスト • (リソース的に分離したとしても)本番環境に対して⾏っ てアカウント毎停⽌の恐れ
6. 6 マルチアカウントの⾟さ • このIAMユーザー(アクセスキー)どのアカウント⽤ のだろう • 何⼗個もあるアクセスキーのローテーションなんて 無理… • 退職したAさんのIAMユーザーが30個ある…
7. 7 あれ︖マルチアカウントって⾟い︖
8. 8 最初におすすめのフロー紹介
9. 9 AWSアカウント ログインフロー • IAMユーザーは1つしか持たない(ID&PWは1つ) • Multi Factor Authentication 必須 • IAMユーザー⽤AWSアカウントは情シスが管理可能
10. 10 そもそもIAMって??? IAMについて簡単に説明
11. 11 AWS Identity and Access Management • セキュアにAWSを使うための認証・認可の仕組み • 実現できる事 • ユーザー単位でのアクセス制御 • AさんはEC2をストップ & スタートできる • グループ単位でのアクセス制御 • アプリケーションチームはデプロイできるがネットワーク設定 は変更できない • AWSサービス間のアクセス制御 • CodeBuildからS3やCWLにログ出⼒
12. 12 IAM必須⽤語 • IAMユーザー • アクセスキーによって認証された⼈・プログラム • IAMグループ • IAMユーザーの集合 • IAMポリシー • どのAWSリソースに触って良いかという権限 • IAMロール • 存在によって認証されたIAMユーザー・AWSサービス
13. 13 IAMユーザー IAMユーザー IAMポリシー EC2への アクセス権限 関連付け 操作 EC2 IAMユーザー
14. 14 IAMグループ IAMユーザー IAMポリシー EC2への アクセス権限 グループに 関連付け 操作 EC2 開発者IAMグループ IAMユーザー
15. 15 IAMポリシー { “Effect”: “Allow”, “Action”: [ “s3:ListBickets”, “s3:Get*” ], “Resource”: [ “arn:aws:s3:::mybucket” ], “Condition”: { “IpAddress”: { “aws:SourceIP”: [“13.32.52.13”, “13.32.52.22”] } } } • Effect • 許可: Allow, 拒否: Deny • Action • 対象となるAWS操作を指定 • Resource • 対象となるAWSリソースを指定 • Condition • このアクセス制御が有効になる条件の設定
16. 16 IAMポリシー • AWS管理ポリシー • AWSが管理するポリシー • AWSによって更新も⾏われる (例)新サービス登場時など • カスタマー管理ポリシー • ⾃分で作成・管理するポリシー • 特定リソース単位(EC2インスタンスAなど)で制御可能 • インラインポリシー • IAMユーザー・グループ・ロール専⽤に作成するポリ シー
17. 17 IAMロール • IAMロール • AWSサービスやIAMユーザーの存在に対して操作権限を 付与する仕組み 1丁⽬: ⾃分の家 4丁⽬: 太郎の家 太郎 4丁⽬の太郎くんな ら私の家に⼊れて 4丁⽬の太郎くん だからOK!!
18. 18 IAMロール • IAMロール • AWSサービスやIAMユーザーの存在に対して操作権限を 付与する仕組み AWSアカウントA AWSアカウントB iamuser: taro Account Bの iamuser:taro を許可 して Account Bの iamuser:taroだから OK ID & PWで認証 存在によって認証
19. 19 実践編
20. 20 Web UI(AWSマネジメントコンソール) のマルチアカウント管理
21. 21 ⽬的 • 迷わず⽬的の環境にアクセスしたい • 操作アカウント間違いを防ぎたい • 同時に複数プロジェクトの作業をしたい
22. 22 Chrome プロファイル切り替え • Chromeは複数プロファイルを同時実⾏可能 • プロファイル間は別セッション • 同時に別のAWSアカウントにログイン可能 • プロファイル毎にカラーテーマを設定できる • プロジェクト毎に⾊を決めることで誤作業防⽌
23. イメージ図 23 Chrome プロファイル切り替え
24. 24 カラーテーマ • Chrome Theme Creator (https://bit.ly/2fFpMXM) • 2択 • ⾃分でカラーテーマを作る • 出来合いのテーマを使う • アニメからアイドルまで⾊々
25. 25 スイッチロールの使い所 • 環境(dev, stg, prd)毎にChromeプロファイルを作 ると流⽯に多すぎる • スイッチロールで環境を切り替えを⾏う
26. 26 クレデンシャルの管理 • 認証情報は1Password等で管理 • 好みのツールでOK • MFAを別管理にするかはお好みで • PC以外のデバイスを使⽤するとより安全
27. 27 AWS CLI・AWS SDK(Tools) のマルチアカウント管理
28. 28 ⽬的 • クレデンシャルを簡単に管理したい • 操作アカウント間違いを防ぎたい • どんなツールでも使えるようにしたい • Assume Role with MFA 未対応ツールへの対策
29. 29 クレデンシャルの保管 • ~/.aws/credentials • アクセスキー & シークレットアクセスキー • 1組だけ登録する • ここ以外にクレデンシャルは記載しない!! • 分散すると管理しきれない [classmethod] aws_access_key_id=XXXXXXXXXXX aws_secret_access_key=XXXXXXXX
30. 30 プロファイルの定義 • ~/.aws/config • role_arn & source_profile & mfa_serial • AWSアカウントが増えるたびに追加する [profile project_a_dev] region=ap-northeast-1 output=json role_arn=arn:aws:iam::<<対象のAWSアカウント>>:role/cm-kato.ryo source_profile=classmethod mfa_serial=arn:aws:iam::<<CMのAWSアカウント>>:mfa/cm-kato.ryo デフォルトプロファイルの場合は [default]と書く
31. 31 AWS CLIで使⽤するには • --profile で プロファイル名を指定 • 指定しないとデフォルトプロファイルで実⾏される • OTPの⼊⼒を求められる • ⼀度OTPを⼊⼒すれば有効時間内は再⼊⼒不要 $ aws --profile project_a_dev s3 ls Enter MFA code for arn:aws:iam::<<CM>>:mfa/cm-kato.ryo: <<OTP>>
32. 32 Toolで使⽤するには • Toolが対応している • オプションでプロファイル名を指定 & OTP⼊⼒ • Toolが対応していない • ⾃分で直してPull Request • direnv & assume-role で⼀時クレデンシャルの⽣成
33. 33 メジャーなOSSでも､Assume Role with MFA に 対応していない事はよくあります 対応していたら感謝しながら使いましょう!
34. 34 assume-role(github.com/remind101/assume-role) • 指定したプロファイルの⼀時的な認証情報を⽣成し て環境変数にセットしてくれるツール • evalを使いセットする $ assume-role project_a_dev MFA code: <<OTP>> export AWS_ACCESS_KEY_ID=”XXX” export AWS_SECRET_ACCESS_KEY=”XXX" export AWS_SESSION_TOKEN=”XXX” export AWS_SECURITY_TOKEN=”XXX" export ASSUMED_ROLE=”project_a_dev" # Run this to configure your shell: # eval “$(assume-role default)”
35. 35 direnv(github.com/direnv/direnv) • ディレクトリ毎に環境変数を設定できるツール • .envrcに設定したい環境変数を定義する $ cd workdir/project_a/dev $ echo ‘eval ”$(assume-role project_a_dev)”’ > .envrc $ direnv allow direnv: loading .envrc MFA code:
36. 36 direnv & assume-role で実現できること • ディレクトリに移動すると､OTPの⼊⼒要求 • 環境変数に⼀時クレデンシャルがセットされる $ cd workdir/project_a/dev direnv: loading .envrc MFA code: direnv: export +ASSUMED_ROLE +AWS_ACCESS_KEY_ID +AWS_SECRET_ACCESS_KEY +AWS_SECURITY_TOKEN +AWS_SESSION_TOKEN $ aws s3 ls # profile project_a_dev として実⾏される