Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Управление секретами в кластере Kubernetes при помощи Hashicorp Vault / Сергей Носков (Avito)

845 views

Published on

РИТ++ 2017
Зал Сан-Паулу, 5 июня, 16:00

Тезисы:
http://ritfest.ru/2017/abstracts/2654.html

Даже небольшие сервисы рано или поздно сталкиваются с проблемой безопасного хранения и управления секретной информацией: паролями, сертификатами, ключами API.

В докладе будет сделан краткий обзор Hashicorp Vault, рассмотрены случаи автоматического и безопасного управления секретами с помощью puppet+hiera. Особое внимание будет уделено встроенным секретам Kubernetes: я обозначу проблемы управления ими и недостатки существующих решений для связки с Vault, а также расскажу, как мы преодолели все эти трудности с помощью простого самописного решения.

Доклад будет полезен тем, кто уже столкнулся с проблемой большого количества секретов, а также всем, кто уже использует Kubernetes, или ещё только думает о его внедрении.

Published in: Engineering
  • Be the first to comment

Управление секретами в кластере Kubernetes при помощи Hashicorp Vault / Сергей Носков (Avito)

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

×