Назад | Перейти на главную страницу

Безопасное хранение учетных данных для доступа к AWS на локальном сервере

Как лучше всего хранить учетные данные для доступа к AWS IAM на физическом / виртуальном сервере, чтобы работающие на нем службы могли получить к нему доступ?

Это проблема, которая была решена давно для инстансов EC2 с помощью профили экземпляров но я не знаю, каковы лучшие практики для серверов, отличных от EC2 (например, арендованный ящик в центре обработки данных, RaspberryPi, сидящий дома и т. д.).

Заметка: Я не говорю здесь о среде разработки на персональном компьютере или ноутбуке. Есть несколько решений для этого сценария.

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

Один из подходов, который я рассматриваю, - это использование Агент AWS System Manager (который уже установлен в коробке), чтобы периодически извлекать ключи из секретного менеджера AWS или хранилища параметров. Сам агент использует настраиваемую роль IAM при выполнении команд и вызове рабочих процессов автоматизации на хосте, поэтому я должен иметь возможность добавлять дополнительные политики IAM по мере необходимости для доступа к хранилищу параметров или другим сервисам AWS.

Интересно, есть ли какие-нибудь хорошие практики для этого. Я не хочу изобретать колесо заново, если проблема решена, или предлагать переваренное и сложное индивидуальное решение.

Так или иначе, вам придется некоторые полномочия на сервере, который будет использоваться для получения ключей AWS. По крайней мере, попробуйте ограничить по IP. Вот один из способов сделать это:

  • Создайте специальный Пользователь IAM для каждого сервера и Роль IAM.
  • В Роль IAM имеет все привилегии, необходимые вашим задачам, пока Пользователь IAM имеет другие привилегии, кроме sts:AssumeRole для этого Роль IAM.
  • Вот уловка: в пользовательском IAM sts:AssumeRole использование политики Condition: { IPAddress: ... } чтобы ограничить его использование только IP-адресом вашего сервера. Подробнее см. Здесь.

Вы можете спросить, почему я предлагаю пользователя IAM и отдельную роль IAM - это потому, что Условие IP-адреса должно быть указано для каждого Разрешения в политике. Если вы примените его к sts:AssumeRole у вас есть единое место, где вы это контролируете. Если вы прикрепите все свои разрешения / политики непосредственно к пользователю IAM, вам придется снова и снова указывать одно и то же условие для каждого разрешения.

Надеюсь, это поможет :)