Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

D90a5143f16f9b27bef934aabf63ed59?s=128

Kato Ryo

May 22, 2019
Tweet

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 として実⾏される
  37. 37