AWS IAMに登場する概念はややこしく、初学者が理解するのは難しいと思います。
そこで、概念モデルを作成して、AWS IAMの基本概念を整理しました。
※ 一部の概念はTerraformのリソース名を参考に命名しています。
全体像
AWS IAMに登場する基本概念は、以下のように整理できました。
それでは、以下の3つに分けてややこしい点を説明していきます。
- IAM Policy
- IAM Policy Attachment
- IAM Role
IAM Policy
IAM Policyとは、どの「リソース」へのどの「アクション」を許可 (拒否) するかを定義するものです。
例えば、「S3へのListBucketを許可」といった内容になります。
IAM Policyには「管理ポリシー」と「インラインポリシー」の2種類がありますが、「インラインポリシー」は非推奨とされています。
※ インラインポリシーはIAM Role、IAM Group、IAM Userに直接記述するものですが、非推奨ということもあり、今回作成したモデルではそこまで表現していません。
管理ポリシーには以下の2種類があります。
- AWS管理ポリシー
- AWSがあらかじめ用意している管理ポリシー
- カスタマー管理ポリシー
- カスタマーが独自に作成する管理ポリシー
JSONは一見ややこしいですが、少しじっくり見れば、実はそれほど難しくありません。
どのリソースへのどのアクションを許可 (拒否) するか、ただそれだけを表しています。
IAM Role Policy Attachment
IAM Policyは何かにアタッチして始めて意味を成します。
アタッチできる対象は以下の3つです。
- IAM Role
- IAM Group
- IAM User
IAM Userに直接アタッチすることは推奨されていないので、IAM Userにポリシーをアタッチしたい場合は、代わりにIAM Groupにアタッチし、IAM UserをIAM Groupに入れましょう。
IAM Roleは少しややこしいので、以下で別途解説します。
IAM Role
IAM Roleは、あるリソースに対して他のリソースへのアクションを許可したい場合に使います。
例えば、EC2からS3にListBucketできるようにしたい場合、以下のステップを踏むことになります。
- S3へのListBucketを許可するIAM Policyを作成
- EC2をPrincipalに設定したIAM Roleを作成し、上記のIAM Policyをアタッチ
- EC2インスタンスに上記のIAM Roleをアタッチ
EC2をPrincipalに設定したのは、「このロールはEC2にアタッチできるものだよ」という意味です。
Principalはマネジメントコンソールやドキュメント上で「信頼」という言葉で表現されることがあります。
※ 実際には、EC2へのIAM Roleのアタッチは、インスタンスプロファイルを経由することになります
IAM Roleを使わずとも、IAM Userのアクセスキー、シークレットアクセスキーをEC2内の ~/.aws/credentials や、アプリケーションのプロパティファイルなどに設定すれば、EC2から他のリソースにアクセス可能になります。
しかし、その方法はアクセスキー、シークレットアクセスキーの漏洩というリスクを追うことになるため、非推奨とされています。
おわりに
これでAWS IAMの基本概念を整理できました。
AWS Organizations、Permissions boundaryといったものを含めるとより複雑になりますが、第一歩としてはこのくらいかなと思います。
IAM関係は重要なわりに難しく、私もまだまだ理解が浅いので、もし間違いに気付かれた方はご指摘お願いします。