Question

我们最近部署了一个新应用程序，该应用程序使用配置为使用加密EBS根卷启动实例的ASG。我们有很多现有的应用程序正好使用这个设置，但我们的新ASG拒绝启动实例。实例甚至没有出现，我们在ASG活动历史记录中看到错误：Client.InternalError: Client error on launch。

经过实验，我们发现如果我们交换AMI，我们使用的是未加密的AMI，它们都按预期开始工作。令人困惑的是，我们在不同的ASG上使用完全相同的AMI，并且它们都按预期工作（由几乎相同的CloudFormation模板构成）。同样，我们可以使用相同的AMI和实例配置文件直接从控制台启动EC2实例。

之前有没有人见过这种行为？

我在其他地方找到了一些解决方案（这导致我们证明它与加密卷有关），例如this from AWS，但它们似乎与我们的场景没有直接关系。

Answer 1

我们最终找到了详细说明服务链接角色（SLR）的an AWS forum post。似乎在过去几个月的某个时候，他们已经改变了ASG的行为方式（仅适用于新创建的ASG）。以前，ASG可以使用任何KMS CMK，但这已经更改，因此它只能访问默认密钥。我们正在使用“客户管理”的CMK，因此我们新创建的ASG默认情况下无法再访问它。

显然，这将在6月底的现有ASG上进行更改。

为了解决这个问题，我们开始创建一个可以访问我们密钥的新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

ASG无法再使用加密的EBS根卷

1 个答案: