はじめに
今回は分かったふりをしながら使っていたIAMポリシーについて勉強したので記事にしてみました。
ポリシーってなんのためにあるの
いきなりですが、
「誰が」「どのリソースの」「何に対して」「どんな操作を」「許可 or 拒否する」
ポリシーの考え方はこれだけです
そして、作ったポリシーを「何か」に割り当てるだけ、です。
その「何か」には
- アイデンティティ
- リソース
があります。
アイデンティティ
アイデンティティというのはこんな感じです。
IAMユーザーやIAMロールに割り当てます。
このポリシーをアイデンティティベースのポリシーと言います。
リソース
リソースはAWSの各リソースですね。
LambdaやS3に割り当てます。
このポリシーをリソースベースのポリシーと言います。
この二つのポリシーには少し違いがありますが、ポリシーに対する考え方的な部分ははじめに書いた通り
「誰が」「どのリソースの」「何に対して」「どんな操作を」「許可 or 拒否する」
だけです。
ポリシーの書き方
上記の考え方をもとにポリシーを書く際は
- 誰が：Principal
- どのAWSリソースの：Actionの左側
- 何に対して：Resource
- どんな操作：Actionの右側
- 許可 or 拒否：Effect
このようになります。
細かい設定もありますが、まずはこれを覚えていれば概要は把握できるはずです。
ポリシーの割り当て方
では、ポリシーの何がややこしいのかイラストを交えながら見ていきましょう。
今回の登場人物は
- ジョン
- Lambda
- S3
です。
ジョン(IAMユーザー)とLambdaはそれぞれ、S3のオブジェクトを取得したいと思っています。
この時、誰にどんなポリシーを割り当てればいいでしょうか？
私はここがIAMポリシーでつまずく部分でした。
いくつかパターンがあるので分解しながら見ていきましょう。
パターン１：ジョンにS3を操作するポリシーを割り当てる
パターン２：S3にジョンとLambdaから操作できるポリシーを割り当てる
パターン３：LambdaにS3を操作するポリシーを割り当てる
ざっくり分解するとこうなります。
先に軽く触れますが、この「パターン３」は正確ではないです。
正確には「LambdaにS3を操作できるポリシーを割り当てたロールを割り当てる」です。
詳細は後述します。
それを踏まえて再度、全体像をあら表すとこうなります
ジョンのアイデンティティベースのポリシー
ではまず、ジョンがS3のhtmlバケットを取得するポリシーを見ていきます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::html/*"
}
]
}
これは単純ですね。
- Actionの左側：S3
- Resource：S3のhtmlオブジェクト
- Actionの右側：GetObject（オブジェクトを取得する）
- Effect：Allow（許可する）
です。
S3のリソースベースのポリシー
次はS3がLambdaとジョンからのアクセスを許可するポリシーです
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::{ACCOUNT_ID}:user/John",
"arn:aws:iam::{ACCOUNT_ID}:role/service-role/{lambdaに割り当てたrole名}"
]
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::html/*"
}
]
}
基本的な考え方はジョンに対するポリシーと同じなので省略します。
しかし、このリソースベースのポリシーにはアイデンティティベースのポリシーにはなかった「Principal」があります。
Principalは翻訳すると「主体」や「主要」という意味です。
「誰が」の部分です。
これは、アイデンティティベースのポリシーは対象となる相手が決まっているのでPrincipalは必要ありません。
ジョンに割り当てるポリシーにわざわざ「これはジョンのポリシーです」と書く必要はありませんね。
しかし、リソースベースのポリシーは主体がS3自身ではなく別のリソースのため、Principalを書く必要があります。
Lambdaにロールを割り当てる
では、最後にLambdaです。
先に書いた通り、Lambdaに直接S3を操作するためのポリシーを割り当てることはできません。
ポリシーを作成して、一旦IAMロールにポリシーを割り当てる必要があります。
Lambdaにもリソースベースのポリシーは存在しますが、それは別のリソースやユーザーがLambdaを操作する場合に使用します。
自分に対しての「許可」「拒否」はできるけど、他のリソースに対しての「許可」「拒否」はできない、ということです。
少し前置きが長くなってしまいましたが、Lambda用にIAMロールに割り当てるポリシーを見てみましょう
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::HTML/*"
}
]
}
このポリシーはロールに割り当てるので「Principal」がありません。
ロールに割り当てるので、これはアイデンティティベースのポリシーです。
LambdaからS3を操作するには、このポリシーを割り当てたロールをLambdaに割り当てる必要があります。
信頼ポリシー
上記のポリシーで{アカウントID}というのを指定していました。
もし、これを他のアカウントのIDにするとどうなるでしょう？
そうです、アカウントを跨いで操作を実行することができます。
しかし、これには信頼ポリシーというものを使って権限の付与を行う必要があります。
これに関しては私の説明の100万倍わかりやすい記事があったので、こちらを参考にして下さい。本当にわかりやすいです。
参考：https://dev.classmethod.jp/articles/iam-role-passrole-assumerole/
まとめ
ポリシーはリソース同士を組み合わせる時には必ずと言ってもいいほど使われます。
よく触る設定なので、なんとなく分かっているフリをしていましたが、実際に勉強してみると理解できていない部分がありました。
これを機に、よくわからず作成した無駄なカスタムポリシーを削除して綺麗なポリシー管理をしていきたいと思います。