Assume Role
通常はアクセスできないAWSリソースへのアクセスに使用できる一時的なセキュリティ認証情報のセットを取得する権利を付与
わかりそうでわからないため、色々整理したく
ポリシーとは
以下の基本となIAMポリシーの要素をJSON形式で記述またはビジュアルで、アクセス制御を実現する
| No | IAMポリシー要素 |
|---|---|
| 1 | 誰が |
| 2 | どのAWSサービスへ |
| 3 | どんな操作を |
| 4 | 許可する/許可しない |
| 5 | どんなとき |
| No | ポリシーのアタッチ先 |
|---|---|
| 1 | ユーザー |
| 2 | グループ |
| 3 | ロール |
| No | 各種のアイデンティティベースのポリシー | 説明 |
|---|---|---|
| 1 | AWS マネージドポリシー | AWS 管理ポリシーは、ユーザー、グループおよびロールに適切な権限を割り当てるのに適している。ただし、AWS 管理ポリシーで定義されているアクセス許可は変更できない。アタッチ先は、 |
| 2 | カスタマー管理ポリシー | これらのカスタマー管理ポリシーは、特定の目的に合わせてポリシーを作成し、何度でも変更および更新が可能です。 |
| 3 | インラインポリシー | カスタマーポリシーとほぼ同じであるが、大きな違いとして使いまわしは不可 |
#アイデンティティベース
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Allow",
"Action": [
"s3:List*",
"s3:Get*"
],
"Resource": "arn:aws:s3:::xxxxxxxxx/*"
}
]
}
#リソースベースポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Statement1",
"Effect": "Allow",
"Action": [
"s3:List*",
"s3:Get*"
],
"Resource": "arn:aws:s3:::xxxxxxxxx/*"
}
]
}
#リソースベースポリシー
#信頼されたエンティティ
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
違いについて
#アイデンティティベース
IAM ユーザー、グループ、ロールにアタッチするポリシー
どのAWSサービスへ、どんな動作を、許可する/許可しないをポリシーに定義する
#リソースベースポリシー
誰が、どのAWSサービスへ、どんな操作を許可する/許可しないをポリシーに定義する
また、ロールにポリシーをアタッチ後にAWSサービスへロールをアタッチする必要がある
#信頼されたエンティティ
AWSリソースにアクションを要求できるIAMユーザー、ロール、フェデレーションユーザー、またはアプリケーションを指し、「誰が」という要素になり、Principalは、リソースまたはAWSアカウントが対象となる
JSONで見ると、Principalは、ec2.amazonaws.comになり、「誰が」を指す。
本題のAssume Roleのsts:AssumeRoleがアクションとして認可されている。
つまり、エンティティのEC2がSTSのAssumeRoleを使用して、認可されているリソースベースポリシーのポリシーを使用していることになります。
認可されていますが、認証されていないため、sts:AssumeRoleを使用する必要があります
stsとは
一時的な認証情報を生成するAWSサービスです
EC2に一時的な認証情報を生成することで、認可された操作を実行できます
備考
認証・認可を必要とするエンティティ側(アクセスする側)にロールを作成し、ポリシーをアタッチするだけで使用できることがわかりました
そのため、アカウントIDなどをAssumeroleとして指定することがあるため、違和感は感じましたがパスワード、ワンタイムパスワード等で認証後にアカウントIDを確認できるため、セキュリティ的に問題ないと個人的に整理できました
AWSサービスの裏側が少し気になります