卓：扮演角色还是不扮演角色？

Question

来自AWS docs：

When to Create an IAM User (Instead of a Role)
...
You want to use the command-line interface (CLI) to work with AWS.

When to Create an IAM Role (Instead of a User)

- You're creating an application that runs on an Amazon Elastic Compute Cloud (Amazon EC2) instance and that application makes requests to AWS.
- You're creating an app that runs on a mobile phone and that makes requests to AWS.
- Users in your company are authenticated in your corporate network and want to be able to use AWS without having to sign in again—that is, you want to allow users to federate into AWS.

但似乎公司在所有事情上都大量使用角色：

• 通过创建具有特定策略的角色并创建自定义策略以应用于组来为组创建角色。
• 担任使用 CLI 的角色。
• 切换角色以使用不同的帐户。

这是过度的还是基于实际工作的解决方案？

Answer 1

这是过度的还是基于实际工作的解决方案？

根据我自己在 AWS 方面的经验，大量使用角色是一种真正基于工作的解决方案，因为在我的公司中，我们只使用角色来授予用户访问权限（是的，我们在您的 AWS 环境中注册了 0 个用户）。我将列出我们选择这种方式的原因：

1. 我们正在使用AWS Control Tower。

此服务使拥有至少 3 个 AWS 账户的 AWS Organizations 能够管理您的组织。我们必须为每个 AWS 账户创建一个用户，这将是一团糟。此外，AWS Control Tower 支持AWS Single Sign-On。

1. 我们正在使用AWS Single Sign-On。

此服务将具有多个角色的多个 AWS 账户与多个用户相关联。说明：

AWS Single Sign-On (SSO) 是一种云 SSO 服务，可以轻松集中管理对多个 AWS 账户和业务应用程序的 SSO 访问。只需单击几下，您就可以启用高度可用的 SSO 服务，而无需前期投资和运营您自己的 SSO 基础架构的持续维护成本。借助 AWS SSO，您可以轻松地集中管理对 AWS Organizations 中所有账户的 SSO 访问和用户权限。 AWS SSO 还包括与许多业务应用程序的内置 SAML 集成，例如 Salesforce、Box 和 Office 365。此外，通过使用 AWS SSO 应用程序配置向导，您可以创建安全断言标记语言 (SAML) 2.0 集成并扩展 SSO访问任何支持 SAML 的应用程序。您的用户只需使用他们在 AWS SSO 中配置的凭证登录用户门户，或者使用他们现有的公司凭证从一个地方访问他们分配的所有账户和应用程序。

请查看此服务提供的一些features。使用角色而不是用户有很多好处。在我看来，通过 AWS SSO，AWS 本身促进了角色的使用。

---

我发现的唯一缺点是每次我需要使用 AWS CLI 时，我都需要访问 AWS SSO 门户，复制凭证并粘贴到我的终端中，因为凭证会在一段时间后过期。但最后，与此过程提供的安全性相比，这个缺点很小 - 如果我的计算机被盗，由于凭证过期而无法访问 AWS CLI。