Задача по шифрованию томов может возникать по разным причинам. Но чаще всего при выставлении требований - соответствие HIPAA или наличие PHI.
Есть дизайн, в котором несколько тиров на базе BeansTalk MultiContainer Docker.
После деплоймента неожиданно всплывает требование по шифрации томов.
Переделывать ничего не хочется. А задача упирается на первый взгляд в тупик. В CloudFormation нет опций для указания шифрования томов. Вообще! Не поддерживается такая возможность пока.
Немного общих тезисов:
Preconfigured Beanstalk AMI это не простой AMI, а AMI со специфичным набором в UserData. Это набор команд, файлов и скриптов, которые разворачиваются при старте инстанса в бинстолк окружение. Это означает для нас что просто так взять AMI из развернутого окружения нельзя. Уже поздно его брать, потому что оно уже модифицировано скриптами.
Кроме этого, скриптами будет подтянут дополнительный том EBS для Docker. А нам надо зашифровать и его. Есть несколько подходов к решению задачи.
Один из них это подготовка EBS томов заранее, с шифрованием и подключение их к уже развернутым инстансам с последующим клонированием содержимого.
Я отправился по другому пути. Не факт что он лучше, но в моей задаче отработал.
Смысл его в подготовке AMI с уже зашифрованными томами KMS.
Смотрим какой AMI был использован при разворачивании EBT (ElasticBeanstalk). Это смотрим в Description на любую EC2 в рабочем окружении EBT, которое хотим модифицировать.
Идем в консоль EC2, говорим Launch, в качестве AMI ищем и выбираем нужный нам. Он будет в разделе Community AMIs скорее всего.
В UserData ОБЯЗАТЕЛЬНО добавим:
#cloud-config
repo_upgrade: none
repo_releasever: 2017.03
это заморозит процесс обновления и скриптов при старте инстанса, пока мы его подготавливаем. repo_releaserver: здесь цифра 2017.03 вычисляется из имени родительского AMI. В описании AMI указано какой год и месяц релиза был использован для его создания. Вот эти цифры и берем.
Запускаем Launch, ждем завершения создания инстанса. Смотрим в его описание в раздел о томах. Сейчас есть только один том - root, /dev/xvda. И он не зашифрован, как и ожидалось.
Останавливаем инстанс (Stop). Идем в раздел Volumes. Находим наш том и делаем ему Snapshot. После создания Snapshot так же будет НЕ зашифрован. Но это этап и его делать придется. Далее выбираем созданный SnapShot , Action -> Copy. Ставим крыжик Encryption!
Вот теперь у нас есть снимок зашифрованый нашим KMS (если сделали отдельный ключ для этих целей, выбирайте его при копировании).
Важно - перед следующим действием смотрите в какой AZ лежит наша EC2 instance, которую мы готовим.
Теперь из этого снимка Action -> Create Volume. Здесь выбрать нужно ту AZ, где и наша EC2!
Теперь у нас есть том, он зашифрован ключом KMS, и это копия нашего Boot Volume.
Находим теперь наш том, который сейчас является текущим и активным Boot Volume для нашей Ec2, говорим ему Detach. На его место нужно подключить наш новый зашифрованный том с тем же путем - /dev/xvda
Теперь грязный хак. Создаем НОВЫЙ том, сразу зашифрованый нашим ключом KMS, в моем случае это том 12GB gp2. Я его подключаю к нашей EC2 по пути /dev/xvdcz - именно такой том создают скрипты EBT Preconfigured Docker Multicontainer.
Идем в раздел UserData и убираем наши строчки что мы добавляли ранее. Там должно быть чисто.
Все. теперь делаем из нашей EC2 новый AMI. Этот AMI теперь можно добавить в CFT EBT в OptionSettings ->
{"Namespace" : "aws:autoscaling:launchconfiguration", "OptionName" : "ImageId", "Value": "ami-XXXXXX"}
Делаем Update Stack CloudFormation. Новые инстансы будут на базе нашего AMI и оба тома будут зашифрованы.
Есть дизайн, в котором несколько тиров на базе BeansTalk MultiContainer Docker.
После деплоймента неожиданно всплывает требование по шифрации томов.
Переделывать ничего не хочется. А задача упирается на первый взгляд в тупик. В CloudFormation нет опций для указания шифрования томов. Вообще! Не поддерживается такая возможность пока.
Немного общих тезисов:
Preconfigured Beanstalk AMI это не простой AMI, а AMI со специфичным набором в UserData. Это набор команд, файлов и скриптов, которые разворачиваются при старте инстанса в бинстолк окружение. Это означает для нас что просто так взять AMI из развернутого окружения нельзя. Уже поздно его брать, потому что оно уже модифицировано скриптами.
Кроме этого, скриптами будет подтянут дополнительный том EBS для Docker. А нам надо зашифровать и его. Есть несколько подходов к решению задачи.
Один из них это подготовка EBS томов заранее, с шифрованием и подключение их к уже развернутым инстансам с последующим клонированием содержимого.
Я отправился по другому пути. Не факт что он лучше, но в моей задаче отработал.
Смысл его в подготовке AMI с уже зашифрованными томами KMS.
Смотрим какой AMI был использован при разворачивании EBT (ElasticBeanstalk). Это смотрим в Description на любую EC2 в рабочем окружении EBT, которое хотим модифицировать.
Идем в консоль EC2, говорим Launch, в качестве AMI ищем и выбираем нужный нам. Он будет в разделе Community AMIs скорее всего.
В UserData ОБЯЗАТЕЛЬНО добавим:
#cloud-config
repo_upgrade: none
repo_releasever: 2017.03
это заморозит процесс обновления и скриптов при старте инстанса, пока мы его подготавливаем. repo_releaserver: здесь цифра 2017.03 вычисляется из имени родительского AMI. В описании AMI указано какой год и месяц релиза был использован для его создания. Вот эти цифры и берем.
Запускаем Launch, ждем завершения создания инстанса. Смотрим в его описание в раздел о томах. Сейчас есть только один том - root, /dev/xvda. И он не зашифрован, как и ожидалось.
Останавливаем инстанс (Stop). Идем в раздел Volumes. Находим наш том и делаем ему Snapshot. После создания Snapshot так же будет НЕ зашифрован. Но это этап и его делать придется. Далее выбираем созданный SnapShot , Action -> Copy. Ставим крыжик Encryption!
Вот теперь у нас есть снимок зашифрованый нашим KMS (если сделали отдельный ключ для этих целей, выбирайте его при копировании).
Важно - перед следующим действием смотрите в какой AZ лежит наша EC2 instance, которую мы готовим.
Теперь из этого снимка Action -> Create Volume. Здесь выбрать нужно ту AZ, где и наша EC2!
Теперь у нас есть том, он зашифрован ключом KMS, и это копия нашего Boot Volume.
Находим теперь наш том, который сейчас является текущим и активным Boot Volume для нашей Ec2, говорим ему Detach. На его место нужно подключить наш новый зашифрованный том с тем же путем - /dev/xvda
Теперь грязный хак. Создаем НОВЫЙ том, сразу зашифрованый нашим ключом KMS, в моем случае это том 12GB gp2. Я его подключаю к нашей EC2 по пути /dev/xvdcz - именно такой том создают скрипты EBT Preconfigured Docker Multicontainer.
Идем в раздел UserData и убираем наши строчки что мы добавляли ранее. Там должно быть чисто.
Все. теперь делаем из нашей EC2 новый AMI. Этот AMI теперь можно добавить в CFT EBT в OptionSettings ->
{"Namespace" : "aws:autoscaling:launchconfiguration", "OptionName" : "ImageId", "Value": "ami-XXXXXX"}
Делаем Update Stack CloudFormation. Новые инстансы будут на базе нашего AMI и оба тома будут зашифрованы.
Комментариев нет:
Отправить комментарий