Terraform:AssumeRole:服务:ec2有什么用? [英] Terraform: what does AssumeRole: Service: ec2 do?

问题描述

这个AWS角色到底是做什么的?

What exactly does this AWS role do?

最相关的位似乎是: "Action": "sts:AssumeRole",和 "Service": "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/provider/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角色在结构上类似于 user ，但是它不是由一组固定的凭据访问的，而是由假设角色使用的，这意味着请求并获取临时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属性> 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:服务:ec2有什么用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！