RBAC и ABAC в IAM-системах: как выбрать модель контроля доступа и настроить её в Keycloak, LDAP и Kubernetes

RBAC и ABAC - две ключевые модели контроля доступа в IAM-системах. RBAC выдает права через роли: пользователь получает роль, роль содержит набор разрешений. ABAC принимает решение по атрибутам: кто обращается (субъект), к какому ресурсу, с каким действием и в каком контексте (среда). Отсюда главное различие: RBAC отвечает на вопрос «какая у вас роль», ABAC отвечает на вопрос «совпадают ли атрибуты запроса с политикой».

Алгоритм выбора для крупной организации: если правило формулируется как «этой группе можно это», нужен RBAC. Модель предсказуема, аудит сводится к проверке списка ролей, решение не зависит от времени и IP-адреса. Если в правиле появляется «если», «только когда», «кроме случаев» (доступ к production в окно релиза, персональные данные при включенном MFA, временный доступ по заявке), подключают ABAC. На практике модели комбинируют: RBAC дает базовый каркас прав, ABAC закрывает контекстно-зависимые сценарии.

В Kubernetes базовая авторизация построена на RBAC, а аутентификацию выносят во внешний OIDC-провайдер. kube-apiserver получает от Keycloak, Dex или Azure AD подписанный JWT, проверяет подпись по discovery-документу, извлекает из claims имя пользователя и группы, а ClusterRoleBinding и RoleBinding превращают группы в конкретные права. Пользователи входят через kubelogin, CI/CD-пайплайны работают через ServiceAccount, корпоративные каталоги LDAP и Active Directory синхронизируются с провайдером идентификации.

Дальше: сравнение моделей по критериям, пошаговая настройка OIDC и RBAC, паттерны комбинирования RBAC с ABAC через Open Policy Agent и Kyverno, сервисные аккаунты для CI/CD, диагностика ошибок 401 и 403, ротация учетных данных и выбор провайдера идентификации.

RBAC и ABAC: ключевые различия и критерии выбора модели

Обе модели отвечают на один вопрос: можно ли субъекту выполнить действие над ресурсом. Различаются входные данные, гибкость и стоимость сопровождения.

Как работает RBAC: роли, разрешения и иерархия

Механика простая: пользователь → роль → разрешения. Роль admin получает полный доступ, developer - чтение и изменение рабочих namespace, viewer - только чтение. Пользователей объединяют в группы, группы привязывают к ролям: при найме человека достаточно добавить в группу, при увольнении - убрать из группы.

Иерархия ролей позволяет наследовать разрешения: старшая роль включает младшую. В Keycloak это composite roles, в Azure RBAC - определения ролей с наследованием на уровне области, в Kubernetes - агрегированные ClusterRole, собранные из других ролей по метке. Наследование сокращает число назначений, но усложняет ответ на вопрос «откуда у пользователя это право»: цепочку приходится разворачивать целиком.

Плюсы RBAC: простой аудит (проверяется список ролей и привязок), предсказуемость (решение не зависит от времени, IP и состояния устройства), быстрый старт. Минусы проявляются при росте организации. Каждое новое измерение (продукт, окружение, регион) умножает число ролей: 5 продуктов × 4 окружения × 3 уровня доступа дают 60 ролей, а с временными и сервисными учетками счет идет на сотни. Роль developer одинаково работает в 3 часа ночи и в полдень, из офиса и из публичной сети: контекст в модели не учитывается.

Как работает ABAC: атрибуты, политики и контекст

ABAC принимает решение по четырем группам атрибутов: субъект, ресурс, действие, среда. Типичный набор: отдел и уровень допуска сотрудника, классификация ресурса (публичный, внутренний, персональные данные), тип операции (чтение, запись, удаление) и контекст (время суток, IP-подсеть, статус MFA, управляемое устройство). Правило читается так: доступ к базе с персональными данными разрешен, если department == 'finance', classification == 'pii', mfa == true и время запроса попадает в рабочий интервал.

