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.

出典

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 ユーザーが使用できる長期的なアクセスキー認証情報とほとんど同じですが、次の相違点があります。

出典

ユースケース

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ポリシーを使って記載される。

備考

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

Ref.