ASG больше не может запускать экземпляры с зашифрованным корневым томом EBS - PullRequest
Новая
       25

ASG больше не может запускать экземпляры с зашифрованным корневым томом EBS

0 голосов
/ 10 мая 2018

Недавно мы развернули новое приложение, которое использует ASG, настроенную для запуска экземпляров с зашифрованными корневыми томами EBS. У нас есть много существующих приложений, которые работают именно с этой настройкой, но наша новая ASG отказывается запускать экземпляры. Экземпляры даже не появляются, и мы видим ошибку в истории активности ASG: Client.InternalError: Client error on launch.

После экспериментов мы обнаружили, что если мы заменяем AMI, который мы используем, на тот, который не зашифрован, все начинает работать как положено. Смущает то, что мы используем точно такой же AMI для другой ASG, и все это работает как положено (сформировано из почти идентичных шаблонов CloudFormation). Аналогичным образом мы можем запустить экземпляр EC2 непосредственно из консоли, используя тот же AMI и профиль экземпляра.

Кто-нибудь видел такое поведение раньше?

В других местах я нашел некоторые решения (которые позволили нам доказать, что это как-то связано с зашифрованным томом), например это из AWS , но, похоже, они не имеют прямого отношения к нашему сценарию.

1 Ответ

0 голосов
/ 10 мая 2018

В итоге мы обнаружили сообщение на форуме AWS , в котором подробно описываются связанные со службой роли (SLR). Кажется, что когда-то за последние пару месяцев они изменили поведение ASG (только для вновь созданных ASG). Ранее ASG мог использовать любой KMS CMK, но это было изменено, чтобы он мог получить доступ только к ключу по умолчанию. Мы используем «управляемый клиентом» CMK, поэтому наша вновь созданная ASG больше не может получить к нему доступ по умолчанию.

По-видимому, это будет изменено на существующих ASG к концу июня.

Чтобы исправить это, мы приступили к созданию новой зеркальной фотокамеры с доступом к нашему ключу, но позже обнаружили, что CloudFormation еще не позволяет указывать зеркальную зеркальную копию для ASG.

Тем временем мы решили по существу создать ситуацию, которая у нас была раньше, изменив политику на нашем CMK, чтобы разрешить доступ из зеркалки по умолчанию.

Облачная формация, которую мы используем для создания нашего CMK, теперь выглядит следующим образом: 

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
...