Решает политика, которую исполняет движок: Policy Decision Point (PDP) выдает ответ allow/deny, Policy Enforcement Point (PEP) применяет его. В Kubernetes роль PDP часто выполняет Open Policy Agent или Kyverno на этапе admission-проверок.

Плюсы ABAC: гранулярность без взрыва ролей (одна политика закрывает тысячи комбинаций), учет контекста, изменение правил без пересборки ролей. Минусы: сложная отладка (на вопрос «почему deny» отвечает трассировка политик, а не список ролей), требования к качеству атрибутов (если отдел в HR и в AD расходится, политика срабатывает неправильно), задержка на вызов внешнего движка и необходимость версионировать и тестировать политики как код.

Сравнительная таблица: RBAC vs ABAC

Критерий выбора: если правило описывается фразой «этой группе можно это», берите RBAC. Если в правиле есть условие на контекст, добавляйте ABAC поверх. Гибридная модель закрывает оба требования: RBAC отвечает за базовые права и аудит, ABAC - за доступ к чувствительным данным и production.

Настройка RBAC в Kubernetes через OIDC-интеграцию с Keycloak и Dex

Архитектура интеграции строится вокруг OIDC. kube-apiserver получает от провайдера идентификации подписанный JWT, проверяет подпись по discovery-документу, извлекает из claims имя пользователя и группы, после чего RBAC-привязки превращают группы в права. Встроенные механизмы работают хуже в масштабе: kubeadm выдает клиентские сертификаты на 1 год, отозвать сертификат нельзя, потому что kube-apiserver не проверяет CRL для клиентских сертификатов, а статический токен действует бессрочно и требует перезапуска API-сервера при каждой правке списка.

Результат OIDC-интеграции: вход по корпоративной учетной записи с MFA, отзыв доступа через деактивацию в IdP, автоматическая выдача прав по группам AD и ротация токенов без ручных действий. Базовый сценарий с одним IdP и одним кластером закрывается за несколько часов: флаги API-сервера, kubeconfig, две RBAC-привязки и один ServiceAccount для пайплайна. Полный разбор с шаблонами манифестов и диагностикой ошибок 401 и 403 собран в статье Интеграция IAM с Kubernetes: настройка безопасного доступа к кластеру и управление сервисными аккаунтами.

Для стенда, где нужно отработать конфигурацию до продакшена, подойдет облачная инфраструктура: Timeweb Cloud дает виртуальные серверы для self-managed кластера и управляемый Kubernetes для быстрого старта.

Обязательные флаги kube-apiserver для OIDC

Минимальный набор: --oidc-issuer-url, --oidc-client-id, --oidc-username-claim, --oidc-groups-claim, --oidc-ca-file. Пример для kubeadm-кластера (манифест /etc/kubernetes/manifests/kube-apiserver.yaml):

--oidc-issuer-url=https://idp.example.local/realms/k8s
--oidc-client-id=kubernetes
--oidc-username-claim=preferred_username
--oidc-groups-claim=groups
--oidc-ca-file=/etc/kubernetes/pki/oidc-ca.crt

Требования к значениям жесткие. issuer URL совпадает с claim iss в токене символ в символ, включая схему и отсутствие завершающего слеша. client-id попадает в aud токена. CA-файл нужен, если IdP использует самоподписанный сертификат. Правка флагов в kubeadm-кластере выполняется через манифест, kubelet перезапустит статический под автоматически.

Проверка discovery-документа до перезапуска:

curl -s https://idp.example.local/realms/k8s/.well-known/openid-configuration | jq .issuer

Ответ должен совпасть с --oidc-issuer-url. Расхождение схемы http/https или лишний слеш дают 401 на каждом запросе, хотя настройки IdP выглядят корректно.

Настройка Keycloak с LDAP/Active Directory

Порядок для Kubernetes: создать realm, подключить User Federation с LDAP или Active Directory (connection URL, bind DN, users DN, периодическая синхронизация), затем создать клиент kubernetes с включенной клиентской аутентификацией.

Ключевой шаг - маппинг групп. По умолчанию группы в токен не попадают, и RBAC-привязки не сработают. Нужен mapper типа Group Membership в client scope, который клиент kubernetes использует по умолчанию. В настройках mapper отключите Full group path для коротких имен групп и задайте Token Claim Name = groups. Дополнительно настройте Audience mapper: добавьте kubernetes в aud, иначе kube-apiserver отклонит токен.

Проверка: в консоли Keycloak откройте Client Scopes → Evaluate, выберите пользователя и посмотрите итоговый токен. В payload должны присутствовать claims preferred_username, groups и aud: kubernetes. Если групп нет, проверьте членство пользователя в каталоге, результат синхронизации и наличие group mapper именно в том client scope, который назначен клиенту.

Для защиты kubectl добавьте второй фактор: OTP или WebAuthn в authentication flow realm. Как включить 2FA для kubectl и веб-интерфейсов через Keycloak, пошагово разобрано в статье Защита Kubernetes с двухфакторной аутентификацией.

Настройка Dex с LDAP

Dex подходит, когда нужен легкий OIDC-провайдер без веб-консоли: один бинарник, конфигурация в YAML, хранение состояния в Kubernetes CRD или etcd. Каркас config.yaml:

issuer: https://dex.example.local
storage:
  type: kubernetes
  config:
    inCluster: true
connectors:
  - type: ldap
    id: ldap
    name: Corporate LDAP
    config:
      host: ldap.example.local:636
      insecureNoSSL: false
      bindDN: cn=svc-dex,ou=services,dc=example,dc=local
      bindPW: $LDAP_BIND_PASSWORD
      userSearch:
        baseDN: ou=people,dc=example,dc=local
        filter: "(objectClass=posixAccount)"
        username: uid
        idAttr: uid
        emailAttr: mail
        nameAttr: cn
      groupSearch:
        baseDN: ou=groups,dc=example,dc=local
        filter: "(objectClass=groupOfNames)"
        userMatchers:
          - userAttr: DN
            groupAttr: member
        nameAttr: cn
staticClients:
  - id: kubernetes
    name: Kubernetes
    secret: $K8S_CLIENT_SECRET
    redirectURIs:
      - http://localhost:8000
      - http://localhost:18000

Секреты держите в переменных окружения или Secret, не в открытом виде. Идентификатор клиента и issuer из конфига переносятся в флаги kube-apiserver. Отличия от Keycloak: Dex проще в сопровождении и не требует отдельной БД, но не дает админ-консоли, тонкой настройки flows и богатой федерации. Выбор сводится к простоте против функциональности: для небольшого кластера достаточно Dex, для крупной организации с несколькими каталогами выигрывает Keycloak.

ClusterRoleBinding и RoleBinding: права на уровне кластера и namespace

RBAC в Kubernetes состоит из ролей и привязок. Role и ClusterRole описывают наборы правил (apiGroups, resources, verbs), RoleBinding и ClusterRoleBinding связывают правила с субъектами: пользователями, группами, ServiceAccount. ClusterRoleBinding выдает права на уровне всего кластера, RoleBinding ограничивает действие роли пределами одного namespace.

Пример: группа k8s-developers из OIDC-claims получает право читать pods и services в namespace dev. Сначала ClusterRole с правилами:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: developer-read
rules:
  - apiGroups: [""]
    resources: ["pods", "services"]
    verbs: ["get", "list", "watch"]

Затем RoleBinding, который ссылается на роль и ограничивает ее одним namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-team-read
  namespace: dev
subjects:
  - kind: Group
    name: k8s-developers
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: developer-read
  apiGroup: rbac.authorization.k8s.io

