IAM 角色 - AWS Identity and Access Management
何时创建 IAM 用户（而不是角色）角色术语和概念其他 资源

IAM 角色

IAM 角色是可在账户中创建的一种具有特定权限的 IAM 身份。IAM 角色类似于 IAM 用户，因为它是一个 AWS 身份，具有确定其在 AWS 中可执行和不可执行的操作的权限策略。但是，角色旨在让需要它的任何人代入，而不是唯一地与某个人员关联。此外，角色没有关联的标准长期凭证（如密码或访问密钥）。相反，当您代入角色时，它会为您提供角色会话的临时安全凭证。

您可以使用角色向通常无权访问您的 AWS 资源的用户、应用程序或服务提供访问权限。例如，您可能需要向您 AWS 账户中的用户授予对其通常不拥有的资源的访问权限，或是向一个 AWS 账户 中的用户授予对其他账户中的资源的访问权限。或者，您可能需要允许移动应用程序使用 AWS 资源，但是不希望在应用程序中嵌入 AWS 密钥（因为难以更新密钥，而且用户有可能提取到密钥）。有时，您需要向已经具有在 AWS 外部（例如，在您的公司目录中）定义的身份的用户提供对 AWS 的访问权限。或者，您可能需要向第三方授予对您账户的访问权限，使他们可以对您的资源执行审核。

对于这些情况，您可以使用 IAM 角色委派对 AWS 资源的访问权限。本节介绍各种角色和它们的不同使用方式，何时及如何选择方法，如何创建、管理、切换到（或担任）和删除角色。

注意

首次创建您的 AWS 账户 时，默认情况下不会创建任何角色。当您向账户添加服务时，这些服务可能会添加服务相关角色以支持其使用案例。

服务相关角色是一种与 AWS 服务 相关的服务角色。服务可以代入代表您执行操作的角色。服务相关角色显示在您的 AWS 账户 中，并由该服务拥有。IAM 管理员可以查看但不能编辑服务相关角色的权限。

您必须先删除角色的相关资源，之后才能删除服务相关角色。这可以保护您的资源，因为您不会无意中删除对资源的访问权限。

有关哪些服务支持使用服务相关角色的信息，请参阅 使用 IAM 的AWS服务 并查找其在服务相关角色列中为是的服务。选择是和链接，查看该服务的服务相关角色文档。

主题

何时创建 IAM 用户（而不是角色）

我们建议您仅在联合用户不支持的用例中使用 IAM 用户。部分使用场景包括：

  • 无法使用 IAM 角色的工作负载 – 您可以从需要访问 AWS 的位置运行工作负载。在某些应用场景中，您无法使用 IAM 角色提供临时凭证，例如 WordPress 插件。在这些情况下，请使用该工作负载的 IAM 用户长期访问密钥对 AWS 进行身份验证。

  • 第三方 AWS 客户端：如果您使用的工具不支持访问 IAM Identity Center，例如不在 AWS 上托管的第三方 AWS 客户端或供应商，请使用 IAM 用户长期访问密钥。

  • AWS CodeCommit 访问 – 如果您正在使用 CodeCommit 来存储您的代码，则可以使用具有 SSH 密钥或服务特定凭证的 IAM 用户对 CodeCommit 进行存储库身份验证。我们建议您除了使用 IAM Identity Center 中的用户进行普通身份验证之外，再执行此操作。IAM Identity Center 中的用户是您的员工队伍中需要访问您的 AWS 账户 或云应用程序的人员。要在不配置 IAM 用户的情况下授予用户访问您 CodeCommit 存储库的权限，您可以配置 git-remote-codecommit 实用工具。有关 IAM 和 CodeCommit 的更多信息，请参阅 CodeCommit 的 IAM 凭证：Git 凭证、SSH 密钥和 AWS 访问密钥。有关配置 git-remote-codecommit 实用工具的更多信息，请参阅《AWS CodeCommit 用户指南》中的连接到具有轮换凭证的 AWS CodeCommit 存储库。

  • Amazon Keyspaces (for Apache Cassandra) access（Amazon Keyspaces（Apache Cassandra 兼容）访问）– 在您无法使用 IAM Identity Center 中的用户的情况下，如出于测试 Cassandra 兼容性的目的，您可以使用具有服务特定凭证的 IAM 用户向 Amazon Keyspaces 进行身份验证。IAM Identity Center 中的用户是您的员工队伍中需要访问您的 AWS 账户 或云应用程序的人员。您还可以使用临时凭证连接到 Amazon Keyspaces。有关更多信息，请参阅《Amazon Keyspaces（Apache Cassandra 兼容）开发人员指南》中的使用临时凭证连接到使用 IAM 角色和 SigV4 插件的 Amazon Keyspaces。

  • 紧急访问：无法访问身份提供者，且必须在 AWS 账户 中执行操作的情况。创建紧急访问 IAM 用户可以是您弹性计划的一部分。我们建议使用多重身份验证（MFA）严格控制和保护紧急用户凭证。

