问题
为了安全地访问 AWS 服务，我的理解是应该始终使用 IAM 角色，这样凭证的暴露始终只是暂时的。我不完全理解的是，如何在服务器上以自动化且安全的方式实际承担这个角色？
假设有一个应用服务器 A，它必须通过服务器到服务器的通信与 AWS 服务交互，以向请求的 Web 前端提供 API 响应。
要做到这一点，我能想到的当前设置是：
- 在 AWS 中创建一个 IAM 角色，授予在 AWS 内执行所需操作的权限。
- 创建一个 AWS IAM 用户。
- 向上文提到的 IAM 角色添加一个信任关系，确保该角色只能由你在上一步创建的 AWS IAM 用户承担。并且，只有当承担角色的请求来自特定的服务器时才允许，例如，通过在 AWS 端对角色承担请求进行 IP 白名单过滤。
目前为止都很好，但我不理解的是：如何以编程方式设置角色的承担，而无需实际设置允许已创建的 AWS IAM 用户发起承担角色请求的永久凭证？我能想到的唯一方法是，为 AWS IAM 用户创建永久访问密钥，然后持续轮换这些密钥。 难道没有更好的方法吗？
类比 OIDC
据我所知，这与实际的 OIDC 协议也没有太大区别。唯一的区别在于，在上述场景中，我的 AWS IAM 用户的 AWS 访问密钥是用于从我的服务器向 AWS 认证以承担角色的初始凭证，而不是像服务器用来向 OIDC 认证以获取 ID 令牌的 JWT（例如）。对吗？
因此，例如在这个解释传统 OIDC 设置的链接中，与我上述解释的设置相比，技术上的区别在于第 4 步（获取临时凭证的请求）不是从客户端发送到身份提供商（IdP），而是从我的服务器发送到云端。这还带来了额外的副作用，即对我的应用程序的访问被专门锁定在我自己的系统登录上。因此，例如，我不必担心临时凭证会泄露给那些谷歌账户可能已被泄露的用户，等等。 我的想法错了吗？