MENU
AWSを中心としたクラウドインフラ技術サイト
  1. ホーム
  2. AWS
  3. 【AWS】iam:PassRole と sts:AssumeRole の違いについて詳しく

【AWS】iam:PassRole と sts:AssumeRole の違いについて詳しく

AWS AWS認定試験 IAM

iam:PassRole と sts:AssumeRole は、同じ IAM ロールを扱いますが、役割がまったく違います。

権限意味主な利用者
iam:PassRole「このロールをAWSサービスに使わせる設定をしてよい」人、Terraform、AWS Configなどの設定実行者
sts:AssumeRole「実際にそのロールになり、一時的な認証情報を取得してよい」SSM、EC2、Lambda、人、別のIAMロールなど

一言で表すと、

iam:PassRole
＝ IAMロールを使うサービスを指定する権限 ← これ使ってもいいよ

sts:AssumeRole
＝ 実際にそのIAMロールとして動く権限  ← これが使えるんだ

です。

会社の制服に例えると

IAMロールを「特定の作業をするための制服」と考えてみます。

たとえば、Config で CloudTrail が無効にされた場合、自動的に有効にするルールがあり、それをする（CloudTrail を有効にする）為に次の制服があるとします。

SSM 自動修復担当の制服
この制服を着ると、CloudTrail を有効化できる

このとき、3人の登場人物がいます。

  1. AWS Config
    • SSMに自動修復を依頼する人
  2. Systems Manager Automation
    • 実際に自動修復を行う人
  3. Automation実行ロール
    • CloudTrailを修復する権限が入った制服

流れは次のようになります。

AWS Config
   │
   │ iam:PassRole
   │ 「SSMさん、この制服を使って作業してください」 ← ConfigがSSMに制服を渡す
   ▼
Systems Manager Automation
   │
   │ sts:AssumeRole
   │ 「この制服を実際に着用します」 ← SSMが制服を着れる
   ▼
Automation実行ロール
   │
   │ cloudtrail:StartLogging
   ▼
CloudTrailを修復

iam:PassRole では、AWS Config 自身がそのロールになるわけではありません。

AWS Config は、

「Systems Manager に、この実行ロールを使用させてもよい」

という許可を持っているだけです。

実際に実行ロールを引き受けるのは、Systems Manager です。

iam:PassRole とは

基本的な意味

iam:PassRole は、

AWS サービスの設定時に、使用させる IAM ロールを指定する権限

です。

AWS の API にロール ARN を渡すと、AWS 側が「この操作を行った人は、このロールをサービスに渡す権限を持っているか」を確認します。

重要なのは、PassRole は独立した API ではないという点です。

たとえば、EC2 に IAM ロールを設定して起動する場合、実際に呼ばれる API は次のようなものです。

ec2:RunInstances

そのリクエストの中に、IAM ロールの情報が入っています。

{
  "ImageId": "ami-xxxxxxxx",
  "IamInstanceProfile": {
    "Arn": "arn:aws:iam::123456789012:instance-profile/MyEC2Role"
  }
}

AWSは内部的に、次の2つを確認します。

1. この人は ec2:RunInstances を実行できるか
2. この人は指定されたロールを iam:PassRole できるか

したがって、iam:PassRole だけを許可してもEC2は起動できません。

ec2:RunInstances     → EC2 を起動する権限
iam:PassRole         → 起動する EC2 にロールを設定する権限

という別々の権限が必要です。

iam:PassRole の例

以下の例を見てみます。

{
  "Action": "iam:PassRole",
  "Resource": "*",
  "Effect": "Allow",
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": "ssm.amazonaws.com"
    }
  }
}

Action

"Action": "iam:PassRole"

このポリシーを持つ主体は、IAM ロールを AWS サービスに渡せます。自分自身がそのロールを引き受ける権限ではありません。あくまでも渡せるだけです。

Resource

"Resource": "*"

これは、「アカウント内のすべての IAM ロールを渡せる」という広い指定です。

セキュリティ上は、次のように実行ロールを限定する方が安全です。

"Resource": "arn:aws:iam::123456789012:role/ConfigRemediationRole"

権限が強すぎる IAM ロールをサービスへ渡せないように、Resource で渡せるロールを限定しましょう。

