Q. 特定のIAMロールだけをアタッチ可能にするIAMポリシーの書き方を知りたい
AWS IAMロールを渡すための認可設定がわからない。そんな場合に必要な知識とサンプルを紹介します。
ソフト道場の「SIerが目利きする。今日から使えるAWSレシピ」
- 2021年10月05日公開
Q. 特定のIAMロールだけをアタッチ可能にするIAMポリシーの書き方を知りたい
はじめに
NTT テクノクロスの渡邉 洋平です。
時折、社内のAWSのご相談が届くことが多いので、Tips等を追記しつつ、質疑の記録を時折Webにも公開してみることにしました。
表題の質問内容
内容を確認する前に、各用語を簡単におさらいしましょう。
参考:IAMポリシーとは?
AWSにおいて、アクセス許可や条件をJSONで定義するオブジェクトを"ポリシー"と呼びます。 IAMポリシーとはアイデンティティベースのポリシーを指し、下のリソースのアクセス許可を定義します。
- IAMユーザ
- IAMグループ
- IAMロール
IAMポリシーはStatementというブロックの集まりで構成され、各ブロックではそれぞれアクセス許可や条件を定義します。大まかなイメージとしては、公式サイトに記載の下図が参考になります。
ちなみに、Statementの各属性の意味を簡単にまとめてみました。後述のIAMポリシーのサンプルを読む際の参考にしてください。
-
Sid: Statementの名前・識別子。
- Sid = Statement-idの略ですね。
-
Effect: ポリシーで付与する認可の種別。
- Allow(明示的な許可) or Deny(明示的な拒否)
- Principal: ポリシーを利用するプリンシパル(ユーザ、ロール、セッションなど)
- 今回の例では利用しません。
- Action: Effectで指定する認可を行うアクション。
- Resource: Effectで指定する認可を行う対象のオブジェクト。
- Condition: Effectで指定する認可を行う条件。
参考:IAMロールとは?
前述のIAMポリシーを、AWSサービスやアプリケーションに一時的に委任するサービスをIAMロールと呼びます。
例として下図のような使い方をします。
この例では、EC2インスタンスに対しIAMロールをアタッチすることで、S3へのアクセス権限を委任しています。
これによりIAMユーザのアクセスキーをインスタンスやLambdaへ直接配置する必要がなくなり、認証情報の管理が簡単になります。なおかつ認証情報は自動的にローテーションされるため、AWSの各リソース間のアクセス管理ではIAMロールの利用が推奨されています。
質問内容
"特定のIAMロールだけをアタッチ可能にするIAMポリシーの書き方を知りたい" とのことでしたので、
- IAMポリシーで何のActionを許可すればよいか
- 操作対象となるIAMロールの制御方法、制御条件の設定方法
を回答すれば良さそうです。
Q. 何のActionを制御すれば良いか?
IAMポリシーで制御すべきActionですが、この場合はiam:PassRoleが正解です。
下に挙げるActionは、間違えやすいですが本件には関係ないことに注意してください。
-
sts:AssumeRole
- 本Actionは既存のIAM権限でIAMロールから一時的な認証情報を取得する操作です。
- 例として、ユーザAがロールBの権限を一時的に取得する、という使い方をします。
- ユーザAがロールBをリソースCに付与する。という今回のユースケースとは異なります。
-
attachrolepolicy
- 何も考えずに読むと「ロールをアタッチするポリシー......?」と一見それらしく見えるActionですが、″IAMロールにポリシーをアタッチするAction″です。Role自体のアタッチを制御するActionではありません。
- ″Roleに強い権限を付与して権限昇格されたくない″というユースケースには役立ちます。
A.ユースケースから考える、PassRoleを指定するポリシー
質問の内容からは、いくつかの回答が考えられます。 質問者様のユースケースでは後述の例1で十分の様子でしたが、せっかくなので、IAMポリシーの具体例をいくつか挙げてみます。
例1."hogehoge-"から始まる特定のRoleを渡すことを許可するポリシー
サンプルはこちらです。
- Resourceで指定するARNに"*"を利用することで前方一致する名称のRoleだけにPassRoleを許可(Allow)しています。
- PassRole以外のCreateなどの権限を付与する場合は本サンプルを編集して権限を追加するか、AmazonEC2FullAccess、AWSLambda_FullAccessなどのAWS管理ポリシーを設定してください。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowPassRole",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::012345678901:role/hogehoge-*"
}
]
}
例2.特定サービスへ特定のRoleを渡すことを許可するポリシー
例えばEC2インスタンスへRoleを渡したい(PassRole)場合、下記のポリシーでOKです。
- 例1との差分は、ConditionでPassRole対象のサービス(iam:PassedToService)をAllow条件としている点です。
- マネジメントコンソールからIAMRoleを選択する場合、"iam:ListInstanceProfiles"のActionも必要となるので記載しています。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowPassRoleOnlyEC2",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::012345678901:role/hogehoge-*",
"Condition": {
"StringEquals": {
"iam:PassedToService": [
"ec2.amazonaws.com"
]
}
}
},
{
"Sid": "AllowListInstanceProfiles",
"Effect": "Allow",
"Action": "iam:ListInstanceProfiles",
"Resource": "arn:aws:iam::012345678901:instance-profile/*"
}
]
}
例3.渡すことの出来るRoleの許可リスト、拒否リストを定義するポリシー
例1.例2. に関しては、あくまでEC2へのPassRoleを許可した。という記述に過ぎない点には注意です。具体的にはIAMエンティティ(ロールやユーザ)に対し、別のポリシーにてのAllowを拒否することは出来ません。 エンティティ毎に、PassRoleの許可・拒否一覧を明示的に指定したい場合は、下のようなポリシーを作成します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowList",
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::012345678901:role/hogehoge-*"
},
{
"Sid": "DenyList",
"Effect": "Deny",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::012345678901:role/hugahuga-*"
}
]
}
例4.特定のRole以外渡すことを禁ずるポリシー
“hogehoge-”から始まるRole以外のPassRoleを禁ずるポリシーは下のように書きます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "iam:PassRole",
"NotResource": "arn:aws:iam::012345678901:role/hogehoge-*"
}
]
}
禁ずるだけなら上のポリシーで良いですが、“hogehoge-”から始まるRoleのPassRoleは認めるという要件が暗に含まれている場合はこちらです。
- 当たり前のように感じますが、Actionが複合すると観点として漏れる場合もあるので注意です!
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": "iam:PassRole",
"NotResource": "arn:aws:iam::012345678901:role/hogehoge-*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:aws:iam::012345678901:role/hogehoge-*"
}
]
}
まとめ
要件が複雑なほどIAMポリシー作成は難しいですが、本質的には今回のようにStatementの組み合わせです。 作成に悩む場合は一度今回のように粒度を小さくして、ActionやResourceについて検討するところから取り組むと着手しやすいですね。 ※ポリシー数や、ポリシー当たりの文字数で悩みは尽きないですが......
それではまた。
デジタルツイン事業部でAWSのアーキテクチャ検討から何でもやってます。AWS 社内研修講師(IaaS/PaaS/CaaS) 全社AWSサポートなどを務めております。もっぱら育児中。