В мире инфраструктурной инженерии существуют вещи, неподвластные времени. Например, бесконечные YAML-манифесты, которые размножаются быстрее, чем инженеры успевают обновлять документацию. Или удивительная способность специалистов по автоматизации автоматизировать уже существующую автоматизацию, после чего написать ещё один инструмент, который будет автоматизировать предыдущие два. И если ещё несколько лет назад можно было услышать фразы вроде: «Мы создаём виртуальные машины руками через веб-интерфейс, потому что так надёжнее», то сегодня подобные признания воспринимаются примерно так же, как рассказ о том, что резервное копирование производится путём периодического копирования файлов на флешку, лежащую в ящике рабочего стола.

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

Именно на этапе эксплуатации становятся заметны настоящие преимущества зрелых инженерных практик. GitOps позволяет сделать управление доступами воспроизводимым. systemd и Kubernetes обеспечивают надёжный запуск. Аудит помогает отвечать на вопросы безопасников. А опыт эксплуатации учит тому, какие компромиссы действительно оправданы, а какие являются следствием инженерного перфекционизма.

Создать пользователя значительно проще, чем определить, что именно ему разрешено делать.

Большинство проблем современных IAM-систем возникает не на этапе аутентификации, а на этапе авторизации. Кто должен иметь доступ к production? Какие права положены подрядчикам? Что произойдёт после перевода сотрудника в другую команду? Как гарантировать, что увольнение автоматически приведёт к отзыву всех доступов?

Ответы на эти вопросы и отличают простую синхронизацию учётных записей от полноценной системы управления идентификацией.

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

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

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

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

Знаете эту боль? Сначала вы ставите 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 для больших языковых моделей.