gpt4 book ai didi

amazon-web-services - 通过 CloudFormation 创建 ECS ecsTaskExecutionRole 的 AWS 区域注意事项

转载 作者:行者123 更新时间:2023-12-03 07:38:35 26 4
gpt4 key购买 nike

如果我通过 AWS 控制台手动运行 ECS Fargate 任务,AWS 会很好地自动创建 ECS task execution IAM role对我来说,我什至可以在 CloudFormation 模板中引用它,例如:

ExecutionRoleArn: !Sub "arn:aws:iam::${AWS::AccountId}:role/ecsTaskExecutionRole"

此角色使用 AWS 托管的 AmazonECSTaskExecutionRolePolicy。上述文档解释了如何通过控制台或 CLI 创建此角色。基本上,您创建此角色(或让 AWS 为您创建)一次,然后您可以在 CloudFormation 模板中永远引用它。 AWS 自动创建的 ecsTaskExecutionRole 不引用任何 AWS 区域,如果通过控制台或 CLI 创建,文档也没有提及有关该角色的区域注意事项的任何内容。

但我不想手动创建 ecsTaskExecutionRole。如果我创建一个新的 AWS 帐户,我想简单地部署一个新的 CloudFormation 堆栈,而不必担心我必须先进入并手动配置某些内容。 (毕竟,这就是 CloudFormation 的核心存在理由!)AWS 没有告诉我如何做,但在阅读 AWS::IAM::Role 的文档后我相信这很简单,如下所示。 (文档指出,通过 CloudFormation 创建角色需要我在某处指定 CAPABILITY_IAM,例如使用 CLI,但这似乎并不困难。)

  EcsTaskExecutionRole:
Type: AWS::IAM::Role
DeletionPolicy: Retain
Properties:
Description: AWS managed policy role for executing tasks on ECS.
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal:
Service:
- ecs-tasks.amazonaws.com
Action:
- sts:AssumeRole
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy
RoleName: ecsTaskExecutionRole

请注意,我设置了 deletion policy保留。这样,我的所有 CloudFormation 模板都可以根据需要创建一次角色,就像我通过控制台运行 ECS Fargate 任务时 AWS 本身所做的那样,然后将其保留在那里。

但是在文档中我读到了这个不祥的警告:

Naming an IAM resource can cause an unrecoverable error if you reuse the same template in multiple Regions. To prevent this, we recommend using Fn::Join and AWS::Region to create a Region-specific name, as in the following example: {"Fn::Join": ["", [{"Ref": "AWS::Region"}, {"Ref": "MyResourceName"}]]}.

documentation for CAPABILITY_NAMED_IAM同样说:

If your template contains custom named IAM resources, don't create multiple stacks reusing the same template. IAM resources must be globally unique within your account. If you use the same template to create multiple stacks in different Regions, your stacks might share the same IAM resources, rather than each having a unique one. Shared resources among stacks can have unintended consequences from which you can't recover. For example, if you delete or update shared IAM resources in one stack, you will unintentionally modify the resources of other stacks.

但是 AWS 创建的 ecsTaskExecutionRole 不指示任何区域,我认为我通过 CloudFormation 创建的这个角色将与该角色相同。有什么问题吗?

我的解释是,这种可怕的语言只是在说(尽管不是那么清楚),我应该小心,不要让一个 CloudFormation 模板删除正在另一个区域使用的角色(尽管我不想删除)如果同一区域中的另一个 CloudFormation 模板正在使用它,那么我不确定哪些区域与它有关)。因此,只要我在通过 CloudFormation 创建角色时使用 DeletionPolicy: Retain ,一切都应该没问题,或者至少不比使用 AWS 在以下情况下自动创建的 ecsTaskExecutionRole 角色差:我在控制台手动使用ECS。

我错过了什么吗?有没有什么方法可以使用 DeletionPolicy: Retain 通过 CloudFormation 创建 ecsTaskExecutionRole 与诱导 AWS 通过控制台运行 ECS 任务来创建相同的角色有什么不同?还有什么我没有考虑到的缺点吗?

最佳答案

