**001. Быстрая межсервисная аутентификация – Евгений Сидоров, Игорь Клеванец — Transcript & Summary | SozAI** Source: https://sozai.app/transcript/fast-interservice-authentication-sidorov-klevanets/ Обзор проблем и решений быстрой межсервисной аутентификации в микросервисной архитектуре от инженеров Яндекса. ## Key Takeaways - Традиционные межсервисные firewall не обеспечивают достаточной гибкости и безопасности в современных микросервисах. - Клиентские сертификаты имеют множество ограничений и сложностей в масштабировании и делегировании. - Переход на аутентификацию на уровне приложения (L7) позволяет лучше контролировать доступ и идентифицировать сервисы. - Macaroon токены и подходы, подобные LTS, обеспечивают более эффективную и гибкую аутентификацию. - Необходима интеграция современных методов аутентификации с облачными и контейнерными средами. ## What the video covers - Введение в проблемы межсервисной аутентификации и ограничения традиционных firewall в микросервисной архитектуре. - Обсуждение уязвимостей внешних firewall, таких как SSRF и обходы через DNS rebinding и неправильные прокси. - Недостатки использования клиентских сертификатов для аутентификации, включая зависимость от PKI и сложности с делегированием. - Рассмотрение подхода LTS от Google как улучшенной модели на основе TLS. - Описание механизма macaroon токенов для экономии обращений к серверу аутентификации и повышения гибкости. - Примеры реализации системы с возможностью оффлайн проверки и гибкой настройки под разные сценарии. - Преимущества перехода с L3-L4 firewall на уровень приложения (L7) для более точного контроля доступа. - Обсуждение проблем с масштабированием и поддержкой сертификатов в больших распределённых инфраструктурах. - Важность интеграции аутентификации с современными облачными и контейнерными технологиями. - Заключение о необходимости развития межсервисной аутентификации для повышения безопасности и удобства эксплуатации. ## Chapters 1. 00:00 Введение и постановка задачи 2. 02:34 Проблемы межсервисных и внешних firewall 3. 05:00 Ограничения клиентских сертификатов 4. 07:17 Подход LTS от Google 5. 12:17 Macaroon токены и их преимущества 6. 15:14 Реализация гибкой системы аутентификации 7. 24:01 Обсуждение и ответы на вопросы 8. 32:16 Заключение и перспективы развития Answers ## Questions about this video Почему традиционные межсервисные firewall не подходят для современных микросервисов? Они работают на низком сетевом уровне, не обеспечивают гибкости сегментации, плохо масштабируются в облаках и контейнерах, а также не дают информации о том, какой сервис обращается. Какие основные проблемы использования клиентских сертификатов для межсервисной аутентификации? Зависимость от PKI, низкая скорость работы, сложности с делегированием и масштабированием, а также проблемы с проверкой hostname и обходом балансировщиков. Что такое macaroon токены и как они помогают в аутентификации? Macaroon токены позволяют экономить обращения к серверу аутентификации, обеспечивают оффлайн проверку и гибко настраиваются под разные права и сценарии использования. ## Full Transcript — Download SRT & Markdown 00:08 Speaker A Спасибо большое. Да, как Антон уже сказал, вы знаете, меня зовут Женя, я работаю security инженером в компании Яндекс, и сегодня вам расскажу немного про быструю мир сервисной аутентификацию. Когда я думал над содержанием, я внезапно вспомнил книжку "1984". 00:27 Speaker A Там главный герой он частенько сдавался, он частенько говорил фразу: "Я понимаю, как, я не понимаю зачем". Сегодня мы ответим вам на два вопроса: как и зачем. Я отвечу на вопрос "зачем", а мой коллега Игорь, который появится здесь буквально через 00:41 Speaker A 15 минут, ответит на вопрос "как". Итак, небольшое введение. То есть у вас есть какой-то замечательный сервис, у вас есть пользователи, у вас есть внешний firewall на периметре, все построено по микросервисной архитектуре, есть frontend, есть какой-то набор 00:57 Speaker A брендов, и все вроде бы модно, молодежно, все хорошо. Дальше вы добавляете еще один сервис, они начинают между собой шарить какие-то микросервисы, это упрощает разработку, это ускоряет запуск этого сервиса и так далее, и вроде бы тоже все хорошо, но в какой-то момент 01:14 Speaker A вы задумываетесь над тем, что вам надо разграничить доступ между этими сервисами. Это может быть какое-то естественное разграничение, например, есть development среда, есть production среда, и кажется, что development среда не должна иметь доступ в production среду. И здесь вы задумываетесь о такой штуке, как 01:30 Speaker A межсервисные firewall. Межсервисные firewall и межпроектные firewall, мы их называем в Яндексе, это некие такие железные машинки, которые перекладывают пакетики из одного она в другой, делят все эти на сегменты, разграничивают доступ и так далее. Кажется, это такая довольно 01:47 Speaker A естественная вещь, многие из вас наверняка с ней знакомы, но у них есть некоторые проблемы, ряд проблем. Они не везде могут быть применимы, они не дают большой гибкости при делении сети на сегменты, они не подходят для облаков и 02:04 Speaker A контейнеризации. То есть ваши инстанции могут мигрировать из одного дата-центра в другой, из одной части сети в другую, это может происходить динамически. Эти firewall мальчики, авто скрининге и так далее, они в целом не дают никакой 02:19 Speaker A информации о том, кто пришел в ваш сервис, например. Хорошо, вы смотрите access log, вы получаете IP-адрес какой-то и порт, и вы не можете в реальном времени как-то развязать эту информацию, что это был за сервис, как-то 02:34 Speaker A применить какие-нибудь, я не знаю, квоты, то есть как бы ограничивать RPS этому сервису. То есть здесь они работают на довольно низком уровне и не совсем отвечают современным требованиям. Также хочу сказать пару слов про внешний firewall. То есть как бы он служит таким одним из 02:53 Speaker A security барьеров, но есть типы багов, такие как SSRF, которые позволяют обойти этот firewall. Например, у вас есть сервис внутри вашей сети, и он по какой-то причине должен ходить куда-то наружу. То есть это может быть, давайте вот возьмем в качестве примера Яндекс 03:11 Speaker A Вебмастер, туда саммитит шуру в специальную формочку, и он ходит вовне, проверяет вообще доступен этот сервис или нет, так далее. И казалось бы, все окно, злоумышленник может туда в эту формочку поместить URL, который находится внутри вашей сети, и сервис А сходит в сервис Б, который 03:29 Speaker A находится внутри вашей сети, таким образом обойдет большой firewall. И не обязательно это должна быть какая-то формочка вовне, это может быть, например, вы не знаю, проверяете домен, и атакующий ставит туда и velcom, ваш робот пойдет на его com, 03:44 Speaker A и вилка он отдаст redirect во внутреннюю сеть, там 301, 300 redirect. Это может быть DNS rebinding, то есть вырезал этот домен, смотрится, что IP-адрес не внутри сети, но когда выполняете запрос, IP-адрес опять веселый, домен, IP-адрес 03:57 Speaker A оказывается внутри вашей сети и так далее. Могут быть баги в коми, в конфигурации engine с неправильно настроенным прокси, x-акции redirect, неправильно используемый, может быть FTP, которым тоже есть срыв и так далее. И так же, кроме этого, 04:12 Speaker A напомню, у вас микросервисы, у вас есть frontend, у вас есть backend, пользователь отправляет запрос на frontend, frontend что-то с ним делает и формирует запрос backend. Довольно частая ситуация, но в этом случае могут быть всякие целевые 04:26 Speaker A инъекции, могут быть параметры повешены, параметры камин и контаминация, и иногда разработчики вообще в принципе не сильно выливают воды, можно прямо протащить целиком запрос и сформировать вот какой-то кастомный запрос к backend в обход frontend. То есть здесь у вас 04:45 Speaker A подвожу к некоторым выводам. То есть мы видим, что в целом межпроектные firewall и они не сильно справляются со своей задачей, но они сильно усложняют нашу архитектуру, они удорожают, то есть у них есть дорогая поддержка, их надо рестартить, следить за ними, чтобы они не отвалились, чтобы дырки не заросли и так далее. И как бы есть типы багов, которые позволяют обойти внешний firewall, и при этом мы не получаем никаких нормальных акулов, мы не получаем 05:00 Speaker A никаких нормальных вот, то есть в сервисе нет информации о том, что за сервис к нему пришел. В целом я не хочу сказать, что firewall это совсем дно, но мы считаем у нас внутри security мамы, считаем, что этот подход, но скажем так, 05:14 Speaker A немножко устарел, он не отвечает современным требованиям, и нам надо как-то двигаться дальше. Как двигаться дальше? Надо делать какую-то мир сервисную унификацию, то есть переносить все с уровня L3-L4 firewall на уровень 7, на уровень приложения. Какие здесь есть подходы? Самый, наверное, 05:28 Speaker A распространенный, не то чтобы распространенный, но вот мы выделили несколько, о которых хотели сегодня рассказать, это клиентские сертификаты, LCS и токены. Клиентские сертификаты, наверное, самый такой естественный способ, то есть как бы наверняка в организации есть внутренний PKI, 05:48 Speaker A развернут, и почему бы их не использовать. Но опять же здесь мы натыкаемся на то, что получаем зависимость от PKI, от всего того legacy, от всех этих алгоритмов, всех тех ASN1 парсеров и так далее. У нас есть низкая скорость работы, 06:05 Speaker A то есть может быть кого-то она устроит, но я уверен, что мы можем и быстрее. Вот потом все очень плохо, если у вас с одной стороны не браузер, и с другой стороны не индекс, то есть если вы 06:20 Speaker A пишете какой-нибудь скрипт на питоне, наверняка он не проверяет отозван сертификат сервера, он не выкачивается, не ходит в CSP, в общем, то иногда там бывают всякие баги, которые связаны с проверкой hostname и так далее. Опять же, если вы используете 06:30 Speaker A engine x в качестве L7 балансировщика и терминируете TLS на нем, то за ним наверняка стоит там, я не знаю, сколько-то реалов, и иногда просто можно отправить запрос напрямую в реал минус этот балансер. То есть да, такое бывает, и вся 06:49 Speaker A относится к атакам здесь обходится. Также сертификаты они немножко неудобны тем, что сложнее делать аутентификацию на их основе, то есть как бы у нас есть четкая спецификация X.509, и потом нам придется там парсить сертификаты или как-то на лету генерируя 07:01 Speaker A сертификаты, чтобы добавлять какую-то метаинформацию, которая может меняться, а запросы к запросу. Также они неудобны в том случае, если вам надо делегировать, если вы хотите вашу аутентификацию использовать, в том числе для делегирования, то есть у нас есть три 07:17 Speaker A сервиса, и вот какому-нибудь стороннему сервису надо от вашего имени сходить в какой-то другой сервис, то есть стандартная как OAuth, светляк dual flow. Вот так же есть проблемы с проверкой осознанности SP даже если она хорошо сделана, то есть это блокирующий 07:32 Speaker A запросам, надо подгружать их постоянно, ротировать и так далее. Можно попробовать сделать протухание сертификатов по времени, делать короткоживущие сертификаты, но представьте, что у вас там большой инфраструктуре, много дата-центров, сотни тысяч микросервисов, и вам надо для этого условно каждый день генерить по 07:50 Speaker A сертификату. В ЦАО скорее всего не справится. Мы видели примеры некоторых коммерческих CA, которые действительно не справлялись с этой нагрузкой, но они не были рассчитаны на это. Также есть подход, который называется LTS, он был придуман в компании Google. Я 08:09 Speaker A с радостью прочитал их white paper, как только он вышел, то есть они просто взяли за основу TLS и сделали более легкую версию. Вообще в целом LCS расшифровывается как applications or transport se... 08:25 Speaker A с радостью прочитал их white paper как когда он как как только он вышел то есть они просто взяли за основу tls и сделали более легкую версию вообще целом и lcs расшифровывается как как applications or trans port security они 08:41 Speaker A сделали взаимную аутентификацию на уровне в пище между микро сервисами они сделали единый подход к сервисам и к пользователям у них есть некоторые автоматически менеджмент ключей и это это действительно прикольная штука но она прикольная тогда когда вы контролируете рпц когда вы условно там я не знаю 08:58 Speaker A десятком хамитов можете сказать эту схему по всей компании и нигде не сломается и у ребят вот эта штука реализация этой штуки судя по их white paper заняло около десяти лет то есть как бы начинать чтобы получить что-то хорошее через 10 09:13 Speaker A лет но кажется не совсем правильно да отозван из они проверяют при помощи cl и у них есть система которая пушит сериал на для для каждого инстанса сами стрелы занимают довольно много места они сами ребята из гугла пишет что это все не до 09:29 Speaker A конца реализовано у них ну покрайней мере судя по вайпера то есть не во всех местах использоваться реле и как я уже сказала этого есть недостатки это сложно в реализации если вы контролируете от пищи может быть вы быстренько все 09:42 Speaker A сделаете но если у вас используется как бы свободы внутри каждый волен выбирать свой рпц и как ему строить api и так далее это скорее будет довольно долго и скорее всего будет сложновато и вы не сможете за использовать конкретной их схему вам 09:58 Speaker A придется переделывать и адаптировать по-своему под свои нужды все есть подход с токенами и в принципе мы на нем остановились то есть при каждом запросе передавать security talking который будет содержать некоторые density и да собственно вот была наша идея и идеи кстати иного она 10:16 Speaker A реализована в так называем этой идее есть в россии в посвященному алсу это так называемый туалет душ кран тайм лайн криденс и здесь есть ссылка можно в принципе почитать и посмотреть как это работает вот но он не отвечает на вопрос какой 10:33 Speaker A токен использовать он не говорит ничего о формате токена который вам нужен здесь есть тоже несколько подходов есть так называемый живите джейсон web talking это один из вариантов формата токина для allows и написано много lip все его используют выглядит он приблизительно так у нас мы 10:52 Speaker A берем джейсон с заголовком мы берем джейсон сметой информации кодируем же сон и в боишься 4 и берем некоторую криптографическую подписи или mac от этого всего и а также кодируем b64 и разделяем их точкой в принципе довольно все хорошо но 11:11 Speaker A честно говоря формат down когда он создавался для замены самому большим xml с форматом он конечно более компактен но все же для наших нужд он толстоват то есть мы не хотели использовать jison вот и кодировать его в боишься 4 газировки и 11:28 Speaker A скажем так он не совсем удачный стандарта есть на него есть целая куча а так такие как ну например в заголовке поддерживается алгоритм но он то есть вы нам туда заголовок вставляете и server-side не проверяет подпись вашего токен а еще есть такая штука как и конфи 11:46 Speaker A жена так она работает с их макамы с и 1 on 1 сервер не white list with алгоритмы которые используются вы берете и он работает с ириса вы берете в заголовок пихаете что это должен быть весьма ключ и сервер будет считать что этот сидит 12:02 Speaker A этот токен вообще подписоныч маком возьмет открытый ключ и риса и будет использовать его в качестве ключа подписи ich mag естественно открытый ключ знают все и злоумышленник просто по делу этот токен и это на самом деле довольно популярный task на различных системах и так далее 12:17 Speaker A вот так же есть интересный подход называемом макаронс токены тоже был придуман ребятами из google он совмещать и он как бы позволяет экономить под походы к серверу аутентификации то есть вы получаете макаронс токен и оффлайн без похода куда либо вы можете ограничить скоб навесить 12:38 Speaker A какие-то ограничения на него и так далее но мы ускоряем походы к сервис аутентификации но проигрываем при проверке потому что оффлайн проверка для этой штуки невозможно и вам каждый раз на каждый запрос придется ходить и делать их название токи над 1 peg шин 12:52 Speaker A придется проверять этот токен на каком у какого то сервера и так далее то есть это это неудобно потому что у нас тысячи там десятки тысяч различных микро сервисов и на каждый запрос ходить в какой-то сервис и еще проверять токен но это 13:06 Speaker A действительно тяжело и дальше мой коллега игорь расскажет про то что мы придумали в этом месте спасибо жене всем привет меня зовут ливанец игорь я работаю разработчиком в яндекс паспорте и сегодня я расскажу о нашем решении этой проблемы который 13:28 Speaker A обозначил только что ж не мы его назвали ticket вайден машин и давайте для начала рассмотрим основные его концепции каждый сервис когда выполняю запрос в другой сервис он в запрос добавляет тикет на уровне 7 у нас есть централизованный htpc rs 13:47 Speaker A которые выписывают эти тикеты через этот централизованный сервис мы можем контролировать кто и куда входят какие запросы не так кто и куда входит с какими правами и мы сделали единую библиотеку через которую сервисы проверяют эти тикеты да давайте посмотрим на эту схему сервис 14:14 Speaker A а фоне ходит в твоем и выписывают тикеты на основе знания своего секрета поймать эти киты кэширует и когда ему нужно пойти в сервис б он берет этот ticket is каша и добавляет его запрос сервис б свою очередь когда 14:32 Speaker A тоже тоже христовым и вытягивает оттуда публичные ключи тоже кэширует и когда к ним приходит запрос какой угодно он из запроса берет ticket берет из памяти ключей скармливает их библиотеку и в итоге получает ответ вареники тит или не валидный если ticket 14:53 Speaker A не валидный он говорит 403 например он отказывается выполнять запрос а если ticket валидный он выполняет запрос и таким образом на l7 у нас получается этакий firewall в ки ки ки хранится источник запроса пункт назначения запроса и еще ряд 15:14 Speaker A meta-inf эту информацию например сколько он как долго живет тут a ticket на каких ключах он подписан с какими правами можно выполнять запрос и на стороне сервиса б получается в момент получения запроса достаточно информации а то что принять решение 15:32 Speaker A можно этот запрос выполнять или нельзя и в этом месте на самом деле есть самая самый большой выигрыш в скорости то есть на каждый запрос из сервиса сервис не происходит дополнительно походов по сети давайте посмотрим на отдельные концепции на отдельные моменты реализации от нашей 15:55 Speaker A концепции как видно было только что схеме твоим в этом при таком плохой становится вообще центральной центральным местом центральным узлом центральной . отказа если хотите i knew поэтому предъявляются повышенные требования надежности а потом уже быстродействия что самые ненадежные в 16:16 Speaker A работе эстетики сервиса мы считаем что это бэг-энда они могут отвечать не то они могут вообще не отвечать они могут быть не причем сеть может быть недоступно ну тогда давайте посмотрим что же мы оттуда выгребаем ну и грибам оттуда 16:33 Speaker A например информацию про сервисы то есть нет информацию про сервиса и у нас большое количество сервисов но их ограниченное количество а самое главное что они появляются не так что и бы и часто ну хорошо если в день появится их 16:51 Speaker A несколько штук то есть в принципе работает примерно с одним и тем же набором сервисов а значит мы можем эту информацию запиши ровать и подновлять кэш раз в несколько минут ничего страшного не произойдет если вдруг доступ прорастет не и мгновенно через 17:10 Speaker A несколько минут таким образом мы сэкономили поход в бэг-энд провернуть подобный подход с остальными бы канду не можем отказаться полностью от походов по сети при выполнении своего запроса это очень здорово поднимается надежность дальше давайте посмотрим вот приходит запрос по сети tm смотрит что там ему 17:33 Speaker A прислали он берет из памяти данные из кэша проверяет запрос и дальше он принимать решение выписывать ticket не выписывать и дальше когда ему нужно выписать текет ему нужно выпал выполнить ресурсоемкая операция ему нужно сгенерировать подпись для тить это вообще сантики сформировать и мы помним 17:55 Speaker A о том что примерно одни и те же сервисы на самом деле у него все время в операционном поле значит что и пары источника и пункт назначения тоже появляется не очень часто поэтому получается что он все время выписывает одни и те же токены и раз у нас есть 18:17 Speaker A информация о том какие то ticket он выписывает мы можем сделать эту работу заранее то есть приходит запрос мы покажу проверяем можно такой tickets выписывать или нет дальше мы понимаем что его можно выписать мы лезем в набор регенерированный тикетов берем у кота 18:36 Speaker A берём от туда текет и отдаем если его там нет мы генерируем тикет на лету и тут же кэширует потому что если вдруг какой-то сервис выкатился на новый сервис выкатился на большое количество машин а мы ещё не знали что такое ticket 18:49 Speaker A может потребоваться то был бы здорово чтобы он нас не забуду сил хотя бы на единицу минут но все равно этого важно давайте шагнём немножко дальше вот у нас есть сервис твоем который вертится на десятках машин и выписывайте киты эти 19:09 Speaker A тихие то будут проверяться на сотнях тысяч других машин и надо сэкономить этот ресурс то что немножко может намного будет все равно достаточно что на этом можно было бы начать экономить поэтому мы выбрали алгоритм подписи которые у которого скорость проверки 19:25 Speaker A гораздо выше чем скорость генерации подписи это алгоритм робина уильямса и в наших реалиях он показывает более чем приемлемые для нас результаты то есть скорость проверки вместе с паркингом формат и вот этого всего занимает единицы микросекунд для наших нужд 19:46 Speaker A этого достаточно давайте шагнём немножко дальше вот представим что в каком-то сервисы на стала светлая настоящая он видел аутентификацию во всех во всем своим и степи интерфейсе и без этикета запрос выполнить просто невозможно во время от времени бывает так что нужно 20:07 Speaker A отладить какие-то баги пусть даже и в продакшене ну запуск разработчику нужно выполнить запрос что он сделает он пойдет чтобы мы выпишет о тактике для этого ему потребуется секрет а как разработчики будут раздавать этот секрет друг другу через чат и через почту 20:25 Speaker A записывать на бумажке перекидывать их друг другу самолетиками но очень чтобы избежать вот этого всего и сделать все по-человечески мы решили что разработчику сервиса можно дать право отдать этот получить этот ticket просто потому что он разработчик этого сервиса в качестве aus фактора 20:43 Speaker A мы взяли его из sage ключ потому что в нашей инфраструктуре у разработчика у всех разработчиков есть sage ключе то есть мы в нашей инфраструктуре без него жить не возможно поэтому схема выглядит так разработчик публичным в приватным ключом подписывает запрос 21:03 Speaker A отправляется м твоим берёт публичный ключ этого разработчика проверяет и подпись запроса убеждается что это он далее он смотрит что этому разработчику разрешили так делать и отдает ему ticket хорошо теперь разработчиками и кит может выполнить запрос свой сервис и 21:21 Speaker A посмотреть как она на самом деле ведет себя в продакшн [музыка] но когда у тебя есть какая-то проблема вот тут последние вот вот прям сейчас продакшене что-то не работает вот последний что ты хочешь это осваивать чужое api поэтому хочется просто взять инструмент 21:39 Speaker A и начать его использовать ну ты просто берешь его используешь мы сделали такой инструмент название вот в м knife и научили его выписывать и китай в обмен на секрет в обменные sage подпись еще раз уж пошло такое дело помогает 21:55 Speaker A разработчикам мы добавили туда возможность распарсить ticket вне зависимости от его валидности потому что если тебе пришел ticket или ты сгенерировал что-то не то и не смог выполнить запрос было бы очень полезно посмотреть что же там случилось но чтоб разработчик не парсел там и этот 22:14 Speaker A формат руками мы сделали инструмент который которая может скормите киты посмотреть и понять где он ошибся если не поймет к нам придет мы ему объясним вот здесь дорогой разработчик написано что ты вписал не то поле а еще когда разработчик написал код 22:32 Speaker A который выполняют аутентификацию было бы здорово дать ему возможность покрыть этот код тестами теста это хорошо поэтому мы сделали вот такую возможность в этом же самом инструменте выписывать вечные ticket и которые можно положить в сами тесты и они будут жить вечно и это 22:54 Speaker A безопасно потому что эти титулы пятен на изолированный паре приватных публичных ключей и мы решили одну из проблем пользователя еще мы сделали отдельный инструмент hdp демон который может отвечать на локалхосте и у него есть две задачи он умеет выписывать чеки то и кэшировать 23:20 Speaker A их автора это он умеет проверять эти тикеты для некоторых команд оказалось большой большим препятствием добавление бинарной зависимости ну очевидно что это проблем такие проблемы в основном у команд который работаю со скриптом ими языками вроде но ради питона потому что им удобнее иметь один 23:42 Speaker A и тот же код который не зависит от платформы и разрабатываться например на мате я запускать его на продакшне на linux и для них это оказалось блокером мы сделали возможность им ходить в локалхост чтобы проверять эти тикеты и чтобы они не заморачивались кэшированием 24:01 Speaker A это возможность в этом же демоне даник понятно мы снизили порог вхождения для нас в выигрыш вот в чем когда очень у скриптовых языков есть некоторые проблемы с тем чтобы разделять состояние между маркерами и поэтому скорее всего каждый worker пойдет в твин и выпишет 24:21 Speaker A этот ticket каждый себе то есть если у сервиса 50 worker of он стоит наша api 50 раз ну пусть он лучше сходит свой локалхост зачем доносит нашу api в этом мы выиграли мы сэкономили на рпс of наш сервис хочется еще рассказать не совсем 24:42 Speaker A очевидных вещах то есть твоим позволил ответить на вопрос кто именно пришел и из этого следует не только тот момент можем и от сети злоумышленника или нет мы еще можем воспользоваться этой фичей себе во благо вот примут пощупать ее 25:00 Speaker A пальцами во первых у нас есть большие потребители у которых много точнее не так большие сервисы у которых много потребителей которые удерживают большие рпс и но не бесконечны и у них иногда бывает такая проблема что у какого-то сервиса что-то идет не так он 25:18 Speaker A начинает вдруг генерировать какой-то не нормальную нагрузку и поэтому начинают страдать другие потребители этого большого сервиса в результате того что появился torino теперь этот большой сервис может ответить на вопрос кто именно к нему пришел поэтому он может выделить каждому 25:37 Speaker A из их потребители по квоте и не давать не не выполнять запросы свыше свыше клод и чтобы сломалась не все сразу а только маленький кусочек пусть маленький кусочек не тянет за собой весь остальные домик чтобы он не оказался карточным 25:50 Speaker A следующий момент когда у нас были меж проектные firewall и мы не могли выдать какие-то гранты то есть приходит к нам потребитель и говорит нам нужно ходить вашей сети пикапе и выполнять такие то запрос мы green классно атку все нормально это можно 26:06 Speaker A делать но только тебе потому что у тебя такой сценарий и всем мы открывать такой сценарий не хотим он говорит а я хочу запускать его из любых сетей нет ну таких грантов не выдадим мы не сможем понять что это ты пришел а теперь мы 26:21 Speaker A можем это понять потому что он будет присылать этот ticket и значит что только он владеет этим секретом во всяком случае мы надеемся на то что рассчитываем на то что он это обеспечит и мы смогли выбить такой грант ну раньше этого не могли теперь 26:38 Speaker A можем классно в результате хочется рассказать о том что у нас получилось сделать гибкую систему которая может подстроиться под разные сценарии работы мы не зависим в данном месте от внешних стандартов можем добавлять туда такие fitch какие нам нужны мы смогли приложить какие-то усилия 27:01 Speaker A снизить порог адлера порог входа для новых разработчиков и мы смогли оптимизировать наши server-side на и полно для того чтобы выдерживать большие рпс и и обеспечить большую нагрузку и так но обеспечили возможность выдерживать большую нагрузку вот так правильно еще хочется заметить что это 27:24 Speaker A не все то что мы сделали в рамках проекта под по-твоему мы рассказать только то что успели рассказать заказа эти полчаса ну например у нас есть такой эпизод когда но давайте посмотрим у нас публичные ключи разложенные на множеством джин и у людей библиотека для 27:42 Speaker A того чтобы проверять этикеты но поэтому мы прикинули немножко так и решили что тот сервис который у нас проверяют пользовательские сессии он тоже может выписывать чеки то но другие юзер тикеты в которых хранится за надёжное знание а то что пришел именно о том что именно 28:00 Speaker A этот пользователь пришел по сети то есть давайте соберем всю картинку все вместе вот например есть фронт фронт сервиса а бег этого же сервис а и когда пришел франк ну это был пользовались браузер этапа нажимал кнопочку там за прилетел запрос ему от 28:20 Speaker A браузера за фронт фронт берет куку и несет ее в специальный сервис который занимается проверкой кук тату выдается и помимо путем туда засылает сферы sunseeker он доказывает что это фронт пришел проверять куку хорошо этот сервис по проверке кук возвращает ему юзер китикет и потом 28:43 Speaker A фронт идет в свой бег и не снеся 2 тикета сервисы он доказывает что это действительно фронт этого моего сервиса не какой-то чужой сервис пришел а именно свой фронт родной которому действительно надо доверять и он выполнять запросы именно для этого пользователя и дальше 28:59 Speaker A этот бег может выполнять запросы дальше по сети передавая этот пользовательский тихий таким образом передавая ну из так сказать поэтических волю пользователя сквозь ваши микро сервисы что это не просто идентификатор а это действительно выполнил запрос пользователь скукой да всё у меня моя часть закончена я 29:24 Speaker A приглашаю моих коллег чтобы отвести на вопросы спасибо женя спасибо игорю немножко по организационной части смотрите по вопросам у нас есть время для вопросов у нас есть также микрофон центре зала мы решили не кидать его из угла в угол а если у кого-то есть 29:42 Speaker A вопросы вы хотите пожалуйста к микрофону и задавайте вопрос также у нас есть чатик трансляцию нас есть на снова смотрит оказывается и я зачитаю первый опрос вашего позволения оттуда а разве в агрессии не в контейнерах все живется можно было бы не городить велосипед а 30:02 Speaker A использовать контейнер не только интерфейс решение типа коли ты или целью смотрите у нас в яндексе есть свой пас своя платформа и у нас мы просто грянули немножко что там за решение это все на уровне сети это все на уровне или три то есть у 30:20 Speaker A нас похожая штука тоже используется она называется host bass firewall но она все равно на уровне стены не дает гранулярный стивом то конкретной описки и конкретного приложения то есть например кита опишите приложения может там условно вызывать какие-то там не может вызывать 30:39 Speaker A да да на уровне 7 до дона до уровня и 7 этой этой гранулярный стене достаточно плюс мы избавите себя от фирмы железных фаерволов как я уже говорил во время доклада и вот этот вот костава агента он просто позволяет очень сильно упростить 30:55 Speaker A структуру сети в дата-центрах он позволяет вам условно у вас два сервера в одной стойке так вам получается надо гонять трафик между фирмой железных фрироллов и обратно то есть мы все упрощаем с разных проектов ну да да да и хуй на добавить что вот 31:10 Speaker A этот инструмент который локальной сети 5 демон мы устроили наши облака это было на слайде я забыл рассказать да ну из изнутри контейнера это дым м прим встроенный отзыв одну галочку закрытые можно просто брать и пользоваться она очень простой порог вхождения для 31:25 Speaker A пользователи они просто настраивать свой проект нашем внутреннем по оси и сразу же получают себе межсервисного классификацию спасибо да а вопросы напомню опять же к микрофону можно выйти задать пожалуйста добрый день большое спасибо за доклад все прозвучало очень вкусно и наверное 31:44 Speaker A не только у меня возник вопрос планируется ли выкладывать его консорт если да то где ссылка смотрите при прямо сегодня мы не планируем ничего выкладывать в panzar сны подумаем какие части мы можем за open source и вполне возможно объявим об этом дополнительно 31:58 Speaker A но прям сегодня пока это внутреннее решение с другой стороны как бы мы рассказываем вам все на уровне идеи и здесь нет ничего сложного что мешало бы вам самим все это повторить сколько у вас времени заняло реализация на этот вопрос отвечает игорь 32:16 Speaker A сносите человеко-часов да ну блин сложно сказать что ждет человека год наверно ну скажем так это примерно это на все то есть это не один сервис это именно смотри тут очень много ищет во первых есть еще теперь т.е. а 32:33 Speaker A есть последней мили которую надо уложить станут библиотека билдинги поцци языки бен сборка этих биндинг оф пацан нужны платформы там не за это облако которые этот локальный демон собранный под разные платформы что там все нормально убедиться надо что засунуть его вовсе в 32:53 Speaker A это облако о чем вот это все ну где-то год но надо еще поговорить с другими сервисами но во первых провести исследование поговори с другими сервисами сделать оптимальной реализацию и так далее benchmark отмерить там ну как обычно у нас красная смысле мы очень 33:09 Speaker A любим измерения и как бы никотин просто так production все сразу я еще хочу добавить и себя братом source ожидался такой вопрос если честно мы его ждали я тут на днях вспоминал пересматривал свое выступление на 5 2012 году когда мы 33:26 Speaker A рассказывали про наша идеям которые мы написали и там должен был такой вопрос я неосторожно за сцены пообещала что да наверное будет вот прошло шесть лет ибо этого 10 сделали поэтому мы сейчас боюсь еще либо обещать но как же неправильно 33:40 Speaker A сказал в принципе идея понятна и вполне можно реализовать и самим пожалуй следующий вопрос здравствуйте спасибо большое за доклад у меня наверное немножко дурацкие я что-то мог пропустить но насколько я понял решение классно работает когда вы самостоятельно разрабатываете клиентскую и серверную 33:58 Speaker A часть но наверняка внутри компании есть какие-то скажем так внешне разработанные системы котором тоже приходится работать в таких условиях вот как для них настраивать интерфейс аутентификации спасибо если коротко то не как у нас есть сторонний системы у которых есть 34:19 Speaker A встроенная аутентификация основанная на где ну по всякого with a message ключа где-то на логинов паролях и мы в них не внедрялись возможно это следующий этап но я ничего не так много таких систем и в основном если посмотреть существенная 34:39 Speaker A часть это сам описанной свое отсюда и и проблема насущна и возникла отсюда и не взять ничего снаружи потому что все пишутся внутри все очень кастомное специфические потребности и поэтому систему это дефекации тоже самим писарро опять же зачастую стороне системы 34:54 Speaker A которые могут у нас работать у них есть механизм плагинов house плагинов и иногда можно прям написать плагин а если система поддерживает нативно какую-то другую схему аутентификацию мы ее просто не не меня и мы используем схему authentication которой подержите 35:10 Speaker A стянуты я не знаю mais quel там есть логин пароль и мы как бы не меняем здесь ничего пока и даже ограничивание пыль печника просто с очередями поясните пожалуйста вопрос вы испортите нибудь и в очереди для коммуникации не синхронно между компонентами 35:31 Speaker A сообщения как-нибудь инфицируется версии романе понял вопрос смотрите вообще в целом у нас есть всякие самописные очереди типа но в тот же самый системы доставки логов и так далее да там используется наш authentication везде вот все вещи которые мы делаем внутри 35:53 Speaker A которые служат для внутренних нужд там используется эта схема дефекации как вопрос как бы это вкрутили вам куда бы ты это хочешь спросить ну вопрос блюд круг вкручивали ли нет пока еще не вкручивали мы еще пока думаю над этим 36:11 Speaker A под у нас вот и 90 95 процентов среднем по больнице http с поэтому такая схема более нативно показалось и вопрос как вы решали проблему последней черепахи как как ждущий замедляет ли это или что-то меня откуда появляется собственно секреты которыми сервис 36:40 Speaker A инфицируется в китае нет машин смотрите у нас есть платформа внутренняя и эта задача платформы раскладывать секреты для приложений то есть у нас есть scheduler который запускает контейнеры и так далее это уже немножко другой уровень и там эта задача 36:58 Speaker A решается то есть когда как только стартует приложение у него уже есть целый набор тикетов для сервисов которые он ходит там уже все полученную все каши и прогреты и ничего не мешает ему стартануть уже на уровне платформы спасибо это немножко ортогонального 37:14 Speaker A просто есть как бы доставка секретов и вот это вот давайте последний вопрос и нам нужно будет двигаться дальше спасибо очень круто только вопрос такой как потратить меньше чем человека год например человека неделя для того чтобы внедриться мир there is no 37:29 Speaker A authentication потому что живите не стали использовать или ну как вообще не смотрели потому что валидация настроения как у сервера вас пугало вот это именно проблема смотреть завести на самом деле он поддерживает несколько режимов но для детей есть во первых это толстый формат 37:47 Speaker A то есть когда мы начинаем гонять данные почти во вторых в сауне надо мне достаточно быстро для нас например если мы используем оффлайн проверку в третьих в живите есть целая куча лип и не все они безопасны как я уже говорил 38:00 Speaker A заголовок но в качестве алгоритмов головки выставляешь но мы как бы по либо не проверяет мы не хотим гоняться за всеми этими кейсами и как бы у нас есть наша 1 нативная правильная на наш взгляд либо которое рекомендуется всем 38:14 Speaker A разработчикам внутри но я могу добавить своей стороны только то что за если нужно если нужно именно цель такая человека неделя то нужно на себя в чем-то ограничиться все сразу не успеть во первых но если очень сильно пофантазировать то нужно определиться с 38:31 Speaker A оливой под капот под конкретную платформу и gps сервер с одной или двумя возможностями там выписать эти ты отдать ключи не более или наверное ключи на первом этапе не буду трактира ваться а потом есть еще организационный момент который в неделю 38:48 Speaker A у нас точно не уложился это дойти до сервисов и попросить их вот вот вот у меня есть возможности пожалуйста воспользуйтесь этими возможностями можем заставить сервисы вот прям прийти к ним и сказать вы обязаны это сделать мы им это как бы продаем вырос как бы мы 39:04 Speaker A рекламируем эту штуку мы показываем всякие бонусы которые не могут получить они могут всякие делать кого ты на этой основе там как бы защищаться от и не знаю кого нибудь аналитика который решил там в их сервис отправить 500к рпс вот и 39:17 Speaker A так далее то есть им это очень получается то прихожу я и говорю правду же вы это сделаете спасибо она может двигаться дальше давать еще раз паладину ребятам очень классная штука спасибо Topics: межсервисная аутентификация микросервисы firewall безопасность Yandex клиентские сертификаты macaroon токены LTS облачные технологии контейнеризация --- This is the markdown twin of https://sozai.app/transcript/fast-interservice-authentication-sidorov-klevanets/ — the same content, without the markup. Published by SozAI (https://sozai.app). Reuse and quotation are allowed with attribution and a link back. Machine-readable index: https://sozai.app/llms.txt · data API: https://sozai.app/api/