Комментарии 9
Система не только обеспечивает безопасность, но и делает взаимодействие между сервисами более эффективным. Лично для меня это стало настоящим удобством и шагом вперед в сфере авторизации. Внедрение таких технологий не только повышает безопасность, но и делает работу с платформой еще более удобной и гладкой
Спасибо за статью. Пара вопросов:
Вы используете https://github.com/open-policy-agent/opa-envoy-plugin , или что-то свое написали, и используете OPA как библиотеку?
Интересно было бы узнать, как вы распростряняете policy и data.
Вы генерируете Rego Policy на основе
auth.toml?
Вначале использовали этот плагин. Но в итоге перешли на свое решение на lua, так как нужно было кэширование и несколько других возможностей, которые плагин не поддерживал.
Есть controlplane, в который ходят все сайдкары и забирает там бандлы https://www.openpolicyagent.org/docs/latest/management-bundles/ Controlplane хранит у себя все необходимые данные и в момент обращения просто собирает этот бандл
Да именно так.
Спасибо, про аутентификацию было интересно, но зацепила немного другая тема. А как происходит подключение нового потребителя к какому либо сервису и как ведется учет используемых полей для сохранения обратной совместимости контрактов?
Есть некий реестр, который хранит brief схемы всех сервисов, а так же brief схемы, которые сервис использует, то есть по сути свои связи. Если провести аналогию, то у реестр хранит proto файл самого сервиса и proto файлы других сервисов, которые он использует. Это очень грубое описание, хранится конечно же все в структурированном виде.
Обновление этой информации происходит после того как сервис задеплоен. В реестр попадают все обновленные и актуальные схемы
Привет! На связи коллега из Сбер Маркета.
Мы у себя применяем два уровня авторизации:
базовый слой - istio mesh
MTLS для всего межсервисного взаимодействия
описываем политики для inbound, outbound трафика (как для внутренних ресурсов, так и для ресурсов и в интернете)
ролевая модель доступа к ресурсам - централизованный сервис авторизации
описываем политики авторизации в файлах конфигурации
написали общие библиотеки для go, python, ruby, которые работают в качестве middleware и ходят в централизованный сервис
Мы уже сталкивались с тем, что неоптимизированный istio mesh выжирал огромное кол-во ресурсов куба (cpu, ram), а хотел уточнить, к уже существующей istio mesh инфре, сколько в % (к cpu, ram) добавляют сайдкары авторизации?
Межсервисная авторизация в Авито PaaS