从对我的问题的评论(感谢所有回复的人)中,我了解到通过 CloudFormation 管理单个帐户范围的 ECS 任务执行角色可能会比通过其他方式创建它带来更多奇怪的行为。此外,创建单个帐户范围角色来执行 ECS 任务的 AWS 方法无论如何都不是多个 CloudFormation 堆栈的最佳方法。

但是recently我发现,出于其他考虑因素,有时最好为每个服务创建任务执行角色,而不仅仅是为每个 CloudFormation 模板创建任务执行角色。最初在发布这个问题后,我为整个测试环境创建一个任务执行角色,然后将该角色用于各种服务。但如果服务从 Secrets Manager 注入(inject)密码,您将需要更细粒度的定义。

以下是您如何在 CloudFormation 中设置单个 ECS 任务执行角色以供所有服务使用:

Resources:

EcsTaskExecutionRole:
Type: AWS::IAM::Role
Properties:
RoleName: !Sub "${AWS::StackName}-${AWS::Region}-ecsTaskExecutionRole"
Description: "Role for executing tasks on ECS in region ${AWS::Region}."
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal:
Service:
- ecs-tasks.amazonaws.com
Action:
- sts:AssumeRole
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy

您甚至可以将其导出以用于相关(例如每个服务)CloudFormation 模板:

Outputs:

EcsTaskExecutionRoleArn:
Description: The ARN of the IAM role for executing ECS tasks.
Value: !Ref EcsTaskExecutionRole
Export:
Name: !Sub "${AWS::StackName}-${AWS::Region}:ecsTaskExecutionRoleArn"

在您需要将 secret 注入(inject)服务之前,这一切都很好。 AWS 托管 AmazonECSTaskExecutionRolePolicy允许这些操作:

  • ecr:GetAuthorizationToken
  • ecr:BatchCheckLayerAvailability
  • ecr:GetDownloadUrlForLayer
  • ecr:BatchGetImage
  • 日志:CreateLogStream
  • 日志:PutLogEvents

请注意,secretsmanager:GetSecretValue 操作不在其中。假设您希望从 Secrets Manager 注入(inject)密码,以便 Spring Boot 应用程序与 DocumentDB 对话,如 Using Secrets Manager 中所述。并在 Disable Spring Boot Data MongoDB retryable writes in AWS ECS Fargate with CloudFormation 中进行说明:

          Secrets:
- Name: SPRING_DATA_MONGODB_USERNAME
ValueFrom: !Sub "${DbCredentials}:username::"
- Name: SPRING_DATA_MONGODB_PASSWORD
ValueFrom: !Sub "${DbCredentials}:password::"

使用上面定义的 EcsTaskExecutionRole 是行不通的。您需要定义一个单独的角色,其中包含 secretsmanager:GetSecretValue,如 IAM policy examples for secrets in AWS Secrets Manager 中所述。 。您可以继续将 secretsmanager:GetSecretValue 添加到您的自定义角色,但您可能不希望让所有服务都可以访问仅适用于其他服务的 secret (即 PoLP )。在这种情况下,最好为每个需要注入(inject) secret 的服务定义一个单独的角色。以下示例假设您将注入(inject) AWS::SecretsManager::Secret上面引用的 DbCredentials(如 https://stackoverflow.com/a/75999386 所示)

  ServiceTaskExecutionRole:
Type: AWS::IAM::Role
Properties:
RoleName: !Sub "my-service-${AWS::Region}-taskExecRole"
AssumeRolePolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Principal:
Service:
- ecs-tasks.amazonaws.com
Action:
- sts:AssumeRole
Policies:
- PolicyName: !Sub "my-service-${AWS::Region}-secret-access-policy"
PolicyDocument:
Version: 2012-10-17
Statement:
- Effect: Allow
Action:
- secretsmanager:GetSecretValue
Resource:
- !Ref DbCredentials
ManagedPolicyArns:
- arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy

这将设置与本答案开头所示的相同的 ECS 任务执行角色,并具有仅访问 DbCredentials key 的权限。

如果有人知道如何使用共享 EcsTaskExecutionRole 并仅根据具体情况添加检索 DbCredentials 的权限,而不创建新角色,请让我知道。

关于amazon-web-services - 通过 CloudFormation 创建 ECS ecsTaskExecutionRole 的 AWS 区域注意事项,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/75870686/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com