我们最近部署了一个新应用程序,该应用程序使用配置为启动带有加密 EBS 根卷的实例的 ASG。我们有大量现有应用程序完全使用此设置工作,但我们的新 ASG 拒绝启动实例。这些实例甚至没有出现,我们在 ASG 事件历史记录中看到一个错误: Client.InternalError: Client error on launch
。
经过试验,我们发现如果我们将使用的 AMI 换成未加密的 AMI,它就会开始按预期工作。令人困惑的是,我们在不同的 ASG 上使用完全相同的 AMI,并且一切都按预期工作(由几乎相同的 CloudFormation 模板组成)。同样,我们可以使用相同的 AMI 和实例配置文件直接从控制台启动 EC2 实例。
有没有人见过这种行为?
我在其他地方找到了一些解决方案(这让我们证明它与加密卷有关),例如 this from AWS,但它们似乎与我们的场景没有直接关系。
最佳答案
我们最终发现 an AWS forum post 详细说明了服务相关角色 (SLR)。似乎在过去几个月的某个时候,他们改变了 ASG 的行为方式(仅适用于新创建的 ASG)。以前,ASG 可以使用任何 KMS CMK,但现在已更改为只能访问默认 key 。我们使用的是“客户管理的”CMK,因此我们新创建的 ASG 默认无法再访问它。
显然,这将在 6 月底对现有 ASG 进行更改。
为了解决这个问题,我们着手创建一个可以访问我们的 key 的新 SLR,但后来发现 CloudFormation 还不允许您为 ASG 指定 SLR。
与此同时,我们决定通过更改 CMK 上的策略以允许从默认 SLR 进行访问,从而从根本上创造我们之前遇到的情况。
我们用来创建 CMK 的 CloudFormation 现在看起来像这样:
KmsKey:
Type: AWS::KMS::Key
DeletionPolicy: Retain
Properties:
Description: Used to encrypt AMIs
EnableKeyRotation: True
KeyPolicy:
Version: 2012-10-17
Id: ami-kms-key
Statement:
- Sid: Enable IAM User Permissions
Effect: Allow
Principal:
AWS: !Sub arn:aws:iam::${AWS::AccountId}:root
Action: kms:*
Resource: "*"
- Sid: Allow use of the key by the default service linked role
Effect: Allow
Principal:
AWS:
- !Sub arn:aws:iam::${AWS::AccountId}:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling
Action:
- kms:Encrypt
- kms:Decrypt
- kms:ReEncrypt*
- kms:GenerateDataKey*
- kms:DescribeKey
Resource: "*"
- Sid: Allow attachment of persistent resources
Effect: Allow
Principal:
AWS:
- !Sub arn:aws:iam::${AWS::AccountId}:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling
Action:
- kms:CreateGrant
Resource: "*"
Condition:
Bool:
kms:GrantIsForAWSResource: true
关于amazon-web-services - ASG 无法再使用加密的 EBS 根卷启动实例,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/50270264/