IAM の概要をまとめています。

IAM リソース

  • ユーザー
    • ルートユーザー（アカウント毎に1つ発行）
    • IAM ユーザー
  • グループ
  • ロール

ユーザー、グループ、ロールを IAM アイデンティティと呼びます。

IAM ポリシー

  • AWS 管理ポリシー（ AWS managed policies ）
    • AWS ビルトインのスタンドアロンポリシー
  • カスタマー管理ポリシー（ Customer managed policies ）
    • カスタムのスタンドアロンポリシー
  • インラインポリシー（ Inline policies ）

    • IAM アイデンティティ (ユーザー、グループ、またはロール) に埋め込まれたポリシーです。つまり、ポリシーは本質的にアイデンティティの一部です。

※ ARN を持つポリシーを スタンドアロンポリシー と呼びます。
ref. https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html

許可 ポリシー

IAM_Management_Console

信頼関係（信頼ポリシー）

IAM_Management_Console

信頼関係の詳細

信頼関係（信頼ポリシー）はロールを利用できる対象を表します。

AssumeRolePolicyDocument The trust policy that is associated with this role. Trust policies define which entities can assume the role. You can associate only one trust policy with a role. For an example of a policy that can be used to assume a role, see Template Examples. For more information about the elements that you can use in an IAM policy, see IAM Policy Elements Reference in the IAM User Guide.

https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html#cfn-iam-role-assumerolepolicydocument

IAM ロール

STS で一時的に発行した認証情報を使ってロールの引き受け手にリソースの操作権限を付与する仕組みです。

IAMロールは、AWSのサービスやアプリケーションに対して、一時的なAWSリソースの操作権限を与える仕組みです。
この操作権限はAWS Security Token System（AWS STS）を利用し、一時的認証情報（Temporary Security Credential）を発行するこにより実現しています。
一時的認証情報の実態は、有効期限が短いアクセスキーとシークレットキー、セッショントークンです。
AWSサービスやアプリケーションは、受け取った一時的認証情報を使いS3やKMSといった対象のAWSリソースを利用します。

– 要点整理から攻略する AWS認定セキュリティ・専門知識

ロールの引き受け

AWS IAM のロールを引受ける（AssumeRole）仕組みを整理します。

IAM ロールの 2 つのポリシー

IAM ロールには 2 種類のポリシーが存在します。

ポリシー 役割
アクセス権限ポリシー どのリソースに対して何ができるか
IAM Action List
信頼ポリシー（ AssumeRolePolicyDocument ） 誰がそのロールを引き受けられるか

アクセス権限ポリシー

  • Action：何ができるか（例：s3:GetObject）
  • Resource：どのリソースに対して許可するか（例：arn:aws:s3:::my-bucket）

信頼ポリシー

CloudFormation では AssumeRolePolicyDocument に Principal（引受を許可するエンティティ）を記載します。

ロール引受の条件:プリンシパルの種類による違い

AWS サービス（ codepipeline.amazonaws.com 等）と IAM ユーザー / ロールで必要な設定が異なります。

AWS サービスがプリンシパルの場合（ロール側のみで完結）

AWS が管理するサービスは sts:AssumeRole を呼び出す能力を AWS が内部的に持っているため、ロール側の信頼ポリシー1つで完結します。
※ STS：AWS Security Token Service 。

IAM ユーザー/ロールがプリンシパルの場合（両側の設定が必要）

IAM ユーザーは自動的に AssumeRole の権限を持たないため、プリンシパル側にも明示的なポリシーが必要です。

まとめ

プリンシパルの種類 ロール側の信頼ポリシー プリンシパル側のポリシー
AWS サービス（CodePipeline 等） 必要 不要
IAM ユーザー 必要 必要
IAM ロール（クロスアカウント等） 必要 必要

具体例 1. IAM ユーザーのスイッチロール

ロール側

  • AWS アカウント：12345678901
  • ロール： OrganizationAccountAccessRole
  • 許可：AdministratorAccess
  • 信頼関係； AWS アカウント 98765432109 の example ユーザー
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::98765432109:example"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

プリンシパル側（　IAM ユーザーが別ロールを引き受ける場合）

  • AWS アカウント 98765432109
  • ユーザー：example
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statement1",
      "Effect": "Allow",
      "Action": "sts:AssumeRole",
      "Resource": "arn:aws:iam::12345678901:role/OrganizationAccountAccessRole"
    }
  ]
}

IAM ユーザー（ example ）に上記インラインポリシーを付与することで、OrganizationAccountAccessRole（　AdministratorAccess　）を引き受けて S3 を操作できるようになります。

具体例 2. AWS サービスが引き受ける場合

ロール側（　CloudFormation　）

