Terraform - 假设角色策略 - 与标准 IAM 策略类似但略有不同 [英] Terraform - assume_role_policy - similar but slightly different than standard IAM policy

问题描述

此页面 https://www.terraform.io/docs/provider/aws/r/iam_role.html 提及:

<块引用>

注意:这个假设角色策略非常相似但略有不同不仅仅是标准的 IAM 策略，不能使用 aws_iam_policy资源.但是，它可以使用 aws_iam_policy_document 数据源，请参阅下面的示例了解其工作原理.

assume_role_policy 与 标准 IAM 策略 有什么不同吗?

为什么?

解决方案

承担角色策略 是与控制委托人(用户、其他角色、AWS 服务等)的角色关联的特殊策略) 可以假设"角色.承担角色意味着生成临时凭据以使用与该角色关联的访问策略授予的权限.

代入角色策略与普通策略的不同之处在于:

• 它是角色本身的属性，而不是与角色关联的单独对象.每个角色只有一个代入角色政策.
• 在承担角色策略中唯一具有任何意义的 Action 值是 sts:AssumeRole 及其上的一些其他变体(在撰写本文时，sts:AssumeRoleWithSAML 和 sts:AssumeRoleWithWebIdentity).这些是用于获取角色临时凭证的 API 操作.

这些差异中的第一个导致了 Terraform 文档中提到的差异:由于角色只有一个 IAM 策略并且它被直接声明为角色的一部分，因此必须将其策略文档作为aws_iam_role 资源.aws_iam_policy_document 数据源只是将其输入简单转换为 IAM JSON 策略文档格式，因此可用于生成 assume_role_policy 属性的值.>

当 AWS 服务代表您调用另一个 API 服务时，它会在内部获取您指定角色的临时凭证，然后可以使用该凭证调用其他服务 API.正因为如此，有必要创建角色并将其分配给 AWS Lambda、EC2(通过实例配置文件)、Kinesis Firehose 等服务.

---

作为 另一个问题的答案，其中给出了一些实际 IAM 角色、假设角色策略和常规策略的示例.

This page https://www.terraform.io/docs/providers/aws/r/iam_role.html mentions:

NOTE: This assume_role_policy is very similar but slightly different than just a standard IAM policy and cannot use an aws_iam_policy resource. It can however, use an aws_iam_policy_document data source, see example below for how this could work.

Is there any reason why the assume_role_policy is different from the standard IAM policy?

Any why?

解决方案

An assume role policy is a special policy associated with a role that controls which principals (users, other roles, AWS services, etc) can "assume" the role. Assuming a role means generating temporary credentials to act with the privileges granted by the access policies associated with that role.

An assume role policy differs from a normal policy in the following ways:

• It is a property of the role itself, rather than a separate object associated with the role. There is only one assume role policy per role.
• The only Action values that have any meaning in an assume role policy are sts:AssumeRole and some other variants on it (at the time of writing, sts:AssumeRoleWithSAML and sts:AssumeRoleWithWebIdentity). Those are the API operations used to obtain the temporary credentials for the role.

It is the first of these differences that creates the difference mentioned in the Terraform documentation: since a role has exactly one IAM policy and it is declared directly as part of the role, its policy document must be provided as an attribute of the aws_iam_role resource. The aws_iam_policy_document data source is just a simple transform of its input into an IAM JSON policy document format, so it can be used to generate the value of the assume_role_policy attribute.

When an AWS service makes calls to another API service on your behalf, it is internally obtaining temporary credentials for the role you designate, which it can then use to make calls to other service APIs. It is for this reason that it is necessary to create roles and assign them to services such as AWS Lambda, EC2 (via instance profiles), Kinesis Firehose, etc.

---

I wrote a more elaborate description of this as part of an answer to another question, which gives some examples of practical IAM roles, assume role policies and regular policies.

这篇关于Terraform - 假设角色策略 - 与标准 IAM 策略类似但略有不同的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！