Когда вы встраиваете учётные данные в AMI, они расходятся с каждой копией образа, остаются впечатанными в снимки и могут оказаться в аккаунтах или регионах, о которых вы и не думали. Достаточно, чтобы кто-то с правом чтения образа их извлёк. А поскольку образы хранятся по версиям, секрет может пережить тот момент, когда вы считали, что уже его сменили.
Золотое правило: образ определяет машину; секреты доставляются во время выполнения.
Где должны жить секреты
| Сервис | Облако или среда | Идеален для |
|---|---|---|
| AWS Secrets Manager | AWS | Сменяемые учётные данные, нативная интеграция |
| AWS SSM Parameter Store | AWS | Простые параметры и секреты, недорого |
| HashiCorp Vault | Мультиоблако | Динамические секреты и тонкий контроль |
| Azure Key Vault / Google Secret Manager | Azure / GCP | Нативные аналоги в каждом облаке |
Держите секреты в специализированном менеджере, никогда не в образе и не в открытом user-data.
Правильный подход: идентичность вместо паролей
Самый безопасный способ дать инстансу доступ к ресурсам — не пароль, а идентичность. В AWS привязанная к инстансу роль IAM позволяет получать временные и автоматически обновляемые учётные данные, и ни один ключ не путешествует внутри образа.
- Роли IAM для инстансов: инстанс принимает роль и получает временные учётные данные.
- IRSA в Kubernetes: идентичность на уровне пода, без общих ключей на узле.
- Динамические секреты в Vault: короткоживущие учётные данные по запросу.
- Подстановка во время выполнения: приложение читает секрет из менеджера при старте, а не из вшитого файла.
Защищайте метаданные: IMDSv2
Временные учётные данные роли получают через сервис метаданных инстанса. Атакующий, эксплуатирующий SSRF, мог бы попытаться их украсть. IMDSv2 требует сессионный токен и снижает риск такого класса атак: сделайте его обязательным при запусках.
Гигиена: не оставляйте следов в образе
- Перед запечатыванием AMI удалите истории команд, логи с учётными данными, временные SSH-ключи и файлы конфигурации с секретами.
- Просканируйте образ на секреты инструментами вроде gitleaks или trufflehog, адаптированными к файловым системам.
- Не оставляйте лишних авторизованных ключей в
~/.ssh/authorized_keys. - Избегайте публичных AMI с секретами: публикуя, убедитесь, что ничего не утекает.
Быстрый чек-лист
- Ноль вшитых секретов в образе.
- Менеджер секретов с ролями или федеративной идентичностью.
- Обязательный IMDSv2.
- Сканирование секретов в конвейере.
- Уборка следов перед запечатыванием.
Часто задаваемые вопросы
А если приложению нужен секрет при старте?
Пусть читает его из менеджера секретов во время выполнения, используя идентичность инстанса. Тогда секрет никогда не путешествует внутри образа и меняется без пересборки.
Безопасно ли передавать секреты через user-data?
Не в открытом виде: user-data читается из метаданных. Максимум — используйте его, чтобы указать, какой секрет забрать из менеджера, защитив метаданные через IMDSv2.
Как понять, есть ли в образе уже вшитые секреты?
Просканировать его инструментами обнаружения секретов по файловой системе и до использования проверить файлы конфигурации, истории команд и авторизованные ключи.
В imaxe.cloud мы строим образы, свободные от учётных данных и рассчитанные на интеграцию с менеджерами секретов и федеративной идентичностью.
