CloudFormationのリファレンスにポリシーが掲載されていない？ので以下を参照する。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_policies_elements.html
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
次のポリシーの例では、s3:PutObject および s3:PutObjectAcl アクセス許可を複数の AWS アカウント に付与し、これらのオペレーションのリクエストに public-read という既定のアクセスコントロールリスト (ACL) が含まれることを要求しています。
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"AddCannedAcl",
"Effect":"Allow",
"Principal": {"AWS": ["arn:aws:iam::111122223333:root","arn:aws:iam::444455556666:root"]},
"Action":["s3:PutObject","s3:PutObjectAcl"],
"Resource":"arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
"Condition":{"StringEquals":{"s3:x-amz-acl":["public-read"]}}
}
]
}
大きく以下から構成される。
アクセス権（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