FreeIPA и Keycloak (часть 3): Управление ролями и жизненным циклом сотрудников

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

Бизнес хочет автоматически назначать роли новым сотрудникам. Информационная безопасность требует немедленно отзывать доступы у уволенных работников. Аудиторы задают вопросы о причинах изменения прав. Платформенные команды хотят хранить правила в Git и управлять ими декларативно.

Когда инфраструктура только появляется, управление доступами кажется удивительно простой задачей. Пользователей немного, сервисов ещё меньше, а новый сотрудник получает доступы буквально за несколько минут. Администратор заводит учётную запись в GitLab, вручную добавляет пользователя в Jenkins, создаёт VPN-профиль, отправляет логин и пароль в корпоративный мессенджер и идёт пить кофе с ощущением хорошо выполненной работы.

Проблемы начинаются тогда, когда компания перестаёт быть маленькой. Пять сотрудников превращаются в пятьдесят. Затем в сто. Затем появляется несколько команд разработки, отдел аналитики, подрядчики, стажёры, внешние консультанты и дежурные инженеры. Одновременно с этим растёт количество систем: GitLab, Jenkins, Grafana, ArgoCD, Harbor, OpenSearch, VPN, внутренние порталы, Wiki, корпоративные приложения и ещё несколько загадочных виртуальных машин, назначение которых никто уже толком не помнит, но выключить их страшно, потому что "что-то перестанет работать".

Есть одна мысль, которую многие компании почему-то осознают только после третьего массового увольнения, пятого выгорания команды и седьмого “а почему у нас опять все легло ночью”.

Инфраструктура - это не про технологии.
Инфраструктура - это про людей.

Есть один очень характерный этап взросления инфраструктуры.

Сначала все выглядит прекрасно:

• один backend,
• один nginx,
• один PostgreSQL,
• один frontend,
• и один человек, который “примерно помнит где лежат конфиги”.

Все просто. Все понятно. Все работает.

Знаете эту боль? Сначала вы ставите Keycloak «на пробу» на пару месяцев. Всё летает. Вы даёте ссылку на auth.myapp.ru разрабам. А потом бац - прод, 10 тысяч пользователей, и Keycloak внезапно говорит: «Я устал, я ухожу, и все сессии с собой забираю». Мммм. Классика!

И тут из-за угла, на белом коне (слегка прихрамывающем, потому что JVM жрёт память) приезжает кластерный Keycloak.

В 2026 году Kubernetes окончательно превратился из "оркестратора контейнеров" в полноценную операционную систему для датацентра. Если в 2020-м все радовались автоматическому рестарту Pod'ов, то сейчас инфраструктурщики обсуждают GPU scheduling, inference gateway, multi-cluster federation и стоимость токена у LLM-моделей так, будто это курс нефти Brent.

И вот здесь появляется Kubernetes Operator.

Не просто очередной контроллер. Не просто "скрипт в контейнере". А полноценный способ научить Kubernetes понимать ваш бизнес-домен.

В этой статье мы напишем настоящий Kubernetes Operator на Python для одной из самых хайповых тем 2026 года - управления AI Gateway для больших языковых моделей.