0

背景：

我正在尝试为账户 B 中的 ECS 任务授予访问权限，以从账户 A 中的 DynamoDB 表中提取数据。

理论上，这可以通过以下方式正常工作：(1) 在账户 A 中创建一个允许账户 B 担任的角色（使用配对的外部 ID），然后 (2) 授予该角色对所需 DynamoDB 表的访问权限。

问题：

当 ECS 中运行的进程承担 ECS 角色（账户 B）时，它会创建该角色的唯一实例，该实例显然不能成为账户中主体语句的目标。如果我尝试授予对底层角色的访问权限，那显然没有影响。

我可以强制 ECS 使用我可以作为委托人授予的原始角色，而不是一个显然不能承担其他角色的临时集吗？

我能想到的唯一解决方法是使用编程 API 凭证创建一个新用户，将这些凭证移交给 ECS 任务，然后让 ECS 任务用属于 AWS 密钥对的角色覆盖它自己的角色。不过，据我所知，这绝对是一种反模式，它会带来这些凭据被泄露的风险。

有没有办法在不求助于手动创建的用户和手动传递 AWS 凭据的情况下做到这一点？

附加信息：

  • 我可以授予此委托人arn:aws:iam::AcctB****:role/myrole，但 ECS 任务在运行时使用此委托人：arn:aws:sts::AcctB****:assumed-role/myrole/45716b8c-40c8-4ca7-b346-1ff4ee94eb53.
  • 错误信息是：An error occurred (AccessDenied) when calling the AssumeRole operation: User: arn:aws:sts::AcctB****:assumed-role/myrole/45716b8c-40c8-4ca7-b346-1ff4ee94eb53 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::AcctA****:role/ExternalRole
4

2 回答 2

2

我遇到了同样的情况，并找到了一种安全的方式来以编程方式从 ECS 任务中承担角色。

sts_client = boto3.client('sts')

identity = sts_client.get_caller_identity()

print(identity) # identity in account A

response = sts_client.assume_role(RoleArn=assume_role_arn, RoleSessionName=session_name)

session = boto3.Session(aws_access_key_id=response['Credentials']['AccessKeyId'],
                        aws_secret_access_key=response['Credentials']['SecretAccessKey'],
                        aws_session_token=response['Credentials']['SessionToken'])

这个想法是连接到帐户 A，从帐户 B 承担角色，使用临时凭据初始化会话，然后从该会话中初始化您需要的任何客户端。

external_client = session.client('sts')

identity = external_client.get_caller_identity()

print(identity) # identity in account B

这比创建 IAM 用户并在账户之间共享凭证更安全，因为身份验证是在内部完成的。

在这里您可以找到有关其工作原理的更多信息 https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/sts.html

于 2020-10-14T02:36:15.903 回答
0

在此处链接以下主题：如何从另一个 AWS 角色担任 AWS 角色？

TL;DR
确实确保您在其中一项政策中没有拼写错误、错误名称或外部 ID。

ECS 需要以与您尝试在账户 B 中代入角色相同的方式代入您的任务角色。这无法更改。即使 ECS 尝试承担账户 B 角色，assumed-role/...当授予委托人时，它也会按预期工作role/...

于 2021-03-12T01:58:22.517 回答