Condition

"Condition": {
  "StringEquals": {
    "iam:PassedToService": "ssm.amazonaws.com"
  }
}

これは、「ロールを渡せる相手は Systems Manager だけ」という制限です。

iam:PassedToService とは

iam:PassedToService とはiam:PassRole で「どのAWSサービスにロールを渡してよいか」を制限するための条件キーです。

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": "ec2.amazonaws.com"
    }
  }
}

これは、「このユーザーは IAM ロールを渡すことができる。ただし、渡し先がEC2の場合だけ許可する」という意味です。

ただしiam:PassRole では、まず Resource で「渡してよいロール」を限定する方が重要です。

一番安全なのは、以下のようにResource と iam:PassedToService の両方で絞ることです。

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::123456789012:role/S3ReadRole",
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": "ec2.amazonaws.com"
    }
  }
}

なぜならサービスを絞ることで、以下のようにより安全にできるからです。

S3ReadRole         → EC2      ○
S3ReadRole         → Lambda   ×
AdministratorRole  → EC2      ×
AdministratorRole  → Lambda   ×

PassRole は認証情報を取得しない

iam:PassRole を実行しても、実行者には次のような一時認証情報は渡されません。

AccessKeyId
SecretAccessKey
SessionToken

また、実行者自身がそのロールに切り替わるわけでもありません。

あくまで、

AWSサービスにこのロールを関連付けてよい

という設定権限です。

さらに、PassRole は独立した API 呼び出しではないため、CloudTrail に PassRole というイベントが直接記録されるわけではありません。確認するときは、CreateFunction や RunInstances など、ロールを指定した元の API イベントを調べます。

sts:AssumeRole とは

sts:AssumeRole は、「IAM ロールを実際に引き受け、そのロールとして動くための一時認証情報を取得する操作」です。

AssumeRole が成功すると AWS STS から、主に以下のような一時認証情報次が返されます。

AccessKeyId
SecretAccessKey
SessionToken
Expiration

例えば、以下のようなイメージです。

AccessKeyId:
  ASIAxxxxxxxxxxxx

SecretAccessKey:
  xxxxxxxxxxxxxxxx

SessionToken:
  xxxxxxxxxxxxxxxxxxxxxxxxxx

Expiration:
  2026-08-08 01:00

この認証情報を使用すると、そのロールに設定された権限で AWS API を実行できます。

AssumeRole の API リファレンスでも、一時的なアクセスキー、シークレットアクセスキー、セッショントークンを返す操作と説明されています。

たとえば、次のロールがあるとします。

Role名: ProductionReadOnlyRole

このロールに以下の権限が設定されています。

{
  "Effect": "Allow",
  "Action": [
    "ec2:DescribeInstances",
    "rds:DescribeDBInstances"
  ],
  "Resource": "*"
}

利用者がこのロールを AssumeRole すると、そのセッションでは次の操作ができます。

EC2インスタンスの参照
RDSインスタンスの参照

ただし、次の操作はできません。

EC2の停止
RDSの削除

何ができるかは、引き受けたロールの権限ポリシーで決まります。

sts とは何なのか

正式名称は、

AWS STS
=
AWS Security Token Service

です。

AssumeRole は STS が提供している API の1つなので、sts:AssumeRole という名前になっています。

分解すると、

sts
  ↓
Security Token Service

AssumeRole
  ↓
Roleを引き受ける

です。

IAMロールには2種類のポリシーがある

ここが非常に重要です。IAM ロールには、主に次の2種類のポリシーがあります。

① 信頼ポリシー

誰がこのロールを引き受けられるか

を定義します。

② 権限ポリシー

ロールを引き受けた後、何ができるか

を定義します。

ロールには「誰が引き受けられるかを定義する信頼ポリシー」と「引き受けた後に何ができるかを定義する権限ポリシー」の両方が必要です。

  • 誰が引き受けられるか定義されていない 　←　誰もロールを引き受けられない
  • 引き受けた後に何ができるか定義されていない　←　ロールを引き受けても何もできない

信頼ポリシーの例

Systems Manager が引き受けるロールなら、次のようになります。

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