角色术语和概念

以下是可帮助您开始使用角色的一些基本术语。

角色

可在账户中创建的具有特定权限的 IAM 身份。IAM 角色与 IAM 用户有一些相似之处。角色和用户都是具有权限策略的 AWS 身份，该策略可确定身份在 AWS 中可执行和不可执行的操作。但是，角色旨在让需要它的任何人代入，而不是唯一地与某个人员关联。此外，角色没有关联的标准长期凭证（如密码或访问密钥）。相反，当您代入角色时，它会为您提供角色会话的临时安全凭证。

角色可由以下用户代入：

  • 相同 AWS 账户 或另一个 AWS 账户 中的 IAM 用户

  • 同一账户中的 IAM 角色

  • 服务主体，用于 AWS 服务和功能，例如：

    • 允许您在计算服务上运行代码的服务，如 Amazon EC2 或 AWS Lambda

    • 代表您对资源执行操作的功能，如 Amazon S3 对象复制

    • 为在 AWS 外部运行的应用程序提供临时安全凭证的服务，如 IAM Roles Anywhere 或 Amazon ECS Anywhere

  • 由与 SAML 2.0 或 OpenID Connect 兼容的外部身份提供者（IdP）服务进行身份验证的外部用户

AWS 服务 角色

服务角色是由一项服务担任、代表您执行操作的 IAM 角色。IAM 管理员可以在 IAM 中创建、修改和删除服务角色。有关更多信息，请参阅《IAM 用户指南》中的创建向 AWS 服务 委派权限的角色。

AWS 服务相关角色

服务相关角色是一种与 AWS 服务 相关的服务角色。服务可以代入代表您执行操作的角色。服务相关角色显示在您的 AWS 账户 中，并由该服务拥有。IAM 管理员可以查看但不能编辑服务相关角色的权限。

注意

如果在某项服务开始支持服务相关角色时您已使用该服务，您可能会收到一封电子邮件，告知您账户中的新角色。在这种情况下，该服务已自动在您的账户中创建服务相关角色。您无需执行任何操作来支持该角色，并且您不应手动删除它。有关更多信息，请参阅 我的 AWS 账户中出现新角色。

有关哪些服务支持使用服务相关角色的信息，请参阅 使用 IAM 的AWS服务 并查找其在服务相关角色列中为是的服务。选择是和链接，查看该服务的服务相关角色文档。有关更多信息，请参阅 创建服务相关角色。

角色链

角色链是指通过 AWS CLI 或 API 使用一个角色代入另一个角色。例如，RoleA 有权代入 RoleB。您可以在 AssumeRole API 操作中使用其长期用户凭证以允许 User1 代入 RoleA。该操作会返回 RoleA 短期凭证。借助角色链，您可以使用 RoleA 的短期凭证允许 User1 代入 RoleB。

当您在代入某个角色的同时，您可以传递会话标签并将键设置为可传递。可传递会话标签将传递给角色链中的所有后续会话。要了解会话标签的更多信息，请参阅 在 AWS STS 中传递会话标签。

