Управление секретами в Avito при помощи Hashicorp Vault

Митап на тему "Безопасность", 22-08-2018
Сергей Носков, Авито

Сергей рассказал, как они управляют секретами с помощью Hashicorp Vault и используют c Puppet/Ansible и Kubernetes. Также он поделился тем, какие шишки они набили за полтора года использования, и мыслями, как это можно исправить.

Transcript

1. Управление секретами в Avito при помощи Hashicorp Vault Сергей Носков, Platform Security @ Avito
2. План 1. Введение (напомню общие вопросы - что такое, какие преимущества и т.п.) 2. Краткая сводка нововведений за последний год 3. Варианты использования c Puppet и другими SCM 4. Что сейчас в Kubernetes в Avito 5. Основные боли для безопасников 6. Основные боли для разработчиков 7. Идеи как сделать лучше 2
3. Секрет Практически любая конфиденциальная информация • логин + пароль (например, к БД) • API-ключ • ключ сертификата сервера (*.google.com) • ключ клиентского сертификата (партнёры, Yandex money, QIWI, ...) • ключ для подписи мобильных приложений 3
4. Проблема курицы и яйца • чтобы получить секрет вам нужен другой секрет (аутентификация) • секрет для получения секрета - тоже секрет. • важность секрета для хранения секрета >= важности самого секрета? Решение: Авторизация • доверенная третья сторона решает, кому что можно и нельзя • ей не нужен доступ к секрету, но она всегда может его получить 4
5. Hashicorp Vault • безопасное хранение и управление ключами • аутентификация и авторизация доступа к секретам (acl, принцип минимальных привилегий) • REST, JSON • плагины для logical и auth бекендов (+ фреймворк!) • CORS-заголовки (для GUI без посредников) • открыт встроенный GUI • нативная интеграция с Kubernetes 5
6. Hashicorp Vault в Avito • единый Vault на всю сеть ◦ persistence на базе сonsul - для отказоустойчивости из коробки ◦ unseal - 3/7, безопасники и админы • тестовый vault(sandbox) для разработчиков ◦ также доступен как контейнер ◦ unseal+bootstrap при помощи “скрипта” на go 6
7. Какие секреты сейчас храним • секреты для микросервисов Kubernetes • секреты для выкладки на “железные” серверы и LXC • секреты для билдов в CI/CD (Teamcity) • ключи всех сертификатов - внутренний PKI, внешние CA(GeoTrust и т.п.) • общие секреты для команд 7
8. Секрет-файл { “encoding”: “base64”, “data”: “TE9MIEtFSyBDSEVCVVJFSwo=”, “filename”: ”some.secret”, “mode”: ”400”, “owner”: “root”, “group”: ”root”, } 8
9. Puppet + Hiera + Vault Авторизация - puppet master 9
10. Puppet + Hiera: Workflow 1. Положить секрет в Vault (иерархия - как в hiera: /puppet/role/www/site.ssl.key) 2. Прописать префикс в манифест 3. Прописать в yaml для Hiera router 4. PR в репозиторий манифестов 5. Прогнать или дождаться прогона puppet agent (30 мин) Всё руками + секретов на самом деле немного + мощь hiera по подстановке фактов (warning: факты собираются client-side, большинству нельзя доверять) 10
11. Как быть с SCM без мастера? Предложение: агент • при bootstrap-е сервера генерируется токен/approle и политика • агент по крону забирает секреты по доступному пути - каждый новый сервер требует действий в Vault - надо как-то ротировать/обновлять токен - группировка серверов(по роли, назначению, фактам) - затруднена: её надо синхронизировать с Vault 11
12. Большой Недостаток №1 • write на любую политику автоматически означает полные права • политиками нельзя ограничить изменение содержимого секрета или другой политики 12
13. Kubernetes • в Vault 0.9+ нативная поддержка Kubernetes • граница безопасности в kubernetes - namespace • в каждом неймспейсе своя роль • пользователь получает vault токен используя serviceaccount token (почти JWT) • свой доверенный авторитет (vault-controller) не нужен - авторизует сам kubernetes ◦ больше нет проблем с аннотациями ◦ всё равно доверяем разработчикам, когда они сообщают имя неймспейса и сервиса 13
14. Kubernetes: правила • один сервис - один namespace • в каждом кластере свои секреты • в каждом неймспейсе свои секреты • у каждого сервиса свои секреты 14
15. Kubernetes: доставка /k8s/<cluster>/<namespace>/<service>/some_secret Vault init-container shared volume container 15
16. Kubernetes: workflow Разработчик: • разработчик узнаёт от security champion про Vault • подаёт заявку в security на заведение префикса • ждёт • добавляет volume и init-container в depoyment.yaml (helm chart) • commit -> deploy -> fix -> repeat 16
17. Kubernetes: workflow Безопасник: • получает заявку • выясняет недостающие вопросы • создаёт политики и роли в Vault • прописывает нужные политики нужным группам • ищет, где ошибся разработчик • иногда кладёт секреты за разработчика, чтобы у того не заболело ещё больше 17
18. Kubernetes: проблемы • очень сложный workflow для разработчика (многие не знают даже имя кластера) • блокировка на безопаснике: больше никто не может заводить политики из-за БН №1 • много равнозначных копий одного секрета ◦ сложно менять/ротировать ◦ нигде не учитываются 18
19. Идея: Kubernetes KMS KMS (Key Management Service) - новая alpha-возможность Kubernetes по шифрованию секретов 19
20. KMS: плюсы и минусы - децентрализация хранения - вынос из Vault в Kubernetes (etcd) - kubernetes-only решение - сложно делить секреты между кластерами + нативная поддержка в kubernetes, включая защиту env + авторизация в Kubernetes + практически не надо поддерживать Vault + ротация ключей из коробки 20
21. СI/CD: Teamcity • некоторые секреты нужны при деплое (миграции БД, оповещения в Slack, ...) • плагин от JetBrains • AppRole на каждый проект (настройки - write-only) • секрет(или его часть) попадает в параметры билда и автоматически “прячется в логах” 21
22. СI/CD: Не Teamcity? • продумать изоляцию: ограничить область видимости секрета проектом/командой/... • продумать, кто авторизует доступ к секрету • исключить возможность просматривать секрет авторизующей стороны • отдельным этапом билда импортировать секрет в файлы • почистить за собой 22
23. Сертификаты • удобно проверять сроки истечения • через Vault PKI backend удобно создавать CA и (пере)выпускать на нём Intermediate Level 3 сертификаты для небольших групп • сертификаты для ноды k8s - 2 минуты работы скрипта /certs/<тип>/<cn> хост /puppet/role/www/site.ssl.key k8s-pod /k8s/some-cluster/some-ns/some-service/site.ssl.key вручную 23
24. Резюме • слишком много делается руками безопасника • слишком большой порог вхождения для разработчика (~4 длинных статей в wiki) • хочется делегировать, но встроенных средств нет 24
25. Идея для доставки: master-slave секреты • это не симлинки! • у секрета есть source of truth - мастер секрет • менять можно только его • при доставке секрета прописываются параметры доставки ◦ куда доставлять (k8s, сервер, CI-CD, …) ◦ как доставлять (файл, JSON, …) • автоматика синхронизирует slave c мастером • все slave недоступны на изменение руками 25
26. Идея для авторизации: Ownership-based подход • у каждого секрета есть владелец (тот кто его создал или его группа) • владелец может делать с ним что хочет ◦ выкладывать в k8s (генерируется политика, создаётся slave-копия) ◦ выкладывать на сервер (генерируется политика, создаётся slave-копия) ◦ выкладывать в CI/CD (нутыпонел...) ◦ передавать другому владельцу ◦ показывать кому-то ещё ◦ генерировать новые ACL для доступа к секрету 26
27. Идея для делегирования: шаблон ACL 27 • администратору Vault управляет шаблонами ACL • при записи в шаблон можно менять только параметры ACL • у каждого шаблона есть имя => есть префикс в Vault • имея префикс, можно давать на него доступ другими ACL • адресаты ACL, созданных по шаблону, тоже параметризованы
28. Идея для делегирования: шаблон ACL path “policy-mgr/create/k8s-microservice“ { capabilities = [“read”, “update”, “delete”] } ACL на создание ACL: даёт права создавать новые ACL по шаблону (назначается делегату) 28 path “/k8s/{{ .Cluster }}/{{ .Namespace }}/{{ .Service }}” { capabilities = [“read”, “update”, ...] } шаблон ACL
29. Идея: генератор policy по шаблону 29 создаётся политика k8s/some-srv path “/k8s/prod/some-ns/some-srv” { capabilities = [“read”, “update”, ...] } $ vault write policy-mgr/create/k8s-microservice \ cluster=prod \ namespace=some-ns \ service=some-srv
30. Идея: генератор policy по шаблону $ vault write policy-mgr/assign/k8s/some-srv-rw group=some-group когда политика создана, разрешает создателю привязать её к чему угодно или как-то ограничить его Этот шаг уже необязательный! Права на запись в /k8s/prod/some-namespace/some-service автоматически выдаются владельцу, т.к. он сгенерировал политику 30
31. That’s all folks! 31
32. Полезные ссылки 32 • https://www.vaultproject.io/ • https://github.com/jovandeginste/hiera-router • https://github.com/jsok/hiera-vault • https://www.owasp.org/index.php/Security_Champions • https://blog.jetbrains.com/teamcity/2017/09/vault/ • https://github.com/oracle/kubernetes-vault-kms-plugin/