IAM Role/Policy について

# ポリシーとは
ポリシーとは、「誰が」「どのAWSサービスの」「どのリソースに」「どのような操作を」「許可する/しない」かを制御するものである

https://dev.classmethod.jp/articles/aws-iam-policy/

[サービス一覧とサービスに対する記述可能なアクション（操作）一覧](https://docs.aws.amazon.com/ja_jp/service-authorization/latest/reference/list_amazonelasticcontainerservice.html)

# ポリシーの分類
[Identity-based policies and resource-based policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)
## アイデンティティベースポリシー
アイデンティティベースポリシーのポリシーでは、IAMユーザー、IAMグループ、IAMロールに関連付けるポリシーになる

このポリシーでは、「誰が」にあたる部分がこのポリシーを関連付ける対象となるのでポリシーを記述際に`Principal`の部分が必要ない

アイデンティティベースポリシーは作成者や管理方法の観点でさらに以下のように分類できる

 分類名 | 概要
--------- | ---------
 AWS管理ポリシー | AWSが用意している再利用可能なポリシー。複数のIAMユーザー、IAMグループ、IAMロール間で共有可能。
カスタマー管理ポリシー | ユーザーが作成した再利用可能なポリシー。複数のIAMユーザー、IAMグループ、IAMロール間で共有可能。
インラインポリシー | 各IAMユーザー(やIAMグループ、IAMロール)専用にユーザーが個別作成するポリシー。

## リソースベースポリシー
リソースベースは関連づける対象がその名の通り「リソース」(AWSサービス)となる
例えば、Amazon S3 buckets, Amazon SQS queues, VPC endpoints,などが対象となりうる

リソースベースポリシーでは、「誰が」そのリソースにアクセスでき、「どのような操作」をできるかを指定できる
> you can specify who has access to the resource and what actions they can perform on it

この「誰が」にあたる部分を`Principal`で指定することとなる
また、指定できるポリシーはインラインポリシーのみとなる


[AWS JSON ポリシーの要素: Principal](https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_elements_principal.html)

## IAMロールの信頼ポリシー
IAMロールの権限委譲操作に特化したポリシー

このポリシーによって
「当該の信頼ポリシーを関連付けたIAMロールが保有する権限を、信頼ポリシーの操作主体である`Principal`に委譲する」
という記述をする

# IAM Role
あるPolicyが関連づけられているIAM RoleをAWSサービスに対して関連付けさせることで、そのAWSサービスから権限を委譲されている他のサービスへの操作が可能になる

IAM Policy -> IAM Role -> AWS Service


## AssumeRolePolicyDocument
UserやGroupに付与するものはRoleと基本的に同じだがRoleにしかない特徴として`AssumeRolePolicyDocument`がある

まず、IAM RoleをAWSサービスに紐づけただけではRoleが持つ権限を得ることはできない
AWSサービスがそのRoleを引き受けつ処理、つまりRoleを持つサービスがSTS(Security Token Serivce)に対してAssumeRole APIを発行し、他のサービスへの操作をするためのアクセスキーなどを取得する操作が必要になる
このアクセスキーを持っている主体（サービス）が関連づけられたRoleが持つ権限を実行できるというわけである

IAM Roleでは第三者に対して「自アカウントのAPI権限を委譲」するためのものであるが、この第三者には自分のアカウントのAWSサービスだけではなく、「別のアカウント」、「SAMLフェデレーション」だったりと赤の他人？も含まれている
こういった第三者が誰でもRoleを引き受けてしまってはセキュリティ的に危ないということで「許可を受けた第三者」を設定する必要がある
これが`AssumeRolePolicyDocument`である
「許可を受けた第三者」のことをTrusted Entityと読んだりする

`AssumeRolePolicyDocument`はIAM Userに付与するようなポリシーと同じように記述でき１つ異なる点として`Principal`がある
この`Principal`こそが先ほどから言っていた「許可を受けた第三者」、Trusted Entityのことである

例: AWSサービスであるEC2を信頼する
```json
{
  "Version" : "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [ "ec2.amazonaws.com" ] 
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

[Assume Roleについて 2014.02.12](https://dev.classmethod.jp/articles/iam-role-and-assumerole)

## PassRole
ユーザーが IAM ロールを AWS サービスに渡す(PASS)アクセス許可を定義する
このアクションが許可されていないと、そもそも IAM ロールをパスできない

```yaml
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "IAMPassRoleForEC2",
      "Effect": "Allow",
      "Action": [
        "iam:PassRole"
      ],
      "Resource": "arn:aws:iam::12345:role/EC2Role",
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": [
            "ec2.amazonaws.com"
          ]
        }
      }
    }
  ]
}
```

`Resource`パラメータで渡すことのできる*ロール*の制限
`Condition`パラメータでは渡す対象となる*AWSサービス*の制限をしている

上記の例では、渡すことのできるロールを`arn:aws:iam::12345:role/EC2Role`渡す対象として`ec2.amazonaws.com`に制限している

このようにすることで、IAMロールとロールを利用するAWSサービスのペアを制限できる

[AWSサービスに渡すIAMロールを制限する 2019.09.15](https://dev.classmethod.jp/articles/restrict-pass-ima-role-with-passrole/)