【AWS公式が提供しているハンズオン講座】ハンズオンはじめの一歩: AWS アカウントの作り方 & IAM 基本のキ »を実際にやってみて、気になった内容を整理したいと思います。AWSに出てくるユーザ、ポリシーをはじめてとして、似たような概念がいくつか出てくるので私なりにまとめます。
この記事はAWSを独学で勉強している私が特に気になった内容を留めておくものです。
インフラ素人、高校の情報のテストで赤点取った人が「なんとなく」AWSを理解することをテーマに勉強した内容や気になった内容をまとめてます。
ユーザ・ポリシー・ロール・SCP・許可セット
ざっくり言葉の理解。
ルートユーザー：御本尊、始祖のユーザー、強すぎる権限のため普段使いはしない。イメージ的にはアカウントといっても良い。アカウント＝唯一無二であって、アカウントにはメールアドレスなどを登録する必要がある。
IAMユーザー：実際のユーザーアカウント、AWS操作用のユーザー。ルートユーザーを起点に払い出されるユーザーたち。メールアドレスなどは不要。後述するIAMポリシーを付与することで権限が与えられる。だいたい、ルートユーザーは使わないので、管理者用ユーザーを最初に作成し、その後、開発用ユーザー、本番用ユーザーを作成して使っていく。イメージ的には、インフラ担当リーダーが管理者用ユーザーを持ち、メンバが開発用ユーザー、本番用ユーザーを持つような感じ。
IAMユーザーグループ：IAMユーザーをまとめたもの。ユーザー一人ずつに権限付与するのが面倒なので、ユーザーをある程度の塊でまとめておくことで、一括で権限付与できる。
IAMポリシー：権限を記した文書、JSON形式で記載。ただし、アカウントに対してしか付与できない。
IAMロール：AWSのサービス（リソース）に権限付与する時に使う。IAMポリシーをもとにIAMロール（AWS公式では”帽子”の絵が使われている）を作って、そのロール（帽子）をAWSサービスに被せることで、AWSサービスに権限を与えることができる。AWSサービスには、IAMポリシーを付与できないので、IAMロールという名の帽子にIAMポリシーを付与して、間接的に権限付与する。
SCP（サービスコントロールポリシー）：AWS Organizationsで作成したOU（Organizations Units）単位に行う権限設定。ガードレール戦略とも言われ、その組織（OU）で「しちゃいけないこと」を定義する。例えば、本番用OUであれば、EC2に対する開始・終了をさせないようにしたりなど。
許可セット：SSO（Identity Center）ユーザーに対する権限設定
図解
特に紛らわしい概念については、以下の図でまとめてみました。
ポイントは、OrganizationsはあくまでAWSアカウントをまとめたものであり、ユーザーではないこと。そのため、Organizationsで招待したアカウントに対して、実際にそのアカウントとしての作業が必要であれば、ユーザーを払い出す必要がある。
そして、ユーザーに対しての権限設定はポリシーで実施するため、払い出したユーザーに対してはポリシーを付与することが必要。
最後に
あくまで勉強の記録を残すことが主な目的ですので、正確な内容を確認されたい方は公式ドキュメントなどをご確認ください。
コメント