Comments 9
Исчерпывающе, спасибо.
Какие еще промышленные стандарты хранения секретов вы используете?
А если рассмотреть кейс с другими оркестраторами контейнеров (not k8s) ? Возможно у вас в компании выработались определенные стандарты работы с чувствительными данными ?
Спасибо за статью.
Как вы думаете можно ли ли использовать hashicorp vault для хранения секретов "внешних", конечных пользователей (то есть это могут быть десятки или даже сотни тысяч запросов одновременно), например api-ключей?
А как эти vault'ы зашищают секреты?
То есть, к примеру, я через руткит или другим способом получил доступ к серверу.
Что мне мешает прочитать данные vault'а или запросить у него секрет?
Прошу прощения за ткпой вопрос, я просто из тех разрабочиков, которые "деплоят" вордпрес по ftp :]
в бд всё в зашифрованном виде лежит, чтобы получить доступ к секретам, нужно попасть непосредственно в веб-интерфейс (апишку) под учёткой с соответствующими привилегиями, вне веб-интерфейса (апишки) ничего получить невозможно.
более того, при рестарте ваулта он запечатывается, и чтобы распечатать его, нужен набор ключей, в идеальном мире их раздают разным людям, поэтому для распечатки нужно будет дёрнуть каждого из них, чтобы он ввёл свой ключ
Да секреты уже не хранятся в etcd, а в Vault, тем самым защищая от утечки базу etcd, но секреты ведь также доступны на просмотр через интерфейс кубернетес. В чем смысл, если они также доступны на просмотр через интерфейс кубера?
а кто заставляет выдавать всем пользователя кубернетеса права на чтение ресурса Secret? обычно права выдают на работу с ресурсами Pod, Service, Deployment, Ingress, но не на Secret, и еще не стоит выдавать всем кому попало доступы на exec, пользователю не обязательно иметь права читать секреты кубера, достаточно лишь знать имена секретов, чтобы смапить их в переменные окружения или файлы.
но здесь есть один нюанс, пользователь может задеплоить приложеньку, которая распечатает секреты переменные окружения в stdout/stderr, кубер это залогирует, а пользователь сможет забрать секреты через pod logs, поэтому доступ к логам тоже не стоит раздавать всем кому попало.
короче моментов много, но кубер достаточно гибкий, чтобы настроить матрицу права под конкретные нужды.
а откуда идея что секреты уже не будут храниться в etcd ?
Безопасное хранение secrets в Kubernetes