これを日本語にすると、次の意味です。

Effect:
  許可する

Principal:
  Systems Managerに

Action:
  このロールをAssumeRoleすることを

つまり、

Systems Manager がこのロールを引き受けることを許可する

という設定です。

ここにある sts:AssumeRole は、

このロール自身にSTSを実行する権限を与えている

わけではありません。

これはロールの入口に設定されている、

誰をロールの中に入れてよいか

という許可です。

Systems Manager Automation 用ロールについても、AWS公式例では、信頼ポリシーの Principal を ssm.amazonaws.com、Action を sts:AssumeRole としています。

権限ポリシーの例

自動修復で CloudTrail を開始する場合、実行ロールには例えば次のような権限が必要です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "cloudtrail:StartLogging",
      "Resource": "arn:aws:cloudtrail:ap-northeast-1:123456789012:trail/example-trail"
    }
  ]
}

これは、

Systems Manager がこのロールを引き受けた後、対象の CloudTrail を開始できる

という意味です。

信頼ポリシーだけでは、CloudTrail の修復はできません。

信頼ポリシー
  → SSMがロールを引き受けてよい

権限ポリシー
  → 引き受けたSSMがCloudTrailを操作してよい

という関係です。

Automation ランブックから EC2、S3 など別の AWS サービスを操作する場合、その操作権限を Automation 実行ロールに追加する必要があります。

AWS Config の自動修復の例

今回の例えの AWS Config と Systems Manager のケースに当てはめます。

AWS Config の自動修復は、非準拠リソースを検出した後、Systems Manager Automationランブックを使って修復します。

たとえば、次のようなルールを考えます。

Configルール:
  CloudTrailが有効になっていること

違反:
  CloudTrailが停止している

自動修復:
  SSM AutomationでCloudTrailを開始する

登場する権限は、大きく3段階です。

段階1：AWS Config が SSM Automationを開始する

Config 側には、SSM Automation の実行を開始する権限が必要です。

概念的には次のような権限です。

{
  "Effect": "Allow",
  "Action": "ssm:StartAutomationExecution",
  "Resource": "*"
}

これは、

Systems Manager Automationを起動してよい

という権限です。

段階2：実行ロールをSSMに渡す

Config は、SSM Automation に対して次のロールを指定します。

AutomationAssumeRole:arn:aws:iam::123456789012:role/ConfigRemediationRole

AutomationAssumeRoleとは

AutomationAssumeRole は、AWS Systems Manager Automation が処理を実行するときに使用する IAM ロールを指定するためのパラメータ名です。

最も重要なのは、次の点です。

AutomationAssumeRole 自体がIAMロールなのではありません。IAMロールのARNを入れるための「項目名」です。

つまり、「Systems Manager Automation が、どの IAM ロールを引き受けて実行するか」を指定しています。

例えば、AWS-ASGEnterStandby を確認すると、AutomationAssumeRole は1つのオプショナルなパラメータとなっています。

コンテンツを確認すると以下が確認できます。

