OpenTofu в 2026 году: почему именно этот инструмент становится фундаментом современной инфраструктуры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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