Два правила экономят часы отладки. Имя группы в subject совпадает со значением claim groups посимвольно, включая регистр. RoleBinding может ссылаться на ClusterRole: одна роль переиспользуется во всех namespace, а область действия остается ограниченной.

Проверка прав без реального пользователя:

kubectl auth can-i list pods -n dev \
  --as=ivan.petrov \
  --as-group=k8s-developers

Принцип наименьших привилегий: выдавайте конкретные verbs и resources, не назначайте cluster-admin вне аварийных ситуаций, проверяйте выданные права командой kubectl auth can-i --list. Готовые манифесты для разработчиков, CI/CD и мониторинга с примерами аудита собраны в статье RBAC в Kubernetes 2026: практическое управление доступом через Role, RoleBinding и ClusterRoleBinding.

Получение доступа к кластеру через kubelogin

Пользователь настраивает kubeconfig с exec-плагином kubelogin (oidc-login). Установка через krew: kubectl krew install oidc-login. Блок user в kubeconfig:

users:
  - name: oidc
    user:
      exec:
        apiVersion: client.authentication.k8s.io/v1
        command: kubectl
        args:
          - oidc-login
          - get-token
          - --oidc-issuer-url=https://idp.example.local/realms/k8s
          - --oidc-client-id=kubernetes
          - --oidc-client-secret=$CLIENT_SECRET

Процесс входа: kubectl вызывает плагин, плагин открывает браузер, пользователь проходит аутентификацию с MFA, получает ID- и refresh-токен и кеширует их в ~/.kube/cache/oidc-login. Последующие команды используют кеш, токен обновляется автоматически по refresh-токену. Проверка: kubectl get pods -n dev, затем kubectl auth can-i --list для просмотра эффективных прав.

На сервере без браузера помогает device code flow или проброс порта: плагин выводит ссылку и ждет подтверждения. Если плагин не может достучаться до кластера, проверьте свежесть кеша и часы на рабочей станции: рассинхронизация времени ломает проверку JWT.

Комбинирование RBAC и ABAC для гибкой системы авторизации

Гибридная модель строится по принципу «RBAC решает, может ли субъект выполнить действие в принципе, ABAC уточняет, при каких условиях». Такое разделение оставляет аудит простым, а контекстные ограничения выносит в политики.

Паттерны комбинирования: RBAC как база, ABAC как надстройка

Паттерн 1: RBAC как база, ABAC как надстройка. Роль developer через RoleBinding дает доступ к namespace production, но validating-политика запрещает менять workloads вне окна релиза и без группы sre-oncall. Базовое право есть всегда, фактическое действие возможно только при выполнении условий.

Паттерн 2: ABAC принимает решение, RBAC отвечает за аудит. Движок политик вычисляет доступ по атрибутам (отдел, уровень допуска, метки данных), а роль остается учетной единицей для отчетов: безопасность видит назначенные роли и сопоставляет их с фактическими обращениями к ресурсам.

Типовые сценарии для ABAC-надстройки:

• Доступ к production: разрешен только в окно обслуживания, из корпоративной подсети и при активной заявке в тикет-системе.
• Персональные данные: доступ к ресурсам с меткой pii требует уровня допуска и пройденного MFA.
• Временный доступ (JIT): роль выдается на 4 часа по заявке, политика проверяет expiry и ticket_id в атрибутах сессии.

Ограничение, о котором узнают на практике: admission-политики в Kubernetes проверяют операции записи (create, update, delete), а чтение (get, list, watch) не фильтруют. Контекстные ограничения на чтение строят иначе: отдельные namespace или кластеры для чувствительных данных, NetworkPolicy, service mesh. Поэтому RBAC остается основой разграничения чтения.

Инструменты для ABAC: Open Policy Agent и Kyverno

Open Policy Agent работает на языке Rego и чаще всего подключается к Kubernetes через Gatekeeper. Пример: запретить изменения в production пользователям не из группы sre-oncall.

package kubernetes.admission