角色链将您的 AWS CLI 或 AWS API 角色会话限制为最长 1 小时。在使用 AssumeRole API 操作代入角色时，您可以使用 DurationSeconds 参数指定角色会话的持续时间。您可以指定最多为 43200 秒 (12 小时) 的参数值，具体取决于您的角色的最大会话持续时间设置。不过，如果您使用角色链代入角色并提供大于 1 小时的 DurationSeconds 参数值，则操作将失败。

委托

为某人授予权限以允许访问您控制的资源。委派涉及在两个账户之间建立信任。第一个是拥有资源的账户（信任账户）。第二个是包含需要访问资源的用户的账户（可信账户）。可信账户和信托账户可为以下任一账户：

  • 同一账户。

  • 受您的组织控制的两个单独账户。

  • 由不同组织拥有的两个账户。

要委派权限以访问资源，请在附加了两个策略的信任账户中创建 IAM 角色。权限策略授予角色的用户所需权限对资源执行预期任务。信任策略指定允许哪些受信任账户成员担任角色。

创建信任策略时，不能在主体元素中指定通配符 (*) 作为 ARN 的一部分。信任策略附加到信任账户中的角色，并且是权限的一半。另一半是附加到允许用户切换到或担任角色的受信任账户中的用户的权限策略。临时担任一个角色的用户将放弃自己的权限而接过该角色的权限。用户退出或停止使用角色时，恢复原始用户权限。另一个名为外部 ID 的参数有助于确保在不受同一企业控制的账户之间安全使用角色。

信任策略

在 JSON 策略文档中，您可以定义您信任代入该角色的主体。角色信任策略是必需的基于资源的策略（将附加到 IAM 中的角色）。您可以在信任策略中指定的主体包括用户、角色、账户和服务。

用于跨账户访问的角色

将一个账户中的资源的访问权限授予另一个账户中的受信任主体的账户。角色是授予跨账户访问权限的主要方式。但是，某些 AWS 服务允许您将策略直接附加到资源（而不是使用角色作为代理）。这些策略称为基于资源的策略，您可以使用它们向其他 AWS 账户 中的主体授予对资源的访问权限。其中一些资源包括 Amazon Simple Storage Service (S3) 存储桶、S3 Glacier 文件库、Amazon Simple Notification Service (SNS) 主题和 Amazon Simple Queue Service (SQS) 队列。要了解哪些服务支持基于资源的策略，请参阅 使用 IAM 的AWS服务。有关基于资源的策略的更多信息，请参阅 IAM 中的跨账户资源访问。

其他 资源

以下资源可帮助您了解与 IAM 角色相关的 IAM 术语的更多信息。

  • 主体是 AWS 中可执行操作并访问资源的实体。主体可以是 AWS 账户根用户、IAM 用户或角色。代表 AWS 服务身份的主体就是服务主体。使用角色信任策略中的 Principal 元素来定义您信任的可以代入该角色的主体。

    有关您可以允许代入角色的主体的更多信息和示例，请参阅 AWS JSON 策略元素：Principal。

  • 身份联合验证会创建外部身份提供商与 AWS 之间的信任关系。您可以使用现有的 OpenID Connect（OIDC）或安全断言标记语言（SAML）2.0 提供程序来管理谁可以访问 AWS 资源。当您使用 OIDC 和 SAML 2.0 在这些外部身份提供者与 AWS 之间配置信任关系时，会将用户分配到 IAM 角色。用户还会获得允许该用户访问您的 AWS 资源的临时凭证。

    有关联合身份用户的更多信息，请参阅身份提供程序和联合身份验证。

  • 联合用户是来自 AWS Directory Service、您的企业用户目录或 OIDC 提供者的现有身份。这些用户称为联合用户。在通过身份提供者请求访问权限时，AWS 将为联合用户分配角色。

    有关联合身份用户的更多信息，请参阅联合用户和角色。

  • 权限策略是基于身份的策略，用于定义角色可使用的操作和资源。该文档是根据 IAM policy 语言的规则编写的。

    有关更多信息，请参阅 IAM JSON 策略参考。

  • 权限边界是一项高级功能，利用该功能，可以使用策略来限制基于身份的策略可以授予角色的最大权限。无法将权限边界应用于服务相关角色。

    有关更多信息，请参阅 IAM 实体的权限边界。