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