Open2
今更聞けないIAMポリシーのこと
IsTre1592概要
- これまで、実はあまりAWSとは関わってこなかった人生だった
- Google CloudやSnowflakeは触ってきたけど、AWSはS3とかLambdaくらいで、IAMとかも他のサービスと大体一緒でしょ、くらいの認識だった
- その流れでずっときてたけど、利用する以上理解しないでこのまま引っ張るのは良くないと思い調べた
- IAM ポリシーに関するドキュメントを色々ここで確認して理解した内容を書く
IsTre1592JSONポリシー
概要
- awsのiamとかs3のバケットポリシーとして設定するあのjsonって、結局のところどういう仕様だったり、あのversionとかって何を指定してるんだろう、みたいなのを実は学んでこなかった
- そういう今更人に聞けない、JSONポリシーの話
- また、細かい設定方法や書き方みたいなのはドキュメントに載ってることなのでここでは記載は特別なことがない限りはしない(自分の認識と違ってて書いておきたいものは書くが)
ソース
内容
- IAM JSONポリシーとは
- IAMポリシーはJSON形式で表現されるから、それをまとめてIAM JSONポリシーと言ってる感じ？
- このリファレンスでは各要素の意味だったり記載方法が書かれている
Version(Required)
- ポリシーを処理するために使用される言語構文ルールのバージョンを指定しているとのこと
- 現状だと2種類で、デフォルトでは2012-10-17を選ぶことになっているとのこと
- 2012-10-17：現行バージョンがこれで、これを選ばないとポリシー変数などの機能を使用できないらしい
- 2008-10-17：旧バージョンがこれ、特に使う理由がなさそう
Id(Optional)
- あんまり使われているのを見かけないこのIdという要素
- 監査ログなどでどのポリシーが評価されたのかを識別したり、外部システムでポリシーを管理する際の追跡用IDとして利用することもあるらしい
Statement(Required)
- jsonポリシーの中で、誰にどんな権限をどんな条件で付与するのか、みたいなのを定義するまとまり
- 単一ステートメントの時は{}のみでOK、複数ステートメントの時は[]の中に{}で配列として表現する
Sid(Optional)
- ステートメントの中で任意のid文字列をつけて識別する要素
- 人が見てわかりやすいステートメントにするという意味以外に、IAMポリシーを利用する際にSidを要求するサービスもあるそう
- ここには文字列としてなんでも定義できそうだが、プラクティスとしては次のようなものがありそう
- インクリメンタルに番号をつける：あまりSid自体に意味づけをする用途はなくなる
- 環境や役割を含める：環境や対照システムが複数ある場合
- 社内ルールや命名規則の通りにする：監査とかで確認しやすい？機械的に判断しやすくはなりそう
Effect(Required)
- ステートメントの結果を許可、もしくは拒否のどちらの設定にするか
- AllowとDenyで記載する
- ここに関しては、評価順序があるらしく、それに則って評価され、処理されるとのこと、詳しくは以下を参照
Principal(Optional)
自分の理解のための内容
- ポリシーの種類によってはポリシー内で定義すべきものと、そうではないものがあるためOptional
- 次の二つのポリシーがあり、それぞれでPrincipalがなぜいるか、いらないかを整理する
- Identity-based policy
- IAMユーザーやロールにこのポリシー自体を直接アタッチする方式
- 直接ポリシーをアタッチするので、Principalを設定すると二重に設定することになる
- Resource-based policy
- AWSのリソースに対してポリシーをアタッチする方式
- そのリソース自体には「誰が」というPrincipalの情報は持ってないため、ポリシーの中でPrincipalを指定し、そのリソースにアタッチしたポリシーを「誰が」操作可能かを定義する必要がある
- Identity-based policy
ドキュメントの内容
- ポリシーの中で指定できるプリンシパル
- AWSアカウント
- IAMユーザー
- IAMロール
- ロールセッション
- そもそもロールセッションとは、ロールを使用したいとなった時にSecyrity Token Serviceによって払い出される、そのロールのエンティティである
- ロールセッションのARNは以下のような形式で、ロールにセッションの内容が記載されて成立するような内容
- "Principal": { "AWS": "arn:aws:sts::AWS-account-ID:assumed-role/role-name/role-session-name" }
- 何に使えるのかはあまりわかってなく、なんかAPIとか使ってロールセッションを払い出す時に、そのロールセッションに対してプリンシパルを紐づけるみたいな感じにしてできることがあるのかもしれない
- フェデレーションユーザープリンシパル
- OIDCとかSAMLとかで外部からアクセスする時に、そのユーザーに対してプリンシパルを適用するのに使いそう
- AWSのサービス
- 例えばEC2など
- プリンシパルとして指定できるものの定義
- 認証可能なリソースかどうか
- ユーザーグループはアクセス権限を管理するリソースであり、プリンシパルは認証ずみのIAMエンティティだからユーザーグループをプリンシパルに含めることはできないとのこと
Principalに関してはすごく奥が深そうなので、ポリシーを使いたい時にどういう形で利用することができるかを考える時に都度ドキュメントを見るくらいの気持ちのほうが良いかもしれない
NotPrincipal(Optional)
- Effect: denyなステートメントの中で、それの対象外としたいPrincipalを指定する時に使用するものらしい
- 基本的にデバッグとかしにくくなるし、直感的でないので使用せずに実現できるならそうしたほうが良いとのこと
- 例えば、Conditionで条件を組み合わせてできるなら、そうしたほうが良いとのこと(ArnNotEqualsとか)
Action(Required)
- 特定のサービスで利用可能な特定のアクションを指定する
- それぞれのサービスのAPIリファレンスで次のような形で定義されている
- Actions
- アクションの一覧
- Actions by services
- サービスごとに利用できるアクションの一覧
- サービスから利用可能なものはこちらもAPIリファレンスとして持っていそう
- Actions
- 指定方法としては
service:actionみたいな形で、ケースセンシティブなので大文字小文字どっちでもOK - また、*や?のようなワイルドカードも使用できるため、他にも次のような形で定義できる
- s3:*
- S3のサービスのすべてのアクションを許可する
- sqs:*message
- sqsのサービスの後ろがMessageで終わるすべてのアクションを許可する
- s3:*
NotAction(Optional)
- 指定したアクションリスト以外のすべてのアクションを許可することができる
- 明示的に使わせたくないアクションはあるが、それ以外は使ってもらってもいいような権限パターンの時に使えそう
Resource(Required)
- ステートメントが適用されるオブジェクトをARN形式で指定する
- リソースの指定の中でもワイルドカードの使用が可能
- 他の要素と同様に、複数リソースを指定する場合は[]の中で複数リソースを記載する
NotResource(Optional)
- 指定したリソース以外に対してステートメントを適用するというやつ
Condition(Optional)
- ステートメントを適用する際の条件を指定する
- 指定方法は以下
{ "{condition-operator}" : { "{condition-key}" : "{condition-value}" }}- condition-operator
- 条件演算子で指定する、条件演算子について詳細はこちら
- condition-key
- condition-value
- コンテキストキーに当てがう値
- 配列などでも持てる
変数とタグ
サポートされているデータ型
補足
公式ドキュメントではないが、ポリシーの考え方で特に理解が捗ったものがあるので紹介。
ポリシーの呼び方色々
- 以下の図がわかりやすかった
- 元の記事は以下