想定読者
- AWSのログインで利用するIdPをまとめたい人
- IAM プロバイダを設定したい人
- Google Workspace
前回までの設定
AWS IAMプロバイダとSSOを設定してみるにて、
個人のAWSアカウントでAWSのIAMにおけるIDプロバイダとAWS SSOを設定しました。
AWS SSOを設定したことで得られた体験
ログイン方法の簡素化
これまではIAMユーザをメインでしたのでMFAを設定するなど手間でした。
セキュリティを強固にすると利便性のトレードオフな部分ですね。
これがGoogleの右上に表示されるトグルから、
ログインに利用するGoogleアカウントを選択するだけで、
自身の管理するAWSアカウントにアクセスできる体験となりました。
複数のAWSアカウントを採用している背景
- 色々なJAWS-UGイベントや個人の検証などでInoviceを分別したい
AWS公式メールマガジンにて申請すると頂ける$25クーポンについて、
だいぶ認知されてきたようですが、私もその恩恵を享受している一人です。
https://pages.awscloud.com/dev-magazine-mail-member.html
AWSクレジットについては共有が可能であるため、
単一および複数のアカウントへの AWS クレジットの適用
CUR（Cost-and-Usage Report）の検証も含めて分析のために分割しました。
https://www.wellarchitectedlabs.com/cost/200_labs/200_4_cost_and_usage_analysis/
Invoiceを見たことがある人にはわかりますが、一括請求の請求は非常に分かりづらいです。
また、CostExplorerも、GUIだとグルーピングが1項目しかできないところが、
AWS CLIだと2項目グルーピングできたりとちょっと足りない部分があります。
そういった部分をQuickSightで見えるようになるといいなというぼんやりとおぼろげながらに構想が浮かんできました。
AWS CLIのパラメータ
少しなれてくると必要になってくるのがAWS CLIのアクセスキー、シークレットアクセスキーです。
こちらに関しても、AWS SSOの画面であれば予め用意されています。
macOS/Linux/Windows/PowerShellと大抵の環境で設定するテンプレートで表示してくれます。
何も全ていいことばかりではない
アカウント作成しすぎない
組織で許容されるアカウントのデフォルトの最大数: 4
もちろん上限緩和申請を行うことで拡張は可能です。
そして、Oraganizations画面で普段見ないであろう、
「「{count} 」個のアカウントを招待できませんでした。
You have exceeded the allowed number of AWS accounts.」
という表示も見ることが可能ですが、後述することに関連するので上限緩和する際はよく検討してください。
https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_reference_limits.html
https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_accounts_create.html
アカウントを作成すると、AWS Organizations最初に、長い (64 文字) の複雑、ランダムに生成されたパスワードを root ユーザーに割り当てます。
この初期パスワードを再び取得することはできません。root ユーザーとしてアカウントに初めてアクセスする場合は、パスワード復旧プロセスを行う必要があります。
アカウント解約時のプロセスが面倒になる
Oraganizationsからメンバアカウントの解約はできないので、
解約が必要になる場合には個別のメンバアカウントでの作業が必要になってきます。
その際に、Organizationsでアカウントを作成した場合には、
rootアカウントに対するパスワードを一度リセットする作業が必要になるため、
解約になる際は手間に感じることになると思います。
SSOで利用する権限を追加する場合
職務機能ポリシーを使用して事前定義済みの AWS 管理ポリシーをアクセス権限セットに適用します。これらのポリシーは、IT 業界でよく使用される職務機能に基づいています。
カスタムポリシーを使用して最大 10 個の AWS 管理ポリシーを選択します。お客様のニーズに最も合う新しいポリシードキュメントを定義することもできます。
個人で利用する分には、AWSが予め用意されているポリシーで十分です。
権限付与の範囲
アカウントごとに設定するポリシーを設定することが可能です。
さらにアカウント個別に、SSOを許可したユーザ単位で前述の割当した権限セットを適用するかどうかを定義することが可能です。
まとめ
AWS SSOで、IdPをGoogleアカウント（GWS：Google Workspace）に寄せることで、
追加費用無しでログイン体験と従来のIAMユーザ同様のAWS CLIに必要な情報を得られました。
Organizationsを使っているので、
次に気になるのはアカウントごとに制限が適用できるSCP(Service Controll Policy)と、
リソースができるCloudFormation StackSetsです。
SCPに関しては過去に実験している記事を上げているので、
CloudFormation StackSetsを試していこうかなと思います。