有许多 AWS 账户不受我控制。我让账户所有者将 IAM 角色部署TrustingSecurityAuditor到他们的账户中，从而将担任该角色的权限授予TrustingSecurityAuditor我的 AWS 账户中的另一个 IAM 角色TrustedSecurityAuditor。(有关委派访问权限的文档）
这很有效，让我和我的安全团队能够为公司中的其他账户持有者提供安全审计服务。为此，我们启动了一个具有TrustedSecurityAuditorIAM 角色的 ec2 实例，我们的代码使用以下命令从每个账户请求临时凭证船用运输系统AssumeRole通过对每个帐户的角色进行操作TrustingSecurityAuditor。
现在，我想在我的帐户中创建一个在不同的 ec2 实例上运行的附加服务，它不仅可以承担这些“信任”帐户的角色，还可以在我的帐户中执行其他操作，例如访问我帐户的 DynamoDB 来存储信息。
如果我将TrustedSecurityAuditor角色应用于实例，我没有所需的本地权限（如 DynamoDB 访问权限）。
我无法将多个 IAM 角色应用于一个实例（除非我弄错了）。
当我尝试创建一个新角色，MyNewService并具有可以AssumeRole访问该TrustedSecurityAuditor角色的 DynamoDB 访问权限，希望然后使用这些 STS 凭证在外国账户中AssumeRole对该角色进行第二次操作时，我遇到了这个问题：TrustingSecurityAuditor
我能够AssumeRole从MyNewService角色到角色，但是当我对角色TrustedSecurityAuditor执行第二次操作时，AWS 返回错误AssumeRoleTrustingSecurityAuditor
用户：arn：aws：sts：：123456789012：assumed-role / TrustedSecurityAuditor / MyNewService 未获授权执行：sts：AssumeRole 资源：arn：aws：iam：：123456789012：role / TrustingSecurityAuditor
原因是，尝试执行该AssumeRole操作的“用户”
arn:aws:sts::123456789012:assumed-role/TrustedSecurityAuditor/MyNewService
不是
arn:aws:sts::123456789012:assumed-role/TrustedSecurityAuditor
这意味着您不能链接您的AssumeRoles，因为当呼叫来自假定角色时，其发出的 ARN 不仅仅是假定角色，而是假定角色和承担者的角色名称停留在最后。
我不太愿意使用的一个解决方案是，我可以只添加我需要的权限，例如为角色添加使用 DynamoDB 的能力TrustedSecurityAuditor。我不愿意的原因是，我只需要在实例上获得此权限，而不是在原始实例上获得此权限，因为MyNewService原始实例只进行安全审计，不需要访问 DynamoDB。
关于如何实现我所寻找的东西有什么建议吗？
答案1
设想：
- AccountA - 您的帐户
- AccountB-客户账户
- RoleA - 您的账户角色，用于访问 DynamoDB、调用 STS 等。
- RoleB - AccountB 中的 TrustedSecurityAuditor 角色
您需要管理两组凭证。凭证 A 是根据分配给 EC2 实例的 IAM 角色创建的。使用这些凭证可以访问您的资源，例如 DynamoDB。凭证 B 是根据 RoleB 通过 STS 创建的。使用这些凭证可以访问您的客户资源。
然后，您将需要根据要执行的操作独立使用凭据。例如，如果您使用 Python，则需要创建两个具有不同凭据的 boto3 客户端。