Сергей Носков Управление секретами в кластере Kubernetes при помощи Hashicorp Vault.md

Здесь переводится видео в статью Сергея Носкова из Avito "Управление секретами в кластере Kubernetes при помощи Hashicorp Vault"

Ссылка на видеодоклад https://www.youtube.com/watch?v=IulNdGlQR3A

Текст сделан из субтитров. Буду очень благодарен в форматировании текста, его вычитки. Для этого достаточно знать русский язык. Присылайте свои pull request или присылайте текст на почту patsev.anton[собака]gmail.com

План доклада:

• проблема управления секретами как таковыми
• решение, которое мы выбрали для себя (Hashicorp Vault)
• внедрение Vault в систему управления конфигурацией Puppet
• использование Vault в Kubernetes

В целом больше я коснусь общих тем управления секретами. Что мы с вами считаем секретами? Практически любая конфиденциальная информация:

• логин пароль (например, для доступ к базе данных)

• закрытый ключ от сертификата сервера

• закрытый ключ от клиентского сертификата платежной системы

• ключ для подписи мобильных приложения для выкладки в AppStore, Google Play

Если эти примеры не очень убедили, то вот статистика от InfoWatch, которая показывает все нарушения конфиденциальности информации в первом квартале 2016 года. Как вы видите большая часть всех утечек происходили изнутри. В первую очередь нужно защищаться от людей, которые внутри могут нарушить конфиденциальность данных, чем снаружи. Почему так происходит? Потому что научились от внешних угроз более или менее защищаться. Для защиты используем периметры, VPN-серверы. Научились не пускать наружных нарушителей внутрь.

С внутренними угрозами, нарушителями у нас гораздо больше проблем на сегодняшний день. Внутренную инфраструкту не очень хорошо умеем защищать.

Храним секреты локально на серверах. Не думаем какие у секретов права доступа или кто у них владелец. Если разработчику выдали доступ логи посмотреть, то есть вероятность что он утащит wildcard сертификат.

Если вы храните не локально на сервере файлы, пароли, то скорее всего пароли для доступа к базе данных лежат в git. Доступ закрыт к git репозиторию. Но когда большая команда разработки это все равно что у вас доступ к репозиторию открыт. Потому что у вас там большинство разработчиков, которые разрабатывают основной кусок вашего приложения видят пароль к базе данных, потому что вы даете доступ к репозиторию. Это бизнес необходимость.

Некоторые хранят секреты в отдельных репозиториях. Репозиторий с секретами никому не показываем. его синхронизируем только локально на сервер. Есть недостатки такого подхода.

Можно хранить секреты в небольщих базах.

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

Можно использовать configuration management: Chef, Ansible, Puppet, CFEngine. C большой вероятностью вы выкладывайте секреты через configuration management. Скорее всего вы храните их в репозиториях с configuration management. Храните их не с конфигами приложения, а с конфигами диплоя. Какой риск? Все системные администраторы имеют доступ к секретам, если вы не закрыли репозиторий. Также доступ к секретам есть у тех кому разрешено делать pull request в репозиторий configuration management.

Проблемы:

• Все секреты обычно не шифрованные.
• Отсутствует уничтожение дисков то что требует от вас физическая безопасность.
• Не очень уверены в безопасности git репозитория.

Решение: использовать шифрование секретов в репозиториях. С большой вероятностью в репозиториях нет поддержки шифрования секретов.

Часто вы не знаете кто и когда получал доступ к секрету. Отсутствует лог аудита. Вы не знаете кто прочитал репозитории. Куда из этого репозитория уехал секрет. Аудит в git невозможен. Git подразумевает распределенную модель разработки. Секреты будут размазаны по всем машинам разработчиков. Пароль к базе данных утекает легко и просто, например при утере ноутбука разработчика. Кроме случаев, если разработчик и организация сделали шифрование диска.

Иногда бывают проблемы с управлением доступа к репозиторию для 500 разработчикам. Вы не можете внутри репозитории ограничить доступ для разработчиков. Поэтому приходится создавать отдельные репозитории, засекречивать configuration management.

Если вы переходите на микросервисы, то все эти проблемы можно сразу умножить на 10, а иногда и на 100. При использовании микросервисов для каждого сервиса используется небольшой отдельный репозиторий. Каждому сервису нужны секреты для доступа в базу данных. У многих сервисов будут скорее всего цифровые сертификаты. поэтому вместо одного большого репозитория появляется сотни небольших репозиториев с точно теми же самыми проблемами.

Вы скорее всего придете к тому что вы будете использозвать один и тот же пароль. Или разные пароли дающие один и тот же доступ к одной и той же базе, находящиеся в 10 разных местах. Из 10 разных мест эти пароли можно украсть.

Мы этой проблемой озаботились. Озаботились проблемой когда думали как управлять паролями самих пользователей. Пользователи куда-то ходят. Им нужно управление паролями. Поискали системы управления паролями. Нашли многие корпоративные системы. Корпоративные системы не подходили для микросервисов. Это такие системы Keepass, LastPass и прочие. Их к микросервисом очень сложно применить.

Мы остановились на системе от компания Hashicorp, который называется Vault.

• Vault open source. Лицензия у Vault Mozilla Public License 2.0.
• Она написана на Golang.
• Vault является REST-сервисом.
• Общение идет полностью в JSON.
• CLI-клиент использует тот же самый API.

Vault сама по себе микросервис. Что у нее есть хорошего:

Vault сама по себе stateless. Oна никакого состояния, кроме как в памяти, не держит, не пишет на диск.

Vault поддерживает в качестве бекендов огромное количество стандартных баз данных, K/V хранилища.

В модель любой базы данных заложено прозрачное шифрование на уровне самого сервиса независимо от бэкенда. Гарантируется что ваши данные будут зашифрованы прежде чем они по сети отправятся в хранилище.

Заложено приличное управление политиками доступа и заложен принцип минимальных привилегий. Если вы просто подключаете к Vault у вас доступа нету ни к чему. Точнее вы к Vault не подключитесь, потому что у вас нет аутентификации, у вас нет прав. Когда вам дали права, у вас есть минимальные привилегии.

В новых версиях они хотят расширять API вплоть до внедрения плагинов. Можно будет писать плагины, которые интегрироваться в Vault. Они сейчас уже выделили API для базы данных. Если вы сейчас используете экзотическую базу данных, которая они не поддерживается Vault, то вы можете написать свой драйвер для базы данных.

Основное управление производится при помощи утилиты командной строки. Выглядит это вот так. Взяли секрет, сказали положи мой секрет с нужными полями. Секрет записался. Секрет хранятся в JSON. JSON привычный удобный формат. Мы знаем как парсить JSON. JSON поддерживается везде где только можно. По сути это K/V хранилище с оговорками, в котором встроено шифрование и политики безопасности

Вот так выглядит политика безопасности. Она настраивается нетрудно. Секреты устроены в виде дерева. Вы каждому кусочку этого дерева секретов даете доступ политикой безопасности.

Аутентификация отделена от идентификации. Например, вы требуете от Vault аутентификации при помощи ldap, логина/пароля, аккаунта на github, radius. При аутентифицикации вы получаете токен - это обычная UUID последовательность. С помощью токена вы получаете секретом. Вы предоставляете token. К token привязана политика безопасности. С этой политикой можно получать секреты. Это дает возможность построить гибкую и расширяему систему.

Делегирование прав. Вы можете самостоятельно обладая правами на чтение дать кому-то другому кто этими правами не обладает доступ только на то что вы прочитали. Например, вы читаете секрет, оборачиваете его при помощи одноразово токина. Получается token на чтение конкретного секрета. Передаете этот короткоживущий токен. Он будет действовать только один раз. Это способ делегирования. Даже если у кого-то нету доступа в Vault.

Мы делегирование прав используем для автоматизации. Также это хороший способ не передавать секреты по почте.

еще одна штука вал то есть специальный authentication бэкенд на самом деле она немножко дублирует вот это вот в рейтинг но она очень полезна в каком смысле значит вы можете прийти для авторизации не с любым не с логином и паролем да потому что логин пароль предусматривает у вас то что логин у вас не секретный а пароль он вот вы уже в тайне его где-то у себя держите а че здесь подразумевается на самом деле два секрета да то есть вы можете сказать что вот мой секрет номер один и вот мой секрет номер два два кусочка если вы два секрета в разные места разделили то вы можете безопасность тоже разделить то есть у вас тот кто знает всего лишь один секрет он у вас не сможет аутентифицироваться ему нужен второй секрет нужна вот эта вторая последовательность и это на самом деле просто чуть более удобный способ делегирования то есть как вот этот способ но просто чуть более удобный потому что вы да вы приходите вот как бы секрет секрет айди роли это как раз предназначалась да они выше корпус и придумали это для того чтобы аутентифицировать как раз микро сервис то есть у вас есть micro сервиса который где-то там по сети неизвестно где и неизвестно как стартуют да и хачкар подразумевает что все микро сервиса знают свой вот этот ролл айди что они знают айдишник роли потому что нам от микро сервис он знает кто он такой да как а у него роль в сети секрет найди им обладаете вы или что характерно что полезно вы ему просто в нужный момент вы даете то есть у вас есть какое-то третье лицо которое может скользить вот сюда если у него есть право сказать дай мне для этой роли вот этот секрет и этот не секрет а вот этот вот айдишник и этот айдишник получите потом его передать вот сюда вот этому клиенту а этот клиент он уже знает два секрета роль он знает заранее секрет в ему придаст тикай дойди вы ему предоставили он аутентифицироваться и получает токи это вот очень удобно для того когда у вас кто-то в сети вот внезапно стартовал ему нужен секрет как ему получить секрет он знает один одну часть секрета приходит к вам за 2 вы ему даете эту вторую часть и он может работать он может аутентифицироваться в волки в сервисе в нашем и в нем получать уже все остальные секрет какие проблемы каким мы столкнулись с какими проблемами первая сама большая проблема я дней вот нас на следующем слайде поговорю проблем курица яйца а наш проблем замкнутого круга чуть позже не значит все-таки кришны и утилитки немного недостаточно но поскольку это нога все open source в принципе написать там утилит проблема не составляет и есть даже несколько альтернативных управляла к этой штуке эта штука или таких дополнений к world of скому стандартному кли в общем они все именно для управления годятся но так немножко с ограничением все-таки есть ощущение того что не хватает эта файловая система поскольку там под капотом у него все равно киеве хранилища она тоже неудобно у него нету например там fine то есть как солдатам или как-то гибко вот именно запросить там определенные секреты из списка нельзя только вот полный скан то есть я там операции rest of ski прям простые лист get put все то есть вы либо знаете имя либо берете лист рекурсивно идете по директориям это куча степи запросов не очень хорошо политики простые но иногда хочется больше в основном тоже вот этих из-за вот этих префиксов потому что нельзя например в середине префикса поставить звездочку и сказать там выдают разрешить доступ ко всем префиксом у которых там содержится я не знаю там роли равно что-нибудь или какой интиме роли вот этого просто вот на практике когда работали с этим этого не хватило gui на самом деле есть но она идет в платной версии потому что хорошо корпусом enterprise на версию продает но недавно я посмотрел на самом деле в пгу и достаточно много появилось на свет gui есть проблемы я или расскажу в конце если будет время или тогда уже после после доклада потому что я сейчас боюсь что времени не хватит значит чем проблема порочного круга естественного не хотите отдавать секрет просто по запросу но когда вас сети вот кто-то появился новый ему нужен ему нужны секрет это он для этого приходит на сервис хранилище секретов он приходит за секретами но вы не вы не можете просто сказать вот чтобы он пришел и сказал дайте меня вот этот секрет и вы ему даете правда ведь вы должны какую-то аутентификацию провести но вы когда аутентификацию решаете проводить вы выясняете ну хорошо пусть он будет ходить с логином паролем оао логин пароль значит пароль то у нас секретной то есть мы должны значит где-то хранить секрет для доступа к секретам вот тут получается замкнутый круг до вам чтобы получить секрет вам все равно нужен какой то еще один секрет и нету никакого смысла потому что вот этот секрет у вас остается не секрет и вы не можете хранить в хранилище секретов потому что для доступа к нему нужен будет снова секреты так далее вот в этом знал замкнутом круге значит ползаете ничего не получаете семена потому поэтому аутентификация вам не подходит вам не подходит естественно вариант чтобы он просто пришел и сказал я такой то дай мне секрет а потому что знание того что он просто кто-то такое недостаточно поэтому общий принцип по которому мы решаем это некий 3 доверенный какой-то авторитет который решает который может проверить каким-то другим способом не требуя от клиента секретов действительно ли этот клиент тот за кого себя выдает и вот тогда мы его будем пускать у самого доверенного авторитет вот у этого третьего лица которой что-то решает у него тоже есть риски да ему во первых естественно поскольку он тоже должен будет ходить куда-то видимо или волк или еще куда то ему надо как-то доверять да то есть на нем скорее скотт сертификат должен быть ему надо хранить свои секреты где-то он трети доверенное лицо ему негде провериться вы не можете сказать в другом месте пусть он еще к третьему лицу пойдет с такой замкнутый круг но еще не очень все равно другой замкнутый круг получается дальше когда он решает это что-то да если он сам отдает этот секрет кому-то то по сети это надо делать шифровать само собой потому что это секретные данные безопасность ну естественно на первом месте вам этот третий авторитет естественно должен гарантировать что вот ну как 1 сама основная проблема что вы не можете отдать вот просто кому-то кто пришел снаружи сказал дай мне секрет он тоже естественно должен каким-то но это основная задача проверка дальше смотрите кто-то может прийти поскольку он проверяет только проверку может случиться такое что кто-то придет и представиться кем то другим скажет придет совершенно легальный клиент но попросит секреты другого легального клиента и вот это вот эти последние две проблемы на самом деле да то есть абсолютно легальные придет человек то есть 3 авторитет подтвердит скажет да это действительно он это тот тот за кого он себя выдает и будет отдавать ему любой секрет это тоже неправильно мы должны этот риск обязательно учитывать чтобы он отдавал не просто не просто подтверждал вот что это действительно тот за кого он себя выдает чтобы он решал еще какие секреты вот именно ему можно отдавать а какие секреты нельзя мы у себя во вид и начали это внедрять с внедрение всего этого в configuration management system у нас как вы на предыдущем докладе может слышали использовать систему паппет до сих пор у папе то есть такая настройка называется и sierra пьера это иерархическая key value хранилище там у нее смысл такой что вы можете что вы у вас агент который работает конфигурации уже на конечном костя он собирает об этом костей некоторые факты эти факты присылает мастер серверу и на основе этих фактов которые агент собрал со собрал агент доверенный на основе собранных агентом фактов вы можете принимать какие-то решения по вот этому хасту ну и поскольку у вас есть факты факты вы установили да у вас там ну простейший вариант это host name если вы там как-то по ролям отделите да вы можете сказать вот этот хвост у меня является например сср терминаторам и поэтому ему можно отдать сертификат ему нужно дать сертификат вы принимаете решение значит ссылки на эти на эти две штуковины они в конце слайдов есть на все есть ссылки в конце слайдов это открытые решение мы использовали 22 бэкенда карьере она расширяем и это само хранилище фиерро у него есть бэкенд который маршрутизировать который просто решает которым можно сходить в другой бэкенд который может начал в одном месте поискать есть там не нашел пуха пойти в другое место искать мы его используем для каширования чтобы не перезагружать волком и у нее есть непосредственно волгу кем то есть та штука которая умеет волк сходить со своим собственным токи нам со своим собственным секретом и в волчьей благополучную секрет получить естественно чтобы все это из базы данных из киева илью хранилище выложить уже на хост на конечные да нам пришлось но простейшие соглашение принять формат файла в котором собственному просто указываем с какими правами его выкладывайте все это паппет агент он когда берет уже получает собственно сам секрет он вот это вот в виде файла потом выкладывает в результате в конце да здесь но элементарные вещи просто как бы обычный самый легкий джейсон то есть основной вот секрет он просто вот сюда вот запаян значит на самом деле формально ера и паппет мастер как доверенный авторитет они все свои риски решают то есть рисков нету но часть рисков решается за счет того что у папито и у фиеры у них генерируются свои сертификаты то есть паппет сам уже исторический и так он устроен до что у него паппет агент с паппет мастером уже общается при помощи пара сертификатов то есть у него упа питу самого уже есть открытый ключ и закрытый ключ и вот за счет этого за счет это который вы где-то разрешили то есть вы попить и это автоматически или вручную разрешаете говорите да вот этот ход действительно тот и выпиши ему сертификаты когда вы ему сертификат выписали он остается локально на хвосте то есть вы на самом деле здесь вот но не полностью устранены риски потому что немножко вот вы связаны на то что сертификаты самого паппет агента они все равно не хранятся в секрете и вот эти риски присутствуют но мы считаем что во первых там на них нормально распределяются право правильно то есть закрытый ключ этого сертификата не никому нельзя отдать его вторых они не ездят по сети то есть вы вот прям физически хост инициализировали по патоген то запустили сертификат вам там прямо сгенерировался закрытый ключ нигде никуда не поехал вот он там лежит и поэтому более менее этой схеме можно доверять просто в расчете на то что закрытый ключ по петровского сертификата никуда не поедет все остальное прикрыто вот как раз возможности миссьера и наличием вот этого сертификата на то что у вас легитимный клиент не должен запрашивать не свой секрет вы как раз за счет хиир и решаете потому что если у вас факт собранный ссср терминатор например с не действует тахира ему не отдаст не покажет не заберет и хост просто не сможет увидеть секреты которые ему нельзя увидеть почему кодак обернется значит после того как мы стали переходить на кубер нес сначала мы обратили внимание на то что в кубер ниц тоже есть секреты и первый вопрос который возникает почему не взять губернаторские секреты чем это плохо знаете чем это плохо во первых секреты хранятся в незашифрованном виде непосредственно в эти сиди самого кубер нету то есть если вы не озаботились безопасностью и кессиди губернаторского ваш секрет а лежат точно также как они лежали бы на файловой системе а то и хуже если у вас по сети к этому и кессиди кто-то может прийти и ваш секрет получить мы об этом позаботились на самом деле при развертывании кубер нация вам очень советую об этом заботиться там на самом деле достаточно просто тоже выпустить определенный набор сертификатов который мы теперь кстати доставляем собственно по пятам и золото тоже и за счет сертификатов за счет того что вы ты сиди доступ ограничен вас остается рис только того что там кто-то или диск физически вытащит ну понятно да то есть риск обычно того что данные незашифрованные вот где-то лежат на хранилище что их оттуда все таки ну когда то можно будет украсть что еще контролировать эти секреты но практически невозможно и это тоже в кубер найти достаточно сложно то есть вам нужно какие то там аудит логе собирать у вас нету политик на доступ к секретам у вас секрет который если namespace он доступен сразу всем из всего на им space и если вы тоже не написали там кучу этих рыбаков а баков и прочего но в общем [музыка] плоховато это сделано в cabernet с точки зрения управления про политики управления секретами я даже не говорю вам нужно поднимать отдельно томат мишин контроллер или что-то какой-то в эпоху которой у вас будет контролировать кому же на самом деле можно отдавать секрета кому же нельзя естественно это все только кубер не this only и как бы выйти из кубер нить из и хранить секрет а вот как мы там хранили да как про когда нам просто нужен сертификат где-то на стороннем engine.exe который не в кубер найти запущен это невозможно вроде бы как у них подвижки есть то есть у них еще есть но и шью стоит в баттлоге это конечно печально до подвижки в том смысле чтобы дать кубер нацию например еще один web хук и сказать вот те в обход ходи туда и забирай секреты в другом месте не выйти сидя где-то еще ну казалось бы достаточно не сложно да он все равно в киеве хранилище ходит там тем же путем забирает ну вот еще есть но мы пока не трогали и пока это все печально backlog есть boklok в кабинете есть еще одна сущность называется аннотации значит аннотации призваны там много полезной информации хранить об аде а контейнере всем остальном но в частности в аннотация хранятся такие вещи как сетевые политики конфигурации нет контейнеров это контейнера который перед запуском потом запускается и вот прям цитаты из документации кубер не тесто есть все что на самом деле нужно защищать и все что если вдруг в аннотация этого не окажется может вам очень сильно повредить и сделать плохо по последнему докладу из гугла там часа они собираются хранить дополнительную информацию о ситком профилях то есть именно прим вот непосредственно относящейся к безопасности под и контейнера информацию и здесь важно что если вы все-таки доверяйте своим сотрудникам выкладку вот как мы делаем да если вот вы говорите вот тебе фильм выкатываясь а фильмом прям дело тепло и там через seo не через а и то если вы все-таки это делаете через seo и обязательно проверяйте аннотации потому что плохой разработчик который хочет вам плохо сделать он может через ель выкатить плохую аннотацию много безопасности нарушить поэтому как-то разберитесь с тем чтобы аннотации ваши разработчики не могли на них повлиять значит кубер нити можно применить такую же схему с доверенным авторитетом как в случае с по пятам как это устроено есть некоторые штука world контроллер собственно ну практически как в попить у вас запускается под в позе запускается не сама основное приложение должно много приложение запускается специальный нет контейнер он уже в контексте этого года работает то сидит контейнер в том же позе всегда находится у вас есть третье лицо которое через что через cabernet сопи да у вас же есть губернатор пиф которым вы всегда можете запросить что это за под в каком она и спейси и так далее и у вас под который в одну вот в нем вот и нет контейнер чтобы от основного приложения отделить и нет контейнер запрашивает у вас здесь секрет говорит я под такой то в нем спейси таком-то дай мне секрет вы его проверяете вот здесь убеждаетесь что им это можно вы здесь же решаете какой ему секрет можно отдать и благополучно идете вот этот секрет ему отдаете трансфер секрет а вот до основного приложения у вас делается через простой mount то есть вы просто заводите отдельный mount я вам советую делать мемориал то есть пусть он там на темпы офисе да потому что секрет у вас тогда на диск нигде не сохранится даже в даже в слэш tmp например да не сохранится во время на какой-то директории на диске просто кладёт сюда секреты основное приложение потом их может прочитать просто подмонтировать вот этот вольем который вы там в конфигурации прописали и мы когда начали искать какое-то готовое решение на самом деле был наоборот мы нашли сначала готовое решение придумали вы поняли вот эту схему из вот этого готового решения а потом уже начали делать здесь может сложная схема показаться но она на самом деле то же самое что вот это челси хайтауэр есть такой известный cabernet специалистам там читает доклады работает в google и вот он предлагает ровно такое решение как я вот здесь вам показал то есть сходить волк получить там просто токен на авторизацию каким-то макаром и отдать его в контейнер какой токина какой секрет келси хайтауэр предлагает определять по аннотации то есть у вас в аннотации пода есть информация и о том какую политику привязать к токи ну то есть вы идете волк на болт контроллере убеждаетесь что под действительно тот и потом идете волк и именно для этого пода получаете токина говорите волку кто кинул мне вот к этому который я сейчас отдам туда привяжи политику ес аннотация это на самом деле ужасно потому что вы можете в аннотации привязать любую политику если вас заведено как они политика которая дает дофига прав на дофига префиксов то в эту политику благополучно отдадите с одной единственной поправкой если у вас хватит прав на это конечно но это вот это вот не годится совершенно естественно научился идет как прототип он там не полностью все продумал и алгоритм на самом деле чуть-чуть посложнее у вас и нет контейнер сначала запрашивает ваш контроллер и отключается потом волк контроллер проверяет вовку бернес api и нет контейнер в это время сидит и слушает порт и чтить и пышный и вот уже как только вы проверили его вы должны на этот порт самостоятельно приконнектиться и когда вы при коннекте ли сюжету да этот токен отдать и здесь естественно ни о каком шифрование не может быть речи потому что когда у поднялись типе сервер на и нет контейнере у вас секретов нет сертификата вы сделать можете только сама подписной что равнозначно отсутствую сертификата и практически шифрования отсутствует что здесь хорошо это вот основная схема да то что кто-то вообще на самом деле кто угодно со стороны может secret запросить а вы гарантированно проверив то есть у вас же на самом деле вот в этой схеме получается так что кто угодно со стороны может прийти и сказать дай секрет вот этому поводу вы его проверить и и именно этому поводу отдадите это делается по айпи адресу то есть вы их кубер на этапе можете выдернуть самое главное айпи адрес пода и вот здесь вот эта вот схема с обратным коннектом она именно до этого и заточена для того чтобы вы найти адрес пришли именно легального гарантированно того пода которого надо как я уже сказал во первых конечно дополнительный риск виде просто политики в аннотации это совершенно неприемлемо я вам очень не советую я ищу ему создал на гитхабе но ответ пока нет собственные секреты они предлагают держать через январе мин то есть на самом деле хранить где-то там же выходках в репозиториях во всем остальном но это как-то тоже совсем нехорошо про шифрование по сети я сказал в целом роль доверенного авторитета вот контроллер от келси хайтауэр выполняет второе решение которое мы нашли чуть позже чем начали делать свое это решение от but sports значит она на самом деле уже правильной и практически годится значит что здесь хорошего во первых они отказались от работы по запросу у них секрет никто не запрашивает они сделали так они сидят как uber на цепи сервере и в камерной цепи сервера есть такой функционал как watch они просто сидят и смотрят все события в аппетит и как только пришло вопи событие о том что под стартовал они проверяют аннотацию этого пода опять же пользуются аннотациями если у под в аннотации там записано правильная какая-то штука они делают вот оставшуюся часть работы значит оставшаяся часть работы заключается в чем в том что они идут волк волки они генерируют уже не просто talkin' то есть они не от инфицируются в волтер они генерируют там вот тот самый секрет айди а в аннотации они подразумевают что у вас будет прописан вот этот ролл ой то есть они говорят для роли айди прописанного в аннотации возьми мне получим не новый секрет айден и отправляют этот секрет айди уже в приложении поскольку роланде прописан в аннотации подразумевается что под сам который там уже есть он уже знает свою роль айди поэтому он получает секрет айди вместе с роли один секрет айди идет волк получает там той и уже при помощи токина может забирать все секреты какие ему надо что здесь хорошо во-первых хорошо здесь очень хорошо то что в секреты не проходят через контроллер через контроллер проходит запросы вот только на эти секрет айди короткоживущие он потенциально может конечно сам себе чего то там на генерировать и на получать эти секреты но только при условии что он видит роль то есть вот просто работающий только что запущенный волк контроллер не может в этом случае не зная роль аиде получить секреты и вообще у вас делегирование секретов отделена от самих сикретов вас через вот эту штуку секреты не едут основные секреты вот этого приложения не едет там сертификат звезда google.com едет секретарь и для доступа к сертификату звезда но не едет сам сертификат что еще здесь хорошего все остальное да все остальное здесь то же самое то есть они просто поменяли немножко схема аутентификации ада они добавили чтить и без вот здесь то есть у них и нет контейнер генерит сама подписной сертификаты слушает https порт но как я вам уже сказал это роли не играет на самом деле вот вот это вот все вот те минусы который я здесь описал до плюс и какие плюсы естественно все которые были у келси хайтауэр они все сохранились про отделение авторизации от секретов я сказал роль иди в аннотации это здорово я сказал почему значит когда вам нужно выучить событий в кубе r'nessa у вас возникает проблема с отказоустойчивостью потому что если вы хотите выучить событий из нескольких мест вам важно чтобы у вас все получившие событий они начали пушить там по 100 секретов да не начали генерировать эту кучу секрета идеи не пушить их все в одно место эти ребята они справились тем что они вводят ровд ровд это там протокол консенсуса то есть у них как у них вот если вы 10 но запустили 10 но будут голосовать выбирать какая из них главное только главное будет пушить это работает но честно говоря это overkill плюс вам нужно разбираться с доступов cabernet с тем как читать эти события все остальное и консенсус протокола они могут у вас разойтись немножко у них бывает вам придется следить просто затем чтобы но да не разошлись зачем-то а не получив секрета иди кстати еще заворачивают его дополнительно в talkin' то есть вам такое двойное там развертывание надо произвести развернуть секрет айди при помощи в rapida секрет а потом в репе поэтому секретарь где получить снова то есть опять же она работает на минус не страшны просто overkill очередной и чтить и без на самом деле тоже overkill потому что самый подписной сертификат до шифрование по сети сработает носом подписной сертификат здесь не нужен здесь достаточно сгенерить пару ключей на обычными россии на ключевой полировать и передать ничего больше не надо что они еще не делают как делся хайтауэр они не делают ничего стоки нам то есть ваше приложение которое токен получила секрет уже сам именно для доступа к world она должна обо всем позаботится сама и это от вас требует требует от разработчиков чтобы они пуш или приложения который умеет прочитать токен сходить в лт api и из волт api свои секреты забрать и выложить вот это нас тоже совершенно не устраивало потому что может быть тоже слышали у нас много языков и мы каждого разработчика не можем и не хотели бы заставлять то что у нас очень сильно затянулось бы внедрение все остальное но в целом большинство рисков решения от будут спорт устраняет хорошо и вот если не брать вот этот маленький недостаток того что его собственный секрет то есть токен при помощи которого она генерирует эти секрет айди хранится у него просто в конфиг небе который вам тоже нужно на опять там замкнутый круг где-то хранить в репозитории никому не показывать вот это вот все остальное за исключением вот того что они оверкиль от и используют вот немножко не секретный сам токен само решение уже вполне я вам рекомендую то есть она с точки зрения безопасности его можно применять наше решение начинаешь и решение просто устраняет недостатки вот этого решения будут спорт во-первых мы оставили до разработана но нога разработчика основной практически там 90 с лишним процентов я значит что мы оставили оставили схему келси хайтауэр с запросом секрета но запрос секрета я уложила в один запрос то есть я когда поскольку я знаю уже что в нашей сети скорее всего под запрашивать секрет ни для кого то там а всегда сам для себя я остаюсь наставляю открытом это соединение поскольку она телесно меня на волк контроллере хороший годный проверенный сертификат не сама подписано ну подписку сама подписной но на нашем внутреннем всей доверенный нам сир нами сертификат и и нет контейнер когда приходит и держит соединение я всегда смотрю если он пришел с того api адреса я ему в рамках зашифрованного соединения сразу отдаю секрет я просто устраняем вот этот overkills подключиться отключится поднять сервер ждать пока придет кто-то другой отдаст мне секрет а вдруг он не отдаст я буду висеть ее под не стартует под упадет в общем все будет плохо во вторых на случай если вдруг кто-то запрашивает не за себя я выбрал здесь эти без добавил открытый ключ у меня здесь запрос приходит непростая под такой the namespace такой-то а я под такой-то и такой-то вот мой открытый ключ если вдруг точнее вот открытый ключ если вдруг надо запушить кому-то то вы там сами разбирайтесь там кому открыт где закрытой крышке нери руется просто на открытом ключе шифруется секреты пересылается посети я таким образом покрывая полностью шифрования сетевой дальше у меня своя реализация вот этой штуки которые вы нет контейнер и работает она делает на самом деле то что описано вот здесь вот дополнительно плюсами вот этими вот этим последним на самом деле плюс она кроме того что она просто аутентифицироваться world и получает токина не только умеет отдать токен приложения она умеет соответствует с тем джейсоном просто взять уже все файлы какие вы скажете с нужного префикса и файла выложить так что у вас приложение уже не заботится о том чтобы ходить в лес ты читать джейсон я сам хожу в лес сам читает же сон и разработчикам говорю вы подключаете мой нет контейнер то есть с именно с позиций разработчиков это самый простой вариант они просто кпп степной нет контейнер к себе в deployment фильм куда угодно и мой нет контейнер делает все что надо он сам разбираются с аутентификации со всем остальным я только задаю нужны политики world я прописываю волки политики и нет контейнер делает все разработчики только знают директорию в котором же будут лежать секреты прямо готовы прямо как им надо то есть если это сертификат то он уже будет сразу все вот как сертификат формате темп роста тем будет файл лежать и все не нужно никакого volta никакого риска никакого джисона ничего не нужно с проблему собственных секретов я добавил вот в таком виде я просто сделал два варианта либо чтения со стыда in через опцию либо чтения с секретов cabernet если вы хотите автоматизации чтобы у вас вот контроллер перезапускал это в кубе r'nessa реплицироваться и так далее то вы немножко идете на небольшой риск вы его собственный talkin' зашиваете в кубер на тех лет вы принимаете этот риск вы готовы на него пойти если вы не принимаете этот риск не готова пойти просто заходите там их зекам эллиотта чем в контейнер и передавайте токен pstn это безопаснее естественно но автоматизации немножко пропадает собственно риски большинство рисков которые я закладывал туда я устраняю немножко проблемным остается риск с проверкой аннотаций потому что мы точно не знаем ничего про под то есть если у вас разработчик выкатывает под в том же кластер и в том же namespace а то вот внутри одного namespace обхода между собой различать очень сложно потому что различать их по имени ну просто плохой разработчик который хочет получить чужой секрет он по имени он ими поменяет если он там различать его по меткам по метаданным то то же самое он поменяет метаданные так что чужой секрет все равно заберется и вот в кубер нити просто на самом деле очень сложно различить вот это вот эта проблема того что вот она в кластере выкатывается там в разных местах в разных точках во всем остальном сейчас я прихожу к тому что скорее всего просто будем проверять аннотации и при проверке аннотации перед высадкой каким-то образом определять кто и как выкатывает этот пот и не разрешать им менять аннотации говорить вот ты прописываешь аннотацию такую она у тебя точно такая никакая больше возможно в аннотацию просто будем классика это секретная техника который вот половина полу секрет вот этот ролл айди который не даст которым мы форсируем чтобы разработчик его не у него не не менялся или не утихал может быть будем что-то генерировать ну в общем как бы вот проблема доступа к одним и тем же секретом от разных кодов в пределах namespace а где мы не можем вот так различить под и она еще немножко есть обращайте на это внимание что здесь еще можно сказать первый пункт я вам уже сказал да в если вы будете у себя это внедрять политиками устройте так чтобы world контроллеру нельзя было читать сами секреты только выдавать доступ на них естественно секретная техника его нужно сделать короткое живущим там ему 10 20 30 секунд хватит чтобы он дошел до пота и потом все использовал его как надо и естественно хватит одного единственного использования там еще волки сейчас новый функциональность можно секрета иди привет привязать к и печников вы можете айпишник потом я кстати использовать печник под еще привязать скачивать с этим секрет айди можно только с этого айпи прийти извиняюсь сиропу надо осталось 10 минут до я вот прям уже все на самом деле тогда посмотрите потом замечание вот эти просто когда будете дали себя что-то делать учитывайте вот это в своих системах при своих интеграция здесь кроме авторизация хук еще от мишин контроллер подойдет подводя итоги могу сказать что перестаньте уже кому кому-либо доверять постарайтесь не доверять никому попробуйте хэш карп world учтите эту схему с доверенными авторитетами не забудьте что его тоже надо защищать ну и не забывайте вот те вещи которые сказал про секреты и про аннотации ссылки как обещал всем спасибо вопросам спасибо я сразу скажу что давайте вопросы сразу к сергею в culoare ным образом нам надо как раз время осталось чуть-чуть чтобы изменить презентацию спасибо еще раз