英文:
How to Trigger ECS Tasks in a cross-account architecture
问题
我正在尝试使用Airflow触发另一个AWS账户中的ECS任务。Airflow使用的工作节点始终假定在账户A中具有特定角色（role-a）。ECS集群位于账户B中。我在账户B中有一个名为role-b的角色，应该具有运行ECS任务、连接到ECR等所需的所有权限，我正在尝试建立对该角色的访问，以便只有账户A中的role-a可以承担它。
当我使用boto3在工作节点上检查sts身份时，它返回为arn:aws:sts::494531898320:assumed-role/role-a/botocore-session-1631223174。末尾的这部分始终是一个随机数。因为它不断变化，我尝试在role-b的信任策略中使用通配符，以便我的工作节点始终能够承担另一个帐户中的这个角色，并在账户B的ECS集群中使用它运行ECS:RunTask操作。
以下是role-b的信任策略：
# role-b在账户B中 - ECS集群所在的账户。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:PrincipalArn": "arn:aws:sts::494531898320:assumed-role/role-a/*"
}
}
}
]
}
然而，这并不起作用。我的Airflow工作节点立即出现错误，说明role-a无法承担role-b角色。我的通配符条件是否不起作用？是否必须将sts:AssumeRole策略放在附加到role-b角色的实际策略中，而不仅仅放在信任权限中？
在同一个账户中执行所有操作将更容易，但目前对于我的用例来说不是选项。我有点迷失在如何继续进行以及如何正确实现这一点上，没有找到很好的示例 - 任何帮助将不胜感激！
英文:
I'm in the process of trying to use Airflow to trigger ECS Tasks in another AWS Account. The worker nodes that Airflow uses always assume a specific role (role-a) in Account A. The ECS Cluster is in Account B. I have a role in Account B called role-b that should have all the permissions needed to run ECS Tasks and connect to ECR etc, and I'm trying to establish access to this role so that only role-a in Account A can assume it.
When I check the sts identity on a worker node using boto3, it gets returned as arn:aws:sts::494531898320:assumed-role/role-a/botocore-session-1631223174. This last bit at the end is always a random number. Because it's constantly changing I'm trying to use a wildcard in role-b's Trust Policy so that my worker nodes will always be able to assume this role in the other account and run ECS:RunTask operations with it in Account B's ECS Cluster.
Below is my trust policy for role-b.
# role-b in Account B - The account where the ECS Cluster is.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringLike": {
"aws:PrincipalArn": "arn:aws:sts::494531898320:assumed-role/role-a/*"
}
}
}
]
}
However, this doesn't work. My Airflow worker nodes instantly get an error that role-a can't assume this role-b role. Is my wildcard condition not working? Do i have to put a sts:AssumeRole policy in the actual policy attached to this role-b role instead of only in the Trust Permissions?
It'd be a lot easier to do this all in a single account but that's not an option for my use case as of right now. I'm kinda lost on how to proceed and haven't found great examples of how to properly implement this - any help would be appreciated !
答案1
得分: 0
sytech的建议是正确的，但似乎只解决了一半的问题；IAM角色ARN（arn:aws:iam::<account>:role/<your-role>）需要在信任策略中，而不是我sts身份回传的assumed-role/xxx部分。
我还需要在role-a上附加一个IAM策略，使其具有对Account B中的role-b执行sts:AssumeRole操作的权限，以便role-a实际上有权限调用另一个帐户中的资源上的AssumeRole API操作。
如果没有这个，即使信任策略现在是正确的，由于role-a从未被授予执行sts:AssumeRole操作的权限，仍然会返回AccessDenied。
英文:
sytech's suggestion was correct but seems to have been half the answer; the IAM Role ARN (arn:aws:iam::<account>:role/<your-role>) needs to be in the Trust Policy, not the assumed-role/xxx bit that my sts identity was spitting back.
The other thing I had to do was attach an IAM Policy to role-a that gives sts:AssumeRole access to the role-b in Account B so that role-a actually has permissions to call the AssumeRole API operation on that resource in the other account.
Without this, even though the Trust Policy was now correct it was still returning an AccessDenied simply because the role-a was never given permissions to do an sts:AssumeRole Operation.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论