MyBucketRole:
  Type: "AWS::IAM::Role"
  Properties:
    RoleName: MySampleBucketRole
    AssumeRolePolicyDocument:
      Version: "2012-10-17"
      Statement:
        - Effect: "Allow"
          Principal:
            Service:
              - "codepipeline.amazonaws.com"   # AWS サービスを信頼
          Action:
            - "sts:AssumeRole"
    Policies:
      - PolicyName: "CodePipelineS3AccessPolicy"
        PolicyDocument:
          Version: "2012-10-17"
          Statement:
            - Action:
                - s3:ListAllMyBuckets
              Resource: "arn:aws:s3:::*"
            - Action:
                - s3:GetObject
                - s3:PutObject
                - s3:DeleteObject
              Resource: "arn:aws:s3:::my-sample-bucket-unique-name"

この設定では codepipeline.amazonaws.com のみを信頼しています。 codepipeline.amazonaws.com は前述のように AWS 管理サービスなので sts:AssumeRole を呼び出す能力を AWS が内部的に持っているため、ロール側の信頼ポリシー1つで完結します。 また IAM ユーザーがアクセスキーで直接 my-sample-bucket-unique-name を直接操作することはできません。

具体例 3. クロスアカウントロールのスイッチ

信頼関係（信頼ポリシー）についてクロスアカウントロール（ユーザーからのみスイッチできるIAMロール）を例に説明する。 AWSの薄い本 IAMのマニアックな話 p39

クロスアカウントロールのスイッチ元の制限は Condition（条件） ではなく Principal（信頼関係） を利用する。 アカウントAAAAAAAAAAAのexampleロールからアカウントBBBBBBBBBBBのbarロールにスイッチロールする例。

アカウントAAAAAAAAAAA側のexampleロール

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "sts:AssumeRole"
            ],
            "Resource": [
                "arn:aws:iam::BBBBBBBBBBB:role/bar"
            ],
            "Effect": "Allow"
        }
    ]
}

アカウントBBBBBBBBBBBのbarロール

信頼関係の例（JSON）

{
  "Version": "2012-10-17",
  "Statement": [
      {
        "Effect": "Allow",
        "Principal": {
            "AWS": "arn:iam::AAAAAAAAAAA:role/example"
        },
        "Action": "sts:AssumeRole",
      }
  ]
}

アクセス権限AdministratorAccessの例

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

具体例 4. 信頼関係にサービス（例 ecs-tasks.amazonaws.com）を設定

ECSアプリケーションの信頼関係の例です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": [
          "ecs-tasks.amazonaws.com"
        ]
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

上記の信頼関係をCloudFormationdeで定義すると以下のようになります。 参考に許可も設定しています（anagedPolicyArns）。

AppRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: "Allow"
            Principal:
              Service:
              - "ecs-tasks.amazonaws.com"
            Action:
            - "sts:AssumeRole"
      Path: "/"
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonSQSFullAccess
        - arn:aws:iam::aws:policy/CloudWatchLogsFullAccess

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_elements_principal.html

パーミッションバウンダリー

バウンダリーは、IAMユーザーまたはIAMロールに対するアクセス制限として動作します。 付与した権限とBoundaryで許可した権限と重なる部分のみ有効な権限として動作します。

STS AWS Security Token Service

AWS Security Token Service (AWS STS) を使用して、AWS リソースへのアクセスをコントロールできる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供することができます。一時的セキュリティ認証情報の機能は、IAM ユーザーが使用できる長期的なアクセスキー認証情報とほとんど同じですが、次の相違点があります。

https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_temp.html

ユースケース

ECSコンテナ内のアプリケーションがSQSにアクセスする場合を考える。

Bad

  • コンテナ内のアプリケーション用にユーザーを作成してSQSのアクセス件を付与
  • ↑のユーザーのキー、シークレットキーでSQSにアクセス

Good

  • ロールを使用してタスク（コンテナ）にタスクロールに付与
  • コンテナアプリSTSを使用してSQSにアクセス
  TaskRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: "Allow"
            Principal:
              Service:
              - "ecs-tasks.amazonaws.com"
            Action:
            - "sts:AssumeRole"
      Path: "/"
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonSQSFullAccess
        - arn:aws:iam::aws:policy/CloudWatchLogsFullAccess

CloudFormation

AWS::IAM::Role

CloudFormationのAWS::IAM:RoleはJSONポリシーを使って記載される。

  • JSON ポリシー
  • https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_elements.html

備考

  • principal：主要な、認証の対象、当事者
  • assume：引き受ける
  • sts:AWS Security Token Service (AWS STS)
  • 認証（Authentication）：本人確認
  • 認可（Authorization）：リソースに対する使用権限付与

Ref.