无法授予跨帐户访问ECS任务角色的权限 [英] Can't grant cross-account access to a ECS task's role

问题描述

背景:

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

从理论上讲，这可以很好地起作用:(1)在允许帐户B承担的帐户A中创建角色(使用成对的外部ID)，然后(2)授予该角色对所需DynamoDB表的访问权限./p>

问题:

当在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 .
• 错误消息是:调用AssumeRole操作时发生错误(AccessDenied):用户:arn:aws:sts :: AcctB ****:assumed-role/myrole/45716b8c-40c8-4ca7-b346-1ff4ee94eb53无权执行:资源上的sts:AssumeRole:arn:aws:iam :: AcctA ****:role/ExternalRole

解决方案

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

  sts_client = boto3.client('sts')身份= sts_client.get_caller_identity()print(identity)#帐户A中的身份响应= 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')身份= external_client.get_caller_identity()print(identity)#帐户B中的身份 

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

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

Background:

I am trying to grant access for an ECS task in Account B to extract data from a DynamoDB table in Account A.

In theory, this works fine by: (1) creating a role in Account A that Account B is allowed assume (with a paired External ID), and then (2) granting that role access to the needed DynamoDB tables.

Problem:

When a process running in ECS assumes the ECS role (Account B), it creates a unique instance of that role, which apparently cannot be the target of a principal statement in the account. If I try granting access to the underlying role, that apparently has no affect.

Can I force ECS to use the original role, which I can grant as principal, rather an a temporary set which apparently can't then assume other roles?

The only workaround I can think of is to create a new user with programmatic API credentials, handoff those creds to the ECS task, and then then have the ECS task overrides it's own role with the one's belonging to the AWS key-pair. That's definitely an antipattern though, as far as I can tell, and it opens up the risk of those credentials being compromised.

Is there any way to do this without resorting to a manually created user and manually passed AWS creds?

Additional info:

• I can grant to this principal arn:aws:iam::AcctB****:role/myrole but the ECS task is using this one at runtime: arn:aws:sts::AcctB****:assumed-role/myrole/45716b8c-40c8-4ca7-b346-1ff4ee94eb53.
• Error message is: 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

解决方案

I faced the same situation and found a safe way to programmatically assume the role from an ECS task.

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'])

The idea is to connect to account A, assume role from account B, init a session using temporary credentials and then init whatever client you need from that session.

external_client = session.client('sts')

identity = external_client.get_caller_identity()

print(identity) # identity in account B

This is more secure than creating a IAM user and share credentials between accounts because authentication is done internally.

Here you can find more information about how it works https://boto3.amazonaws.com/v1/documentation/api/latest/reference/services/sts.html

这篇关于无法授予跨帐户访问ECS任务角色的权限的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！