Управление секретами в кластере Kubernetes при помощи Hashicorp Vault / Сергей Носков (Avito)
2 likes1,309 views
Документ описывает управление секретами в кластере Kubernetes с использованием HashiCorp Vault, включая проблемы внутренней безопасности и методы их решения. Также рассматриваются интеграции Vault с системами управления конфигурацией и Kubernetes, подчеркивается важность доверенного авторитета и проверки аннотаций. Приведены примеры рисков и существующих решений для повышения безопасности хранения и распределения секретов.
Управление секретами в кластере Kubernetes при помощи Hashicorp Vault / Сергей Носков (Avito)
- 1. Управление секретами в кластере Kubernetes при помощи Hashicorp Vault Сергей Носков Avito snoskov@avito.ru
- 2. План 1. Управление секретами 2. Hashicorp Vault 3. Vault + Configuration management system 4. Vault + Kubernetes
- 3. Секрет Практически любая конфиденциальная информация ● логин + пароль (например, к БД) ● API-ключ ● ключ сертификата сервера (*.google.com) ● ключ клиентского сертификата (партнёры, Yandex money, QIWI, ...) ● ключ для подписи мобильных приложений статистика Infowatch
- 4. Конфиденциальностьсекретов в ДЦ ○ внешние угрозы - всё хорошо, всё умеем: firewall, VPN, … ○ внутренние угрозы: ● локально на серверах ● репозиторий с кодом, доступ ограничен ● отдельный репозиторий, доступ ограничен ● много отдельных репозиториев, доступ ограничен ● хранить в репозитории Configuration management system или в отдельной БД
- 5. Проблемы ● внутренние утечки ● шифрование ● аудит ● управление доступом x10 - x100 при переходе на микросервисы!
- 6. Hashicorp Vault Хранилище секретов для мира микросервисов и не только ● REST, JSON ● стандартные БД в качестве хранилища ● прозрачное шифрование, с безопасным управлением ключами ● принцип минимальных привилегий и политики доступа ● расширяемые API для авторизации и разных видов секретов ● open source (Mozilla Public License 2.0)
- 7. Vault
- 9. Hashicorp Vault: wrapping Способ делегирования прав на чтение секрета ● создать временный токен, не передавать сам секрет ● передать токен ● прочитать секрет по токену ● … ● PROFIT
- 10. AppRole auth backend Role ID = любой (возможно, секретный) ID + настройки(ttl, num_uses) Secret ID = любой секретный ID
- 11. Проблемы ● проблема курицы и яйца ● недостаток инструментов автоматизации ● нет поиска по “файловой системе” ● не очень удобные политики ● нет встроенного GUI, внедрение веб-UI увеличит риски
- 12. Проблема порочного круга ● секрет нельзя отдавать кому попало ● идентификации недостаточно ● аутентификация не подходит: для получения секрета нужен секрет Решение: авторизация у доверенного авторитета
- 13. Риски доверенного авторитета ● собственные секреты (для выдачи доступа к секретам) ● передача секрета по сети ● запрос секрета внешним клиентом ● запрос легитимным клиентом не своего секрета ● маскировка под легитимного клиента
- 14. Puppet + Hiera Hiera - встроенное в паппет расширяемое иерархическое key-value хранилище с доступом к данным на основе фактов. Например /hiera/host/www1.example.com/ /hiera/hostgroup/www/ /hiera/ssl-terminator/yes/
- 15. Puppet + Hiera + Vault Доверенный авторитет - puppet master
- 16. Секрет-файл { “encoding”: “base64”, “data”: “TE9MIEtFSyBDSEVCVVJFSwo=”, “filename”: ”some.secret”, “mode”: ”400”, “owner”: “root”, “group”: ”root”, }
- 17. Риски hiera как доверенного авторитета ✓ собственные секреты - локально на сервере* ✓ передача секрета по сети - TLS ✓ запрос секрета внешним клиентом - PKI ✓ запрос легитимным клиентом не своего секрета - Hiera ✓ маскировка под легитимного клиента - PKI * не в Vault, но принцип минимальных привилегий соблюдается
- 18. Kubernetes: секреты Чуть лучше хранения в репозитории(если включена аутентификация в etcd): ● нет шифрования ● неудобный контроль ● сложные политики ● работают только внутри Kubernetes ● пока что не расширяются
- 19. Kubernetes: аннотации Призваны расширять функционал k8s. Могут содержать важную для безопасности информацию: ● сетевые политики ● инит-контейнеры ● «Pointers to logging, monitoring, analytics, or audit repositories» Важно: проверять аннотации перед выкаткой подов
- 21. Существующие решения: Kelsey Hightower’s
- 22. Kelsey Hightower’s + init container -> volume -> application + стратегия: push по запросу + авторитет k8s - политика Vault в аннотации - нет шифрования по сети
- 23. Риски Kelsey Hightower’s ! дополнительный риск: можно указать (почти) любую политику Vault ✕ собственные секреты - через environment ✕ передача секрета по сети - не шифруется ✓ запрос секрета внешним клиентом - k8s API ✓ запрос легитимным клиентом не своего секрета - проверка аннотаций ✓ маскировка под легитимного клиента - проверка аннотаций
- 25. Существующие решения: Bootsport’s + все «+» от Kelsey Hightower’s + approle backend - отделение авторизации от секретов + role_id в аннотации - event watch: - привилегии на чтение событий - рассинхронизация - Raft - wrapping - HTTPS = self-signed snakeoil overkill - доставка только токена
- 26. Риски Bootsport’s ✕ собственные секреты - через СonfigMap ✓ маскировка под легитимного клиента - надо знать role_id ✓ запрос легитимным клиентом не своего секрета - надо знать role_id ✓ передача секрета по сети - TLS ✓ запрос секрета внешним клиентом - k8s API ✓ маскировка под легитимного клиента - проверка аннотаций
- 28. vault-controller в Avito Все плюсы существующих решений, пони, батарейки + init container -> volume -> application + авторитет k8s + проверка по IP + push-стратегия + approle backend + role_id в аннотации + чтение токена с stdin или k8s -секрета + шифрование на RSA + выкладка файлов вместо токена
- 29. Риски Avito vault-controller ✓ собственные секреты - stdin или k8s secrets ✓ маскировка под легитимного клиента - надо знать role_id ✓ запрос легитимным клиентом не своего секрета - надо знать role_id ✓ передача секрета по сети - RSA ✓ запрос секрета внешним клиентом - k8s API ✓ маскировка под легитимного клиента - проверка аннотаций
- 30. Нюансы ● vault-controller не должен читать секреты, только выдавать SecretID ● стоит ограничить время жизни(ttl) и количество использований SecretID ● в разных кластерах могут быть одинаковые namespace (dev vs prod) ● в разных namespace могут быть одинаковые поды (monitoring, proxy, ...) ● некоторым подам нужны секреты из разных мест (backup + certificate) ● аннотации можно проверять через Authorization webhook или на CI
- 31. Итоги ↓ пора защищаться от внутренних утечек ↓ пора начинать управлять секретами ↓ Hashicorp Vault снижает риски управления секретами ↓ потребуется доверенный авторитет ↓ доверенный авторитет также подвержен угрозам ↓ секреты Kubernetes - не так безопасны, как хотелось бы ↓ аннотации Kubernetes - тонкое место, их надо проверять
- 32. Ссылки ● https://infowatch.com/report2016_half ● https://www.vaultproject.io/ ● https://github.com/jovandeginste/hiera-router ● https://github.com/jsok/hiera-vault ● https://github.com/kubernetes/kubernetes/issues/10439 ● https://github.com/kelseyhightower/vault-controller ● https://github.com/Boostport/kubernetes-vault
- 33. Questions?