РИТ++ 2017 Зал Сан-Паулу, 5 июня, 16:00 Тезисы: http://ritfest.ru/2017/abstracts/2654.html Даже небольшие сервисы рано или поздно сталкиваются с проблемой безопасного хранения и управления секретной информацией: паролями, сертификатами, ключами API. В докладе будет сделан краткий обзор Hashicorp Vault, рассмотрены случаи автоматического и безопасного управления секретами с помощью puppet+hiera. Особое внимание будет уделено встроенным секретам Kubernetes: я обозначу проблемы управления ими и недостатки существующих решений для связки с Vault, а также расскажу, как мы преодолели все эти трудности с помощью простого самописного решения. Доклад будет полезен тем, кто уже столкнулся с проблемой большого количества секретов, а также всем, кто уже использует Kubernetes, или ещё только думает о его внедрении.

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

8. Hashicorp 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»
Важно: проверять аннотации перед выкаткой подов

20. Kubernetes
Доверенный авторитет: Kubernetes API

21. Существующие решения: Kelsey Hightower’s

22. Kelsey Hightower’s
+ init container -> volume -> application
+ стратегия: push по запросу
+ авторитет k8s
- политика Vault в аннотации
- нет шифрования по сети

23. Риски Kelsey Hightower’s
! дополнительный риск: можно указать (почти) любую политику Vault
✕ собственные секреты - через environment
✕ передача секрета по сети - не шифруется
✓ запрос секрета внешним клиентом - k8s API
✓ запрос легитимным клиентом не своего секрета - проверка аннотаций
✓ маскировка под легитимного клиента - проверка аннотаций

24. Существующие решения: Bootsport’s

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
✓ маскировка под легитимного клиента - проверка аннотаций

27. vault-controller в Avito

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?