【AWS】触って理解するIAMユーザー、ロール、AssumeRole

Posted at 2024-12-01

はじめに

業務でほどよくAWSは使用しますが、管理側(?)は経験がありません。
AWSの認定資格の勉強でも、結構アカウント管理周りは机上の理解でした。

そこで、今回はアカウント管理で重要なAssumeRoleについて、実際に触って整理していこうと思います。

はじめに
前提理解
AssumeRole
まとめ

前提理解

ここは前提として、サクッとまとめます。

IAMユーザーだけで管理する

誰になんの権限をもたせるか、、、複雑ですね。

ロールを使用する

さて、これをロールを使用して綺麗にしていきましょう。

前提のまとめ

ユーザーだけで権限管理しようとするととても複雑なので、ロールごとにまとめることでシンプルになりました。

これによって

ユーザー
- 誰がいるか
ロール
- どんな案件（ロール）があるか
- それぞれ何ができるか

が整理できました。

このユーザーとロールを紐付けるために、AssumeRoleを使用します。

では、ユーザーとロールを紐づけて、AssumeRoleの実際の動きを見ていきましょう。

AssumeRole

ケース

今回は同一のアカウントから行います。実際には別アカウントになったりしますね。

ユーザーA
- ロール1へのAssumeRoleのみ可能
ロール1
- ユーザーAからのAssumeRoleを許可
- Lambdaへのフルアクセスを許可

やってみること

以下の構成を実際にやってみます。

ユーザーA

ユーザーAには以下のポリシーを設定しています。

詳細は省きますが、とにかくAssumeRoleしか許可していない、という意味です。

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

前述の通り、AssumeRole以外の権限を持っていないので、ユーザーAでのログイン時には、Lambdaにアクセスできません。

ロール1

続いて、ロール1には以下を設定しています。

信頼ポリシー

ユーザーAからのAssumeRoleのみ許可しています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::XXXXXXXXXXXX:user/userA"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}