{
  "schemaVersion": "0.3",
  "assumeRole": "{{AutomationAssumeRole}}",
  "description": "Change the Standby state of an EC2 instance in an autoscaling group",
  "parameters": {
    "InstanceId": {
      "type": "String",
      "description": "(Required) ID of EC2 Instance to change standby state for within ASG"
    },

"assumeRole": "{{AutomationAssumeRole}}",とありますが、これは、AutomationAssumeRole に入力された IAM ロールを、実行ロールとして使用するというランブック本体の指定です。

段階3：Systems Managerが実行ロールを引き受ける

次に Systems Manager が、実行ロールに対して実際に AssumeRole します。

そのため、実行ロールの信頼ポリシーには次の設定が必要です。

{
  "Effect": "Allow",
  "Principal": {
    "Service": "ssm.amazonaws.com"
  },
  "Action": "sts:AssumeRole"
}

これによって Systems Manager は、一時認証情報を取得します。

AccessKeyId
SecretAccessKey
SessionToken

そして、その一時認証情報を使って CloudTrail を修復します。

cloudtrail:StartLogging

全体の流れ

① AWS Configが違反を検出
        │
        ▼
② Configがssm:StartAutomationExecutionを実行
        │
        │ Configにはiam:PassRoleが必要
        │
        ▼
③ SSMにConfigRemediationRoleが指定される
        │
        ▼
④ SSMがsts:AssumeRoleを実行
        │
        │ ロールの信頼ポリシーで
        │ ssm.amazonaws.comを許可
        ▼
⑤ SSMが一時認証情報を取得
        │
        ▼
⑥ 実行ロールの権限を使って
   cloudtrail:StartLoggingを実行

EC2 が S3 バケットを閲覧する例

もう1つ例を挙げます。

今度は EC2 インスタンスが S3 バケットを閲覧する例です。

次の IAM ロールがあるとします。

S3ReadRole

このロールには、S3 を閲覧する権限があります。

S3ReadRoleの権限
  └─ S3のファイルを読むことができる

そして、この IAM ロールの信頼ポリシーでは、EC2 が許可されています。

{
  "Effect": "Allow",
  "Principal": {
    "Service": "ec2.amazonaws.com"
  },
  "Action": "sts:AssumeRole"
}

これは、「EC2は S3ReadRole を引き受けることができる」という意味です。

ユーザーが EC2 を作る

そしてユーザーが AWS 管理画面より EC2 を作るとします。

そのときに、この IAM ロールを設定します。

ユーザー（作成者）
  ↓
EC2を作成
  ↓
S3ReadRoleをEC2に設定

このとき、作成者に必要なのが、iam:PassRole の権限です。

ここで AWS は、EC2を作成しようとしているユーザーに、S3ReadRole をEC2へ設定するための iam:PassRole 権限が付与されているかを確認します。

例えば、ユーザーに次の権限が付与されているとします。

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "arn:aws:iam::123456789012:role/S3ReadRole"
}

この場合、ユーザーは S3ReadRole をEC2に設定できます。

これが iam:PassRole です。

PassRole してもユーザーの権限は変わらない

ここが重要です。

ユーザーが、S3ReadRole を EC2 に設定したからといって、ユーザー自身が S3ReadRole になるわけではありません。

ユーザー
  │
  │ iam:PassRole
  │
  │ S3ReadRoleをEC2に設定
  ▼
EC2
  └─ S3ReadRole

ユーザーに iam:PassRole 権限があるというのは、「S3ReadRoleをEC2に設定できる」という意味です。

「S3ReadRole の権限を自分自身が使える」という意味ではありません。

EC2が S3ReadRole を実際に使う

EC2 が起動します。

EC2 には先ほど、S3ReadRole を設定しました。

今度はEC2が、そのロールを実際に利用します。

EC2
  │
  │ S3ReadRoleを引き受ける
  │
  │ sts:AssumeRole
  ▼
S3ReadRole

S3ReadRole の信頼ポリシーには、

{
  "Principal": {
    "Service": "ec2.amazonaws.com"
  },
  "Action": "sts:AssumeRole"
}

と書かれていました。

つまり、「EC2には S3ReadRole を引き受けることが許可されている」わけです。

EC2がS3を操作できるようになる

EC2が S3ReadRole を引き受けると、EC2上のプログラムは S3ReadRole の権限を利用できます。

例えば EC2 上で、

aws s3 ls

を実行すると、

EC2
  ↓
S3ReadRoleの認証情報を利用
  ↓
S3ReadRoleの権限でS3へアクセス

となります。

全体像

① ユーザーがEC2を作る
        │
        │
② S3ReadRoleをEC2に設定する
        │
        │ ユーザーに
        │ iam:PassRole が必要
        ▼
③ EC2が起動
        │
        │
④ EC2がS3ReadRoleを引き受ける
        │
        │ sts:AssumeRole
        ▼
⑤ EC2がS3ReadRoleの権限を利用
        │
        ▼
⑥ S3を読み取る

iam:PassRole は「設定する側」の権限

例えば、ユーザーが AWS 管理画面より EC2 を作るとき、

IAMロール：
[S3ReadRole]

と選択したとします。

この操作をするのはユーザーです。

そのため、ユーザーに必要なのが、iam:PassRole です。

正確には、「ユーザーには S3ReadRole を EC2 に設定するための iam:PassRole 権限が必要です」となります。

sts:AssumeRole は「実際にロールを使う側」

その後、ロールを実際に利用するのは EC2 です。

EC2
  ↓
S3ReadRoleを引き受ける

そのため、S3ReadRole の信頼ポリシーで、「EC2がこのロールを引き受けることを許可」します。

その部分が、

"Action": "sts:AssumeRole"

です。

iam:PassRole の注意点

例えば、次の条件がそろっていると、一般ユーザーが EC2 を経由して管理者権限を使えるため、実質的な権限昇格になります。

一般ユーザー
  ├─ EC2を起動できる
  ├─ 管理者ロールをEC2にPassRoleできる
  └─ EC2上で任意の処理を実行できる
          ↓
管理者ロールの権限でAWS APIを実行

iam:PassRole の対象を * にすると、任意の IAM ロールを EC2 へ渡せるため、特定のロール ARN に限定する必要があります。

具体例

一般ユーザー DeveloperUser に、次の権限があるとします。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:RunInstances",
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": "iam:PassRole",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "iam:PassedToService": "ec2.amazonaws.com"
        }
      }
    }
  ]
}

