CloudFormationのAWS::IAM:RoleはJSONポリシーを使って記載される。
assume：引き受けるsts:AWS Security Token Service (AWS STS)※ AWS Organizations（組織アカウント） 複数のアカウントを管理
IAM アイデンティティ (ユーザー、グループ、またはロール) に埋め込まれたポリシーです。つまり、ポリシーは本質的にアイデンティティの一部です。
※ ARNを持つポリシーをスタンドアロンポリシーと呼ぶ
ref. https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_managed-vs-inline.html
管理ポリシーとインラインポリシーを IAM アイデンティティ (ユーザー、ユーザーのグループ、ロール) にアタッチします。アイデンティティベースのポリシーでは、アクセス許可はアイデンティティに付与されます。
インラインポリシーをリソースにアタッチします。リソースベースのポリシーとして最も一般的な例は、Amazon S3 バケットポリシーと IAM ロールの信頼ポリシーです。リソースベースのポリシーでは、アクセス許可は、ポリシーで指定されているプリンシパルに付与されます。プリンシパルは、リソースと同じアカウントか、別のアカウントになります。
ref. https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies.html
大きく以下から構成される。
アクセス権（IAMポリシー）：何ができるか信頼関係（信頼ポリシー）：このロールにスイッチできるのはだれか（サービスも含む）IAMロールはアイデンティティベースポリシーを表すアクセス権とこのロールにスイッチで可能な対象かを表す信頼関係で構成される。
アイデンティティベースポリシーからなる。
このロールにスイッチ可能な対象を表す。
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.
https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-iam-role.html#cfn-iam-role-assumerolepolicydocument
信頼関係（信頼ポリシー）についてクロスアカウントロール（ユーザーからのみスイッチできるIAMロール）を例に説明する。
AWSの薄い本 IAMのマニアックな話 p39
クロスアカウントロールのスイッチ元の制限はCondition（条件）ではなくPrincipal（信頼関係）を利用する。
信頼関係の例（JSON）
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:iam::{{アカウントID}}:user/{{username}}"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
上記はクロスアカウントを例にしたが、以下CloudFormationやCodePipelineなどAWSサービスに付与場合も多い。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": [
"codepipeline.amazonaws.com"
]
},
"Action": "sts:AssumeRole"
}
]
}
例えばCloudFormationで信頼ポリシーを設定するテンプレート
CodePipelineRole:
Type: "AWS::IAM::Role"
Properties:
RoleName:
Fn::Sub: CodePipelineRole-${AWS::StackName}
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
-
Effect: "Allow"
Principal:
Service:
- "codepipeline.amazonaws.com"
Action:
- "sts:AssumeRole"
信頼関係が上記のように設定されている場合は、CodePipelineがこのロールにスイッチできる。
# CloudFormationの例
DeployPipeline:
Type: "AWS::CodePipeline::Pipeline"
Properties:
RoleArn:
Fn::GetAtt: [ CodePipelineRole, Arn ]
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_elements_principal.html
バウンダリーは、IAMユーザーまたはIAMロールに対するアクセス制限として動作します。 付与した権限とBoundaryで許可した権限と重なる部分のみ有効な権限として動作します。
AWS Security Token Service (AWS STS) を使用して、AWS リソースへのアクセスをコントロールできる一時的セキュリティ認証情報を持つ、信頼されたユーザーを作成および提供することができます。一時的セキュリティ認証情報の機能は、IAM ユーザーが使用できる長期的なアクセスキー認証情報とほとんど同じですが、次の相違点があります。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_credentials_temp.html
ECSコンテナ内のアプリケーションが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