Pull to refresh

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

В целом методов аутентификации много. И для куба есть альтернативы. Все подробно описано в документации.

https://developer.hashicorp.com/vault/docs/auth

Ага, шифруйте. А как расшифровывать? Ключ шифрования лежит тут же? Смысл шифрования тогда?

Ни один из способов не является панацеей. Шифрование ключей помогает от случаев утечки кода (например в гитхаб), но не локального взлома сервера.

Как я понимаю, тут суть в том, чтобы расшифрованное было только на самом сервере, а не на машине разработчика (которому может и не положенно иметь доступ к проду) и в гит репозитории (куда вообще могут иметь доступ левые люди, которые даже не работают на этом проекте).

И если уж храним секреты в гит, то хотя бы ключ дешифрования доверяем только CI/CD.

Или храним в git токен доступа к Vault, но сам Vault недоступен извне.

Короче, разделить секреты и ключ их шифрования так, чтобы единственная машина, где они оказываются одновременно вместе был сам прод сервер.

Про вольт: вариантов три. Сайдкары (дорого, если у тебя 100500 микриков, меньше самих сайд каров), из приложений (порой, накладно разработчикам), а есть есть bank-vaults (через вебхуки в моменте запуска пода) - тут еще плюс, что секреты не видно в envs внутри контейнера, если он правильно собран.

Также он позволяет подавать секреты не только в рантайм, ноби в конфигмапы и секреты куба. Это то, что ты хранишь секреты в base64 опять же в репе. Да по итогу они рендерятся в куб в открытом виде, но в куб еще надо попасть, а там уже и шифрование etcd можно например.

А можете про bank-vaults чуть подробней рассказать? Что распространено для кубера из этого типа хранилищ?

это не тип, это хук, работающий в паре с вольтом. он в отличие от родного живого сайдкара мутирует в init-контейнер. да, теряется автообновление (ротация), но она в 90% не нужна прикладу, а ресурсы очень экономятся.

почитать тут https://bank-vaults.dev/docs/mutating-webhook/

Вы правы, спасибо. Очень мало на сворме пробыл, быстро сбежал на кубер и даже не заметил этой особенности.

Sign up to leave a comment.

Articles