deny[msg] {
  input.request.namespace == "production"
  not is_oncall
  msg := "Изменения в production разрешены только группе sre-oncall"
}

is_oncall {
  input.request.userInfo.groups[_] == "sre-oncall"
}

Kyverno делает то же декларативными YAML-правилами, без языка программирования:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: prod-oncall-only
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-oncall-group
      match:
        any:
          - resources:
              namespaces: ["production"]
              operations: ["CREATE", "UPDATE", "DELETE"]
      validate:
        message: "Изменения в production разрешены только группе sre-oncall"
        deny:
          conditions:
            any:
              - key: "{{ request.userInfo.groups }}"
                operator: AllNotIn
                value: ["sre-oncall"]

Сравнение: Rego дает полную свободу (сложные вычисления, внешние данные, решения вне Kubernetes: API-шлюзы, Envoy), но требует изучения языка и дисциплины тестирования. Kyverno ниже порогом входа: правила пишутся на YAML, читаются как обычные манифесты, ограничены возможностями шаблонов. Интеграция с RBAC: сначала срабатывает RBAC-фильтр, затем admission-политика проверяет условия. Такой порядок сохраняет производительность и делает расследование понятным: отказ RBAC и deny от политики различаются в логах.

Черновики Rego- и Kyverno-политик удобно генерировать и проверять на тестовых запросах с помощью LLM. Единый доступ к GPT, Gemini и Claude без VPN и с оплатой в рублях дает агрегатор AiTunnel: можно быстро получить первую версию правила и набор тестов на граничные случаи, а затем прогнать их в CI.

Сервисные аккаунты для CI/CD: создание, ограничение прав и ротация

Пайплайну нужна учетная запись без человека, поэтому вместо пользователя создается ServiceAccount: его токен подставляется в kubeconfig CI-системы, а права ограничиваются RBAC.

Создание ServiceAccount и генерация токена

Создание и выпуск токена:

kubectl create serviceaccount ci-deployer -n dev
kubectl create token ci-deployer -n dev --duration=3600s

Команда create token обращается к TokenRequest API и возвращает короткоживущий JWT. По умолчанию токен действует час, срок задается флагом duration. Долгоживущие токены через Secret типа kubernetes.io/service-account-token работают до сих пор, но не рекомендуются: такой токен не привязан к сроку и не ротируется автоматически. Начиная с Kubernetes 1.24 Secret с токеном не создается автоматически при создании ServiceAccount.

Формирование kubeconfig для CI/CD-системы

Из выпущенного токена собирается kubeconfig минимального вида:

apiVersion: v1
kind: Config
clusters:
  - name: prod
    cluster:
      server: https://k8s-api.example.local:6443
      certificate-authority-data: BASE64_CA
users:
  - name: ci-deployer
    user:
      token: TOKEN
contexts:
  - name: ci
    context:
      cluster: prod
      user: ci-deployer
      namespace: dev
current-context: ci

В GitLab CI токен храните в masked variable, kubeconfig собирайте в before_script; в Jenkins используйте credentials binding; в GitHub Actions - secrets. Файл kubeconfig не коммитьте в репозиторий. Токен живет час, поэтому пайплайн либо получает свежий токен на старте задания, либо использует CronJob, который обновляет Secret с токеном, либо переходит на обмен OIDC-токена CI-системы на права в кластере.

Ограничение прав ServiceAccount через RBAC

Role для деплойера с минимумом прав:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ci-deployer
  namespace: dev
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "patch", "update"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

Привязка к ServiceAccount:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ci-deployer
  namespace: dev
subjects:
  - kind: ServiceAccount
    name: ci-deployer
    namespace: dev
roleRef:
  kind: Role
  name: ci-deployer
  apiGroup: rbac.authorization.k8s.io

Проверка эффективных прав:

kubectl auth can-i --list \
  --as=system:serviceaccount:dev:ci-deployer \
  -n dev

