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

Ответ 1

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

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

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

ИЗМЕНИТЬ

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

UPDATE

ОК, здесь идет сравнительное сравнение различных подходов, обсуждаемых до сих пор:

• Защита данных, когда хранится в AMI user-data незашифрованном
  • низкий
  • данные прозрачного текста доступны любому пользователю, которому удаётся войти в AMI, и имеет доступ к telnet, curl, wget и т.д. (может получить доступ к clear-text http://169.254.169.254/1.0/user-data)
  • вы уязвимы для атак на прокси-запрос (например, злоумышленник спрашивает Apache, который может или не может работать в AMI, чтобы получить и переслать clear-text http://169.254.169.254/1.0/user-data)
• Безопасность данных, когда хранится в AMI user-data и зашифрована (или расшифровывается) с легкодоступным ключом
  • низкий
  • легкодоступный ключ (пароль) может включать:
    • жестко закодирован в script внутри ABI (где ABI может быть получен злоумышленником)
    • жестко закодирован в script в самом AMI, где script читается любым пользователем, которому удается войти в AMI
    • любую другую легкодоступную информацию, такую ​​как открытые ключи и т.д.
    • любой закрытый ключ (его открытый ключ может быть легко доступен)
  • с учетом легкодоступного ключа (пароля) применяются те же проблемы, что указаны в пункте 1, а именно:
    • дешифрованные данные доступны любому пользователю, которому удастся войти в AMI, и имеет доступ к telnet, curl, wget и т.д. (может получить доступ к clear-text 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 учетные данные для различные узлы, возможно, параллельно, с правильной принадлежностью и разрешениями.

Ответ 2

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

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

Ответ 3

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

• Создать профиль экземпляра
• Создайте новую роль IAM

• Назначьте политику ранее созданной роли, например:

  { "Утверждение": [   {      "Сид": "Stmt1369049349504",      "Действие": "sqs:",      "Эффект": "Разрешить",      "Ресурс": ""   } ] }

• Свяжите роль и профиль экземпляра вместе.

• Когда вы запускаете новый экземпляр 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')

Ответ 4

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

http://docs.aws.amazon.com/IAM/latest/UserGuide/WorkingWithRoles.html

Ответ 5

Как уже упоминалось ранее, вам не нужно хранить учетные данные AWS для экземпляра EC2, используя роли IAM -  https://aws.amazon.com/blogs/security/a-safer-way-to-distribute-aws-credentials-to-ec2/. Я добавлю, что вы можете использовать тот же метод и для безопасного хранения учетных данных NON-AWS для вашего экземпляра EC2, например, если у вас есть некоторые учетные данные db, которые вы хотите сохранить в безопасности. Вы сохраняете учетные данные не-aws в буклете S3 и используете роль IAM для доступа к этому ведру. вы можете найти более подробную информацию об этом здесь - https://aws.amazon.com/blogs/security/a-safer-way-to-distribute-aws-credentials-to-ec2/