そして、次の管理者ロールが既に存在するとします。

AdministratorRole

AdministratorRole の信頼ポリシー

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

権限ポリシー

たとえば AWS 管理ポリシーの AdministratorAccess が付いているとします。

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

この状態では、DeveloperUser は次のような EC2 を起動できます。

EC2インスタンス
  └─ AdministratorRoleを設定

iam:PassedToService が ec2.amazonaws.com なので、管理者ロールを SSM や Lambda に渡すことはできませんが、EC2 には渡せます。

そして、AdministratorRole の信頼ポリシーも EC2 を許可しています。

したがって、次の両方が成立します。

DeveloperUser
  → AdministratorRoleをEC2にPassRoleできる

EC2
  → AdministratorRoleをAssumeRoleできる

EC2上では何が起きるのか

EC2 に IAM ロールを設定すると、EC2 上のプログラムはインスタンスメタデータサービスから、そのロールの一時認証情報を取得できます。

AWS CLI や AWS SDK は、この一時認証情報を自動的に取得して使用します。

そのため、EC2 上で次のコマンドを実行したとします。

aws sts get-caller-identity

実行主体は以下のように AdministratorRole になります。

arn:aws:sts::123456789012:assumed-role/AdministratorRole/i-0123456789abcdef0

つまり、以下のような AWS CLI コマンドもAdministratorRoleの権限で実行されることになります。

aws s3 ls
aws ec2 describe-instances
aws iam list-roles

AdministratorRole がほぼすべての操作を許可していれば、EC2 上からほぼすべての AWS API を実行できます。

つまり、DeveloperUser 自身の権限は弱いままでも、

DeveloperUser本人
  → 管理者権限なし

DeveloperUserが作ったEC2
  → 管理者権限あり

という状態になります。

ユーザーは EC2 を操作することで、間接的に管理者権限を使用できるわけです。

aws sts get-caller-identity コマンド

AWS に対して「いま、このリクエストに使っている認証情報は、誰のものですか？」と確認するコマンドです。

AWS は、使用された認証情報を調べて、IAM ユーザー名、IAM ロール名、AWS アカウントIDなどを返します。

IAM ユーザーのアクセスキーを使っている場合は、次のようになります。

{
  "UserId": "AIDAEXAMPLE123456789",
  "Account": "123456789012",
  "Arn": "arn:aws:iam::123456789012:user/yamadataro"
}

安全な設定

まずは危険な例です。

危険な例

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": "ec2.amazonaws.com"
    }
  }
}

改善例

EC2に渡してよいロールを具体的に限定します。

{
  "Effect": "Allow",
  "Action": "iam:PassRole",
  "Resource": [
    "arn:aws:iam::123456789012:role/ec2/DeveloperApplicationRole",
    "arn:aws:iam::123456789012:role/ec2/MonitoringAgentRole"
  ],
  "Condition": {
    "StringEquals": {
      "iam:PassedToService": "ec2.amazonaws.com"
    }
  }
}

AWS AWS認定試験 IAM
AWS IAM

関連記事