Terraform:AssumeRole:Service:ec2 做什么? [英] Terraform: what does AssumeRole: Service: ec2 do?

问题描述

这个 AWS 角色具体做什么?

What exactly does this AWS role do?

最相关的部分似乎是:"Action": "sts:AssumeRole", 和服务":ec2.amazonaws.com"

The most relevant bits seem to be: "Action": "sts:AssumeRole", and "Service": "ec2.amazonaws.com"

完整的角色在这里:

resource "aws_iam_role" "test_role" {
  name = "test_role"

  assume_role_policy = <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Effect": "Allow",
      "Sid": ""
    }
  ]
}
EOF
}

来自:https://www.terraform.io/docs/提供者/aws/r/iam_role.html

推荐答案

要理解它的含义，有必要了解 IAM 角色如何工作的一些细节.

To understand the meaning of this it is necessary to understand some details of how IAM Roles work.

IAM 角色在其结构上类似于 用户，但它不是由一组固定的凭据访问，而是由 假设 角色使用，这意味着请求和获取临时 API 凭据，以允许使用授予角色的权限执行操作.

An IAM role is similar to a user in its structure, but rather than it being accessed by a fixed set of credentials it is instead used by assuming the role, which means to request and obtain temporary API credentials that allow taking action with the privileges that are granted to the role.

sts:AssumeRole 动作 是获取此类临时凭证的方式.要使用它，用户或应用程序使用一些已经获得的凭据(例如用户的固定访问密钥)调用此 API，并返回(如果允许)一组新的凭据以充当角色.这是 AWS 服务可以代表您调用其他 AWS 服务、IAM 实例配置文件在 EC2 中工作以及用户可以在 AWS 控制台中临时切换访问级别或账户的机制.

The sts:AssumeRole action is the means by which such temporary credentials are obtained. To use it, a user or application calls this API using some already-obtained credentials, such as a user's fixed access key, and it returns (if permitted) a new set of credentials to act as the role. This is the mechanism by which AWS services can call into other AWS services on your behalf, by which IAM Instance Profiles work in EC2, and by which a user can temporarily switch access level or accounts within the AWS console.

假设角色策略确定允许哪些主体(用户、其他角色、AWS 服务)为此角色调用 sts:AssumeRole.在此示例中，EC2 服务本身被授予访问权限，这意味着 EC2 能够使用此角色代表您执行操作.

The assume role policy determines which principals (users, other roles, AWS services) are permitted to call sts:AssumeRole for this role. In this example, the EC2 service itself is given access, which means that EC2 is able to take actions on your behalf using this role.

此角色资源单独没有用，因为它没有任何关联的 IAM 策略，因此不授予任何访问权限.因此，aws_iam_role 资源将始终伴随至少一个其他资源来指定其访问权限.有几种方法可以做到这一点:

This role resource alone is not useful, since it doesn't have any IAM policies associated and thus does not grant any access. Thus an aws_iam_role resource will always be accompanied by at least one other resource to specify its access permissions. There are several ways to do this:

• 使用 aws_iam_role_policy将策略直接附加到角色.在这种情况下，策略将描述允许该角色执行的一组 AWS 操作，以及可选的其他约束.
• 使用 aws_iam_policy创建一个独立策略，然后使用 aws_iam_policy_attachment 将该策略与一个或多个角色、用户和组相关联.如果您希望将单个策略附加到多个角色和/或用户，这种方法很有用.
• 使用特定于服务的机制在服务级别附加政策.这是解决问题的另一种方法，它不是将策略附加到角色，而是附加到其访问受到控制的对象.执行此操作的机制因服务而异，例如 policy 属性rel="noreferrer">aws_s3_bucket 设置特定于存储桶的策略；策略文档中的 Principal 元素可用于指定哪些委托人(例如角色)可以采取某些行动.

• Use aws_iam_role_policy to attach a policy directly to the role. In this case, the policy will describe a set of AWS actions the role is permitted to execute, and optionally other constraints.
• Use aws_iam_policy to create a standalone policy, and then use aws_iam_policy_attachment to associate that policy with one or more roles, users, and groups. This approach is useful if you wish to attach a single policy to multiple roles and/or users.
• Use service-specific mechanisms to attach policies at the service level. This is a different way to approach the problem, where rather than attaching the policy to the role, it is instead attached to the object whose access is being controlled. The mechanism for doing this varies by service, but for example the policy attribute on aws_s3_bucket sets bucket-specific policies; the Principal element in the policy document can be used to specify which principals (e.g. roles) can take certain actions.

IAM 是一个灵活的系统，支持多种不同的访问控制方法.哪种方法适合您在很大程度上取决于您的组织如何处理安全和访问控制问题:使用 aws_iam_role_policy 和 aws_iam_policy_attachment 从角色角度管理策略通常适用于组织拥有一个集中的安全团队来监督整个帐户的访问，而特定于服务的策略将访问控制决策委托给负责每个单独对象的个人或团队.作为纵深防御策略的一部分，这两种方法可以结合使用，例如使用角色和用户级别的策略来进行边界"访问控制(控制来自外部的访问) 和内部访问控制的服务级别策略(控制帐户内对象之间的交互).

IAM is a flexible system that supports several different approaches to access control. Which approach is right for you will depend largely on how your organization approaches security and access control concerns: managing policies from the role perspective, with aws_iam_role_policy and aws_iam_policy_attachment, is usually appropriate for organizations that have a centralized security team that oversees access throughout an account, while service-specific policies delegate the access control decisions to the person or team responsible for each separate object. Both approaches can be combined, as part of a defense in depth strategy, such as using role- and user-level policies for "border" access controls (controlling access from outside) and service-level policies for internal access controls (controlling interactions between objects within your account).

有关角色的更多详细信息，请参阅 AWS IAM 指南 IAM 角色.另请参阅 访问管理，其中涵盖 IAM 中访问控制的一般概念.

More details on roles can be found in the AWS IAM guide IAM Roles. See also Access Management, which covers the general concepts of access control within IAM.

这篇关于Terraform:AssumeRole:Service:ec2 做什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！