Правила гигиены: отдельный ServiceAccount на каждый пайплайн и окружение, запрет cluster-admin, отказ от verbs: ["*"], исключение доступа к secrets, если деплой не требует их чтения. Удаление ServiceAccount автоматически инвалидирует его токены: искать и отзывать выпущенные JWT вручную не нужно.

Типичные ошибки при настройке IAM с Kubernetes и их решение

Ошибки аутентификации: токены и issuer URL

Симптом: 401 Unauthorized на любой команде kubectl. Частые причины:

• issuer URL в флагах kube-apiserver не совпадает с claim iss: лишний слеш, http вместо https, обращение по внутреннему DNS вместо внешнего имени.
• Токен истек или часы клиента и сервера разошлись: проверка exp и nbf чувствительна к рассинхронизации.
• client-id не совпадает со значением aud в токене, обычно из-за отсутствующего Audience mapper.
• CA-сертификат IdP не указан в --oidc-ca-file, и проверка подписи JWT падает.

Диагностика: сравните iss из payload токена с флагом API-сервера, проверьте discovery-документ, посмотрите логи пода kube-apiserver на control plane. Payload декодируется из Base64 без внешних сервисов: достаточно вырезать среднюю часть JWT и раскодировать ее.

Ошибки авторизации: RBAC и claims

Симптом: аутентификация проходит, но команда возвращает 403 Forbidden. Частые причины:

• В токене нет claim groups: mapper групп не настроен или не добавлен в нужный client scope.
• Имя группы в RBAC-привязке не совпадает со значением claim: другой регистр, полный путь группы вместо короткого имени.
• Привязка создана в другом namespace или ссылается на роль без нужных verbs и resources.
• Правило описывает не тот ресурс: например, deployment лежит в apiGroups apps, а в rules указан только pods.

Диагностика: kubectl auth can-i с флагами --as и --as-group показывает решение RBAC без реального входа; список привязок выводится командой kubectl get rolebindings,clusterrolebindings -A; audit log показывает, какая группа пришла в запросе. RBAC складывается: подходящая привязка выдает право, deny-правил в штатном RBAC нет, поэтому лишние привязки тихо расширяют доступ.

Проблемы с сертификатами и сетевой доступностью

Симптомы: x509: certificate signed by unknown authority, TLS handshake timeout, connection refused. Причины: неверный или истекший CA, блокировка трафика между kube-apiserver и IdP, DNS-имя IdP не резолвится с control plane. Проверьте цепочку сертификатов, доступность порта 443 с узла control plane и корректность DNS.

Отдельный риск: IdP, развернутый внутри того же кластера, создает зависимость от самого себя. При аварии кластера вы не сможете аутентифицироваться через OIDC, чтобы ее устранить. Держите провайдера идентификации вне управляемого кластера или в отдельном контуре с собственным админ-доступом. Регулярные проверки RBAC, ServiceAccount, Secrets и control plane сведены в чек-лист Аудит безопасности Kubernetes-кластера: базовые проверки для DevOps-инженеров и администраторов.

Безопасность, ротация учетных данных и аудит доступа

Ротация токенов и сертификатов

Сроки жизни учетных данных определяют поверхность атаки. Ориентиры: access-токены OIDC держите короткими (Keycloak по умолчанию выдает access token на 5 минут, refresh token живет дольше), токены ServiceAccount выпускайте через TokenRequest на время задания, клиентские сертификаты kubeadm живут 1 год: продлить их можно командой kubeadm certs renew all, а проверить сроки - kubeadm certs check-expiration.

Клиентские сертификаты Kubernetes не отзываются: API-сервер не проверяет CRL для клиентских сертификатов, поэтому уволенный сотрудник с сохраненной копией сертификата сохраняет доступ до истечения срока. Перевод человеческих учетных записей на OIDC с отзывом через IdP закрывает эту дыру.

