Безопасно ли хранить сценарии оболочки User-Data EC2 в частном ведро S3?

У меня есть AS2 ASG на AWS, и я заинтересован в хранении оболочки script, которая использовалась для создания экземпляра любого экземпляра в ведре S3, и он загружался и запускался при создании экземпляра, но все это чувствует себя немного шатким даже хотя я использую IAM Instance Role, передавая через HTTPS и шифруя сам script, находясь в состоянии покоя в ведре <3 > с помощью KMS, используя S3 Server Side Encryption (потому что метод KMS выбрал ошибку "Неизвестно" ).

Настройка

  • Создан IAM Instance Role, который присваивается любому экземпляру в моей ASG после создания экземпляра, в результате мои AWS-кредиты запекаются в экземпляр как ENV vars
  • Загружено и зашифровано my Instance-Init.sh script до S3, что приводит к частной конечной точке, например: https://s3.amazonaws.com/super-secret-bucket/Instance-Init.sh

В поле User-Data

Я ввожу следующее в поле User Data при создании Launch Configuration Я хочу, чтобы моя ASG использовала:

#!/bin/bash

apt-get update
apt-get -y install python-pip
apt-get -y install awscli
cd /home/ubuntu
aws s3 cp s3://super-secret-bucket/Instance-Init.sh . --region us-east-1
chmod +x Instance-Init.sh
. Instance-Init.sh
shred -u -z -n 27 Instance-Init.sh

Вышеописанное делает следующее:

  • Списки пакетов обновлений
  • Устанавливает Python (требуется для запуска aws-cli)
  • Устанавливает aws-cli
  • Изменения в каталоге /home/ubuntu
  • Использует aws-cli для загрузки файла Instance-Init.sh из S3. Из-за IAM Role, назначенного моему экземпляру, мои AWS-кредиты автоматически обнаруживаются aws-cli. IAM Role также предоставляет моему экземпляру разрешения, необходимые для дешифрования файла.
  • Делает его исполняемым
  • Запускает script
  • Удаляет script после его завершения.

Instance-Init.sh script

script сам будет делать такие вещи, как установка ENV vars и docker run контейнеров, которые мне нужно развернуть на моем экземпляре. Своего рода:

#!/bin/bash

export MONGO_USER='MyMongoUserName'
export MONGO_PASS='Top-Secret-Dont-Tell-Anyone'

docker login -u <username> -p <password> -e <email>
docker run - e MONGO_USER=${MONGO_USER} -e MONGO_PASS=${MONGO_PASS} --name MyContainerName quay.io/myQuayNameSpace/MyAppName:latest


Очень удобно

Это создает очень удобный способ обновления сценариев User-Data без необходимости создавать новый Launch Config каждый раз, когда вам нужно внести незначительные изменения. И он отлично справляется с получением ENV vars из вашей кодовой базы и в узкое контролируемое пространство (сам Instance-Init.sh script).

Но все это чувствует себя немного неуверенно. Идея поместить мои master DB файлы в файл на S3 вызывает беспокойство, если не сказать больше.

Вопросы

  • Является ли это обычной практикой или я вижу здесь плохую идею?
  • Является ли факт, что файл загружен и хранится (хотя и ненадолго) в новом экземпляре, является уязвимостью вообще?
  • Есть ли лучший способ для удаления файла более безопасным способом?
  • Неважно, удаляется ли файл после его запуска? Учитывая, что секреты передаются в ENV vars, кажется почти излишним удалить файл Instance-Init.sh.
  • Есть ли что-то, что мне не хватает в мои зарождающиеся дни?

Спасибо за любую помощь заранее.

Ответы

Ответ 1

То, что вы описываете, - это почти то, что мы используем для создания экземпляров контейнеров Docker из нашего реестра (теперь мы используем v2 self-hosting/private, s3-backed-docker-registry вместо Quay). FWIW, у меня было такое же ощущение "это кажется рискованным", что вы описываете, когда сначала наступаете на этот путь, но уже через год после этого - и сравниваете с альтернативой хранения этих конфиденциальных данных конфигурации в репо или запекались в image - Я уверен, что это один из лучших способов обработки этих данных. Теперь, когда мы говорим, мы в настоящее время смотрим на использование Hashicorp нового программного обеспечения Vault для развертывания секретов конфигурации для замены этой "общей" зашифрованной секретной оболочки script контейнер (скажем, пять раз быстрее). Мы думаем, что Vault будет эквивалентом аутсорсинга криптографии для сообщества с открытым исходным кодом (где он принадлежит), но для хранения конфигурации.

В меньшем количестве слов мы не сталкиваемся со многими проблемами с очень похожей ситуацией, которую мы используем в течение года, но теперь мы рассматриваем использование внешнего проекта с открытым исходным кодом (Hashicorp Vault) для замены нашего доморощенного метод. Удачи!

Ответ 2

Альтернативой Vault является использование credstash, который использует AWS KMS и DynamoDB для достижения аналогичной цели.

Я фактически использую credstash для динамического импорта конфиденциальных данных конфигурации при запуске контейнера через простую точку входа script - таким образом, конфиденциальные данные не отображаются через докеревую проверку или в журналах докеров и т.д.

Здесь примерная точка входа script (для приложения Python) - красота здесь заключается в том, что вы все равно можете передавать учетные данные через переменные среды для сред, отличных от AWS/dev.

#!/bin/bash
set -e

# Activate virtual environment
. /app/venv/bin/activate

# Pull sensitive credentials from AWS credstash if CREDENTIAL_STORE is set with a little help from jq
# AWS_DEFAULT_REGION must also be set
# Note values are Base64 encoded in this example
if [[ -n $CREDENTIAL_STORE ]]; then
  items=$(credstash -t $CREDENTIAL_STORE getall -f json | jq 'to_entries | .[]' -r)
  keys=$(echo $items | jq .key -r)
  for key in $keys
  do
    export $key=$(echo $items | jq 'select(.key=="'$key'") | .value' -r | base64 --decode)
  done
fi

exec [email protected]