Comments 13
Ну, если рассматривать Hashicorp, то почему бы не рассмотреть и Consul для хранения секретов?
вопрос возможно дурацкий: где хранить секреты для доступа в Hashicorp Vault ?
если настраивать его "для людей", то понятно - человек сам введет логин и пароль в веб-интерфейсе.
а если "для автоматов" ?
Нужен какой-то identity, привязанный к сервису, и способ его аутентификации. Например, если в облаках - то к сервису привязывается выделенная для него AWS IAM Role, для которой обвязка AWS предоставляет сервису временные AWS-креды, с помощью которых сервис генерирует нужный материал для аутентификации в Vault (в котором специально настраивается бакенд аутентификации AWS), или для Google Cloud просто проверяется OIDC-токен сервис-аккаунта соответствующего сервису (тоже нужно настроить соответствующий бакенд в Vault). В случае k8s тоже можно аутентифицироваться в vault через oidc токен сервис аккаунта пода.
Если не в облаке, то в статье упоминается AppRole аутентификация, в рамках которой штука, которая запускает или деплоит ваш сервис, получает в Vault секретную строку, которую ваш сервис сможет обменять (одноразово, в течении какого времени) на токен.
Где деплоятся контейнеры? Если в кубер там кластер может выдать jwt ключ, vault настроен для этого метода аутенфикации, инжектор подтягивает секреты и включает их в поды через sidecar контейнеры.
https://developer.hashicorp.com/vault/tutorials/kubernetes/kubernetes-external-vault
В целом методов аутентификации много. И для куба есть альтернативы. Все подробно описано в документации.
Ага, шифруйте. А как расшифровывать? Ключ шифрования лежит тут же? Смысл шифрования тогда?
Ни один из способов не является панацеей. Шифрование ключей помогает от случаев утечки кода (например в гитхаб), но не локального взлома сервера.
Как я понимаю, тут суть в том, чтобы расшифрованное было только на самом сервере, а не на машине разработчика (которому может и не положенно иметь доступ к проду) и в гит репозитории (куда вообще могут иметь доступ левые люди, которые даже не работают на этом проекте).
И если уж храним секреты в гит, то хотя бы ключ дешифрования доверяем только CI/CD.
Или храним в git токен доступа к Vault, но сам Vault недоступен извне.
Короче, разделить секреты и ключ их шифрования так, чтобы единственная машина, где они оказываются одновременно вместе был сам прод сервер.
Про вольт: вариантов три. Сайдкары (дорого, если у тебя 100500 микриков, меньше самих сайд каров), из приложений (порой, накладно разработчикам), а есть есть bank-vaults (через вебхуки в моменте запуска пода) - тут еще плюс, что секреты не видно в envs внутри контейнера, если он правильно собран.
Также он позволяет подавать секреты не только в рантайм, ноби в конфигмапы и секреты куба. Это то, что ты хранишь секреты в base64 опять же в репе. Да по итогу они рендерятся в куб в открытом виде, но в куб еще надо попасть, а там уже и шифрование etcd можно например.
А можете про bank-vaults чуть подробней рассказать? Что распространено для кубера из этого типа хранилищ?
это не тип, это хук, работающий в паре с вольтом. он в отличие от родного живого сайдкара мутирует в init-контейнер. да, теряется автообновление (ротация), но она в 90% не нужна прикладу, а ресурсы очень экономятся.
почитать тут https://bank-vaults.dev/docs/mutating-webhook/
version
в docker-compose.yaml
в 2025 году…
Как организовать безопасное хранение секретов в Docker: лучшие практики