Автоматизация ротации: секрет клиента в Keycloak или Dex меняйте по расписанию и храните в Vault или KMS, обновление ServiceAccount-токенов поручайте CronJob, следите за сроком сертификатов IdP. Просроченный сертификат IdP ломает вход всех пользователей сразу, поэтому алерты ставьте заранее, за 30 и 7 дней до истечения.

Аудит доступа и мониторинг

Audit policy в Kubernetes описывает, что писать в лог: уровни None, Metadata, Request и RequestResponse задаются отдельно для каждого типа ресурса. Metadata достаточно для отслеживания действий пользователей, RequestResponse включайте точечно: полное тело запроса резко увеличивает объем логов и может содержать секреты.

Минимальный набор событий для мониторинга и алертов:

• Неудачные попытки аутентификации (401) и отказы авторизации (403) с группировкой по пользователю.
• Изменения RBAC: создание, изменение и удаление ролей и привязок, особенно cluster-admin.
• Чтение и изменение Secrets, exec и port-forward в поды.
• Создание токенов ServiceAccount и изменения их привязок.

Логи уходят в SIEM (ELK, Splunk), где настраиваются корреляции: серия 403 от одного пользователя, доступ к secrets в нерабочее время, появление новой cluster-admin привязки. Для зрелых организаций полезна сверка прав между системами: учетные записи и группы в каталоге, роли в облачных IAM, sudoers на Linux, права в Active Directory. Методики такой сверки для Linux, Windows, AWS IAM, Azure RBAC и GCP IAM разобраны в статье Аудит политик и прав доступа (IAM): практическое руководство для Linux, Windows и облачных сервисов.

Выбор OIDC-провайдера: Keycloak, Dex или Azure AD

Провайдер идентификации определяет, сколько усилий уйдет на сопровождение. Сравнивайте по четырем осям: функциональность, сложность, поддержка каталогов, стоимость.

Keycloak: функциональность и сложность настройки

Keycloak дает федерацию с LDAP и Active Directory, гибкие мапперы claims, кастомизацию тем и flows, встроенные OTP и WebAuthn, self-service для пользователей. Плата за это: сложная настройка (realm, clients, scopes, mappers), требования к ресурсам (JVM-сервис) и отдельная база данных, которую нужно администрировать. Сценарий: крупная организация с несколькими каталогами и требованиями к тонкой настройке правил. Для Kubernetes-интеграции хватает одной realm и одного клиента, но первый запуск занимает больше времени, чем у альтернатив.

Dex: легковесный OIDC-провайдер для Kubernetes

Dex - легковесный OIDC-провайдер: один бинарник, конфигурация в YAML, хранение состояния в Kubernetes CRD или etcd. Из коробки подключаются LDAP, GitHub, SAML и другие OIDC-провайдеры, для Kubernetes настраивается static client. Минус: нет админ-консоли и богатой федерации, часть настроек (группы, маппинг claims) требует ручной правки конфига и перезапуска. Сценарий: небольшие кластеры, стартапы, команды, которые держат конфигурацию в Git.

Azure AD: интеграция для организаций Microsoft

Azure AD (Microsoft Entra ID) выбирают организации, живущие в экосистеме Microsoft: единый вход с Microsoft 365, MFA, условный доступ (conditional access), который учитывает устройство, геолокацию и риск входа. Интеграция с Kubernetes идет через OIDC, группы из Azure AD попадают в claims и превращаются в права через RBAC. Минусы: привязка к Azure, лицензирование и зависимость от внешнего облачного сервиса. Сценарий: компания уже использует Microsoft 365 и Azure, отдельный IdP ей не нужен.

Практический порядок: начните с RBAC-каркаса ролей и привязок, подключите OIDC-провайдер под масштаб организации (Dex для пары кластеров, Keycloak для сложной федерации, Azure AD для Microsoft-контура), добавьте ABAC-политики там, где правила зависят от контекста, и закройте контур аудитом и ротацией токенов. Такой набор дает и предсказуемость базовых прав, и гибкость крупной распределенной инфраструктуры.