Сегодня хотим поделиться с вами - RBAC-Engine 😱
Какую задачу мы решали. 😈
Есть обычный Kubernetes-кластер, по мере роста появляются новые контроллеры, роли, биндинги и в какой-то момент становится сложно ответить на базовый вопрос —
как вообще выглядит матрица доступов и кто к чему имеет доступ.
Даже на простом примере:
• pods/exec | verb=get,create
• nodes/proxy | verb=get,create
Попробуйте сходу понять 💬:
• Какие роли это разрешают
• Какие service accounts / пользователи с ними связаны
• Через какие биндинги это всё выдается
Отдельная боль — политики уровня "*", которые размывают реальную картину доступа.
Чтобы это разобрать, мы пошли двумя путями: 😎
1. Политики (аналог Trivy-подхода)
Сделали свой механизм правил который позволяет:
• Описывать интересующий скоуп
• Применять к кластеру или namespace
• Получать результат со скорингом
Это даёт быстрый ответ — где 💩
2. Граф связей (Agregation Layer API)
AGL позволил реализовать in-memory GRAPH DB, в рамках кторой находятся все связи и граф всегда простраивается относительно прав пользователей, так что лишнего не увидят.
AGL предоставляет возможность: ☹️
• Фильтровать по нужному скоупу
• Отображать, кто реально может использовать доступ
• Накладывать результаты политик поверх найденных связей
• Резолвить "*" в Rule на основе реальной схемы OpenAPI кластера
В итоге вы получаете инструмент с помощью которого:
• Быстро находите роли с нужным доступом
• Понимаете, кто пользуется найденными ролями
• Понимаете, через какой биндинг выдан этот доступ
Такой подход позволяет убрать десятки, а может сотни человекочасов работы и получить ту прозрачность которую мы заслужили)
Полезная информация:
• Исходники на GitHub
• Chart на GitHub
Лучшая ваша похвала — это: 🤪
• Вопросы по теме
• Поиск неточностей
• Советы, как сделать лучше
• И, конечно, ⭐️ на GitHub