【AWS】iam:PassRoleとsts:AssumeRoleの違い

AWSでロールを扱う際、iam:PassRolests:AssumeRole の両方が説明に出てくることが多い。どちらもロールを使えるようにするために必要なアクションだが、いまいち違いがわからなかったので改めて調べてみた。

iam:PassRole

まず iam:PassRole は、ユーザに対して付与するアクセス許可ポリシーで指定できるアクションである。
例えばAWS Batchを使うとき、ジョブの内容に応じたアクセス許可ポリシーをロールに付与しておき、そのロールをAWS Batchで指定しておく必要がある。ジョブが作成されると、AWS Batchがロールを使ってジョブの内容を実行する。
このとき、もしユーザ自身が aws batch submit-job コマンド等でジョブを登録する場合、 iam:PassRole アクション内で当該ロールをResourceに指定したポリシーを作り、それをユーザにアタッチする必要がある。これを行わないと、ロールをサービスに渡すことができない。 AWS Batchの公式ドキュメントにある例では、iam:PassRole アクションはアクセス許可ポリシー内で以下のように記述されている。

docs.aws.amazon.com

{
    "Effect": "Allow",
    "Action": [
        "iam:PassRole"
    ],
    "Resource": [
        "arn:aws:iam::<aws_account_id>:role/TestRole"
    ],
    "Condition": {
        "StringEquals": {
            "iam:PassedToService": [
                "batch.amazonaws.com"
            ]
        }
    }
}

このポリシーをアタッチされたユーザは、 Resource で指定されたロールをアタッチできるようになる。加えて、 IAM条件キー iam:PassedToService を使うことで、アタッチの対象にできるサービスがAWS Batchのみに制限されている。

docs.aws.amazon.com

(補足だが、ロールをアタッチできる対象はAWSサービスのみではない。他のAWSアカウントのユーザにロールを付与して、特定のアクションをクロスアカウントで行ってもらうという使い方もある)

個人開発をしている場合、 iam:PassRole なんて指定した覚えがないという人も多いかもしれない。個人用環境でAWSを触るときによく使われる AdministratorAccess ポリシーでは、全てのアクションが全てのリソースに対して許可されているので、 iam:PassRole を意識する必要はなくなっている。また、各サービスごとにあらかじめ用意されているアクセス許可ポリシーを使っている場合も、既に iam:PassRole が許可されていることが多い。 AWS Batchであれば、 AWSBatchFullAccess ポリシー内で、Batch関連のあらかじめ用意されたロールについて iam:PassRole が許可されている。

docs.aws.amazon.com

sts:AssumeRole

sts:AssumeRole は、ロールに対して付与する信頼ポリシーの中で指定できるアクションである。この「信頼ポリシー」は iam:PassRole に登場した「アクセス許可ポリシー」とは概念が異なる。アクセス許可ポリシーがアイデンティティベースのポリシーなのに対し、信頼ポリシーはリソースベースのポリシーの一種である。アイデンティティベースのポリシーにはリソースネーム(ARN)が付与され、様々なアイデンティティに使い回してアタッチすることが可能だが、リソースベースは特定のリソースと1対1・不可分の関係である。

docs.aws.amazon.com

sts.AssumeRole は、そのロールをどのリソースにAssume(引き受けさせる)できるかを定義する。もし Assume を管理するという概念がなかった場合、例えばAWSサービスAのために強い権限を持つロールを作ったとして、そのロールを別のAWSサービスBに与えることができてしまう。その場合、サービスBが意図しない強い権限を持ち、セキュリティ上の問題となりうる。そこで、そのロールをどのリソースに渡すことができるか、ロール自体と不可分のインラインポリシーとして定義できるようになっている。もちろん sts.AssumeRole を何も定義しない場合、そのロールはどのリソースにも渡せない。
iam:PassRole の場合と同様に、AWSによってあらかじめ用意されているロールには、既に sts:AssumeRole が定義されている。例えば AWSBatchServiceRole には以下の信頼ポリシーが付与されており、もしこのポリシーがない場合は改めて作成してからロールを使うよう案内されている。

docs.aws.amazon.com

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

この信頼ポリシーにより、 AWSBatchServiceRoleAWS Batch以外のAWSサービスには引き受けられないようになっている。
なお、 sts:AssumeRole のPrincipalはAWSサービスのみではなく、他のAWSアカウントのユーザなどにもできる。

iam:PassRolests.AssumeRole により、「ユーザはどのロールを付与することができるか」「そのロールはどのリソースに付与されることができるか」の両面からロールを管理できるようになっている。ロールは通常であれば持っていない権限を一時的に付与するものであるため、強い権限が意図しない相手に渡らないようにするための仕組みが必要だったのだろう。

ロールを作って使うときの全体像は、以下のドキュメントがわかりやすい。
docs.aws.amazon.com