Как лучше всего передать учетные данные AWS в качестве пользовательских данных в экземпляр EC2?

https://stackoverflow.com/questions/640838

22-07-2019
|

Вопрос

У меня есть архитектура обработки заданий, основанная на AWS, которая требует, чтобы экземпляры EC2 запрашивали S3 и SQS.Чтобы запущенные экземпляры имели доступ к API, учетные данные отправляются как пользовательские данные (-f) в форме сценария оболочки в кодировке Base64.Например:

$ cat ec2.sh
...
export AWS_ACCOUNT_NUMBER='1111-1111-1111'
export AWS_ACCESS_KEY_ID='0x0x0x0x0x0x0x0x0x0'
...
$ zip -P 'secret-password' ec2.sh
$ openssl enc -base64 -in ec2.zip

Запускается много экземпляров...

$ ec2run ami-a83fabc0 -n 20 -f ec2.zip

Каждый экземпляр декодирует и расшифровывает ec2.zip, используя «секретный пароль», который жестко запрограммирован в сценарии инициализации.Хотя это действительно работает, у меня есть две проблемы с моим подходом.

«zip -P» не очень безопасен
Пароль жестко запрограммирован в экземпляре (это всегда «секретный пароль»).

Метод очень похож на описанный здесь

Есть ли более элегантный или общепринятый подход?Использование gpg для шифрования учетных данных и сохранение закрытого ключа в экземпляре для его расшифровки — это подход, который я сейчас рассматриваю, но мне не известны какие-либо предостережения.Могу ли я использовать пары ключей AWS напрямую?Я упускаю какую-то очевидную часть API?

Решение

Вы можете сохранить учетные данные на компьютере (или передать, использовать, а затем удалить их).

Вы можете передать учетные данные по защищенному каналу (например,с использованием scp с неинтерактивной аутентификацией, например.пара ключей), чтобы вам не нужно было выполнять какое-либо специальное шифрование (только убедитесь, что разрешения правильно установлены на 0400 в ключевом файле всегда, например.установите права доступа к основным файлам и используйте scp -p)

Если приведенное выше не дает ответа на ваш вопрос, предоставьте более подробную информацию.какова ваша установка и чего вы пытаетесь достичь.Должны ли действия EC2 инициироваться на нескольких узлах из центрального расположения?Доступен ли SSH между несколькими узлами и центральным расположением?И т. д.

РЕДАКТИРОВАТЬ

Вы рассмотрели параметризация вашего AMI, требуя от тех, кто создает экземпляр вашего AMI, сначала заполнить пользовательские данные (ec2-run-instances -f user-data-file) с их ключами AWS?Затем ваш AMI может динамически получать эти параметры для каждого экземпляра из http://169.254.169.254/1.0/user-data.

ОБНОВЛЯТЬ

Хорошо, вот сравнение различных подходов, обсуждавшихся до сих пор, с точки зрения безопасности:

Безопасность данных, когда хранится в AMI user-data незашифрованный
- низкий
- данные в открытом виде доступны для любой пользователь, которому удается войти в AMI и имеет доступ к telnet, curl, wget, и т. д.(может получить доступ к открытому тексту http://169.254.169.254/1.0/user-data)
- вы уязвимы для атак с использованием прокси-запросов (например,злоумышленник просит Apache, который может работать или не работать на AMI, получить и переслать открытый текст. http://169.254.169.254/1.0/user-data)
Безопасность данных, когда хранится в AMI user-data и зашифрован (или дешифрован) с помощью легкодоступного ключа
- низкий
- Легкодоступный ключ (пароль) может включать в себя:
  - ключ, жестко закодированный в скрипте внутри ABI (где ABI может получить злоумышленник)
  - ключ, жестко закодированный в сценарии на самом AMI, где сценарий может быть прочитан любой пользователь, которому удается войти в AMI
  - любая другая легкодоступная информация, такая как открытые ключи и т. д.
  - любой закрытый ключ (его открытый ключ можно легко получить)
- при наличии легкодоступного ключа (пароля) возникают те же проблемы, указанные в пункте 1, а именно:
  - расшифрованные данные доступны любой пользователь, которому удается войти в AMI и имеет доступ к telnet, curl, wget, и т. д.(может получить доступ к открытому тексту http://169.254.169.254/1.0/user-data)
  - вы уязвимы для атак с использованием прокси-запросов (например,злоумышленник просит Apache, который может работать или не работать на AMI, получить и переслать зашифрованные данные. http://169.254.169.254/1.0/user-data, впоследствии расшифрованный с помощью легкодоступного ключа)
Безопасность данных, когда хранится в AMI user-data и зашифрован труднодоступным ключом
- средний
- зашифрованные данные доступны любой пользователь, которому удается войти в AMI и имеет доступ к telnet, curl, wget, и т. д.(может получить доступ к зашифрованному http://169.254.169.254/1.0/user-data)
  - затем можно попытаться расшифровать зашифрованные данные с помощью грубой силы.
Безопасность данных, когда хранится на AMI, в защищенном месте (нет добавленной стоимости для шифрования)
- выше
- данные доступны только одному пользователю, пользователю, которому данные необходимы для работы
  - напримерфайл принадлежит пользователю: пользователь с маской 0600 или 0400
- злоумышленник должен иметь возможность выдать себя за конкретного пользователя, чтобы получить доступ к данным
  - дополнительные уровни безопасности, такие как запрет прямого входа пользователя в систему (необходимость прохождения через root для интерактивного олицетворения) повышает безопасность

Таким образом, любой метод, связанный с AMI user-data не самый безопасный, поскольку получение доступа к любой пользователь на машине (самое слабое место) подвергает риску данные.

Это можно было бы смягчить, если бы учетные данные S3 требовались только в течение ограниченного периода времени (т. е.только в процессе развертывания), если AWS позволял перезаписывать или удалять содержимое user-data когда это будет сделано (но, похоже, это не так). Альтернативой может быть создание временных учетных данных S3 на время процесса развертывания, если это возможно (компрометация этих учетных данных из-за user-data, после завершения процесса развертывания и признания учетных данных недействительными с помощью AWS, больше не представляет угрозы безопасности.)

Если вышеизложенное неприменимо (например,Учетные данные S3 необходимы развернутым узлам на неопределенный срок) или невозможны (например.не может выдать временные учетные данные S3 только для развертывания), тогда лучшим способом остается стиснуть зубы и scp учетные данные для различных узлов, возможно, параллельно, с правильным владельцем и разрешениями.

Другие советы

Я написал статью, в которой рассматриваются различные способы безопасной передачи секретов в инстанс EC2, а также за и против; минусы каждого.

http: // www.shlomoswidler.com/2009/08/how-to-keep-your-aws-credentials-on-ec2.html

Лучший способ - использовать профили экземпляров.Основная идея заключается в следующем:

Создать профиль экземпляра
Создайте новую роль IAM
Назначьте политику ранее созданной роли, например:

{ "Заявление":[ { "Сид":"Stmt1369049349504", "Акция":"кв:", "Эффект":"Разрешить", "Ресурс":"" } ] }
Свяжите роль и профиль экземпляра вместе.
При запуске нового экземпляра EC2 обязательно укажите имя профиля экземпляра.

Если все работает хорошо и библиотека, которую вы используете для подключения к сервисам AWS из вашего экземпляра EC2, поддерживает извлечение учетных данных из метаданных экземпляра, ваш код сможет использовать сервисы AWS.

Полный пример взят из списка рассылки boto-user:

Во-первых, вам необходимо создать документ политики JSON, в котором будет указано, к каким сервисам и ресурсам должна иметь доступ роль IAM.например, эта политика разрешает все действия S3 для сегмента «my_bucket».Вы можете использовать любую политику, подходящую для вашего приложения.

BUCKET_POLICY = """{
  "Statement":[{
    "Effect":"Allow",
    "Action":["s3:*"],
    "Resource":["arn:aws:s3:::my_bucket"]}]}"""

Далее вам необходимо создать профиль экземпляра в IAM.

import boto
c = boto.connect_iam()
instance_profile = c.create_instance_profile('myinstanceprofile')

Получив профиль экземпляра, вам необходимо создать роль, добавить роль в профиль экземпляра и связать политику с этой ролью.

role = c.create_role('myrole')
c.add_role_to_instance_profile('myinstanceprofile', 'myrole')
c.put_role_policy('myrole', 'mypolicy', BUCKET_POLICY)

Теперь вы можете использовать этот профиль экземпляра при запуске экземпляра:

ec2 = boto.connect_ec2()
ec2.run_instances('ami-xxxxxxx', ..., instance_profile_name='myinstanceprofile')

Я хотел бы отметить, что больше нет необходимости предоставлять какие-либо учетные данные для вашего экземпляра EC2. Используя IAM, вы можете создать роль для ваших экземпляров EC2. В этих ролях вы можете установить детализированные политики, которые позволяют вашему экземпляру EC2, например, получать конкретный объект из определенного сегмента S3 и не более. Подробнее о ролях IAM можно прочитать в документации по AWS:

http://docs.aws.amazon.com/IAM/ последняя / UserGuide / WorkingWithRoles.html

Как уже указывали другие, вам не нужно хранить учетные данные AWS для экземпляра EC2, используя роли IAM - https: // aws .amazon.com / блог / безопасность / а-безопасней пути к распределите-AWS-учетные-на-ec2 / . Я добавлю, что вы можете использовать тот же метод и для безопасного хранения учетных данных NON-AWS для своего экземпляра EC2, например, если у вас есть некоторые учетные данные БД, которые вы хотите сохранить в безопасности. Вы сохраняете учетные данные non-aws на S3 Bukcet и используете роль IAM для доступа к этому сегменту. вы можете найти более подробную информацию об этом здесь - https://aws.amazon.com/blogs/security/using-iam-roles-to-distribute-non-aws-credentials-to-your-ec2-instances/

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow