Ранее мы уже делились опытом запуска функциональности межсервисной авторизации: рассказали о самом важном и полезном, накопившемся на тот момент.
Но в любых проектах самые интересные результаты проявляются спустя какое-то время эксплуатации, когда уже можно оценить эффективность принятых решений и примененных инструментов. А главное — накопилась обратная связь от пользователей продукта.
Мы активно используем межсервисную авторизацию уже более года. И теперь нам снова есть что рассказать 🙂
Всего этого не вместить в один пост, поэтому их будет несколько.
А начну я с технической части, где возникло две основные проблемы:
Первая. Мы выбрали Open Policy Agent в качестве авторизационного движка. Он себя достаточно неплохо показывал на старте: стабильно работал, имел понятные и читаемые политики на языке rego, хорошо интегрировался в существующие процессы.
Однако на высоких rps увеличилось время обработки авторизационных запросов, и стали появляться даже 500ки, что не отвечало требованиям к проекту.
Вторая. Чтобы решить проблемы, мы использовали кэширование авторизационных запросов на стороне envoy (это прокси-сайдкар в нашем service mesh, который построен на Istio).
Lua лучше всего подходил для этого, а коробочный функционал evnoy не обладал этой возможностью. Но и тут подстерегала засада. Реализация Lua в Envoy буферизует запрос перед тем, как отправить его. Это создало серьёзные трудности у ручек, которые принимают большие body.
В целом, если у вас версия envoy 1.27+, то проблему можно решить реализацией расширения на golang, но у нас на тот момент была версия ниже.
В итоге, я бы не стал использовать OPA, если милисекунды имеют большое значение. Конечно, можно оптимизировать кэшированием, или улучшить, оптимизировать и отпрофилировать rego политики. Но, возможно, написать свою реализацию политик, простую как палка, может оказаться более коротким путем.
#avitoteam