Группы безопасности через LDAP: RBAC на основе членства в Active Directory и OpenLDAP

Почему RBAC через LDAP - это основа безопасности инфраструктуры

Ручное управление доступом в Linux, TrueNAS и Kubernetes создаёт три критичные проблемы. Первая - ошибки: администратор забывает отозвать права у уволившегося сотрудника, и учётная запись остаётся активной месяцами. Вторая - трудозатраты: в инфраструктуре из 50 серверов добавление нового пользователя требует зайти на каждую машину и выполнить useradd. Третья - отсутствие аудита: невозможно быстро ответить на вопрос, кто и когда получил доступ к конкретному ресурсу.

RBAC через LDAP-группы решает эти проблемы централизованно. Active Directory или OpenLDAP становятся единым источником правды о пользователях и их ролях. При приёме сотрудника его учётную запись добавляют в нужные группы - и он автоматически получает sudo-права на Linux-серверах, доступ к SMB-шарам на TrueNAS и разрешения в Kubernetes-кластере. При увольнении учётную запись блокируют в каталоге - и доступ пропадает везде одновременно.

Стек технологий для реализации: SSSD для синхронизации групп LDAP с локальными группами Unix, sudoers с префиксом % для делегирования прав целым группам, встроенный LDAP-клиент TrueNAS для ACL на файловых шарах, Dex или Keycloak в роли OIDC-провайдера для Kubernetes. Каждый компонент настраивается один раз, после чего управление доступом сводится к изменению членства в группах каталога.

Подготовка LDAP-окружения: группы и пользователи

Перед настройкой клиентов нужно спроектировать структуру групп в каталоге. Главный принцип: одна группа - одна роль. Группы называйте по шаблону платформа-роль, это упрощает чтение конфигураций и аудит. Избегайте вложенности глубже двух уровней - SSSD и Kubernetes не всегда корректно обрабатывают транзитивные членства.

Типичная ошибка - использование встроенных групп Active Directory, таких как Domain Admins. Эти группы защищены механизмом AdminSDHolder, который сбрасывает ACL каждые 60 минут и ломает делегированные разрешения. Создавайте отдельные группы для каждой платформы.

Структура групп для Linux, TrueNAS и Kubernetes

Логика разделения: linux-sudoers получает неограниченный sudo, а linux-www-admins - только перезапуск сервисов и чтение логов. Это реализует принцип наименьших привилегий. Аналогично для Kubernetes: k8s-cluster-admins - это полный доступ, а k8s-developers ограничены конкретными namespace.

В Active Directory группы создаются через оснастку Active Directory Users and Computers. В OpenLDAP - через LDIF-файлы или инструменты вроде phpLDAPadmin. Убедитесь, что у групп заполнен атрибут gidNumber (для POSIX-совместимости) - без него SSSD не сможет сопоставить LDAP-группу с локальной группой Unix.

Интеграция Linux с LDAP: синхронизация групп и пользователей

SSSD (System Security Services Daemon) - основной инструмент для подключения Linux к LDAP. Он кэширует учётные данные, поддерживает офлайн-аутентификацию и корректно обрабатывает вложенные группы. Установите пакеты sssd, sssd-tools, libnss-sss и libpam-sss на Debian/Ubuntu или sssd и sssd-client на RHEL/Rocky Linux.

После установки настройте /etc/nsswitch.conf, чтобы система искала пользователей и группы через sss:

passwd: files sss
group:  files sss
shadow: files sss

Маппинг групп LDAP на локальные группы Unix работает через атрибуты GID. SSSD получает gidNumber из LDAP-записи группы и создаёт соответствующую локальную группу. Пользователи, состоящие в LDAP-группе, автоматически становятся членами этой локальной группы. Проверьте результат командами id username и getent group linux-sudoers.

Настройка SSSD для Active Directory

Для подключения к домену AD сначала введите хост в домен командой realm join domain.local -U Administrator. Затем настройте /etc/sssd/sssd.conf:

[sssd]
domains = domain.local
services = nss, pam

[domain/domain.local]
default_shell = /bin/bash
ad_server = dc.domain.local
ad_domain = domain.local
id_provider = ad
access_provider = ad
# Фильтр: обрабатываем только группы с префиксом linux-
ad_group_search_base = OU=Groups,DC=domain,DC=local
ldap_group_search_filter = (&(objectClass=group)(cn=linux-*))
# Маппинг UID/GID из AD
ldap_id_mapping = True
use_fully_qualified_names = False
# Кэширование для офлайн-доступа
cache_credentials = True
enumerate = False

Параметр ldap_group_search_filter ограничивает видимые группы только теми, что начинаются с linux-. Это снижает нагрузку на контроллер домена и ускоряет вход в систему. После изменения конфигурации перезапустите SSSD: systemctl restart sssd.

Настройка SSSD для OpenLDAP

Для OpenLDAP провайдер - ldap, а не ad. Конфигурация требует явного указания базового DN и фильтров:

[sssd]
domains = ldap.local
services = nss, pam

[domain/ldap.local]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldaps://ldap.local
ldap_search_base = dc=ldap,dc=local
ldap_user_search_base = ou=Users,dc=ldap,dc=local
ldap_group_search_base = ou=Groups,dc=ldap,dc=local
ldap_user_object_class = posixAccount
ldap_group_object_class = posixGroup
ldap_user_name = uid
ldap_group_name = cn
ldap_id_use_start_tls = True
ldap_tls_reqcert = demand
cache_credentials = True
enumerate = False

Ключевое отличие от AD: в OpenLDAP вы сами управляете схемой и должны убедиться, что у пользователей заполнены uidNumber и gidNumber, а у групп - gidNumber и memberUid. Без этих атрибутов SSSD не сможет построить корректный маппинг. При проблемах с аутентификацией используйте шпаргалку по диагностике LDAP - там собраны готовые команды для быстрого поиска ошибок.

Делегирование sudo-прав через группы LDAP

Файл /etc/sudoers не редактируют напрямую. Правила добавляют в отдельные файлы в /etc/sudoers.d/. Префикс % указывает, что правило применяется к группе, а не к пользователю. Синтаксис:

%группа  ALL=(ALL:ALL) КОМАНДЫ

SSSD передаёт членство в LDAP-группах в PAM-стек, поэтому sudo корректно распознаёт группы из каталога. Проверьте, что в /etc/nsswitch.conf строка sudoers содержит sss: sudoers: files sss. Без этого sudo будет игнорировать группы LDAP.

Тестируйте правила командой sudo -l от имени пользователя. Если правило не применяется, проверьте: состоит ли пользователь в группе (id username), очищен ли кэш SSSD (sss_cache -E), корректно ли указано имя группы в sudoers (регистр важен).

Примеры правил sudoers для типовых ролей

Полный доступ для администраторов - группа linux-sudoers:

%linux-sudoers ALL=(ALL:ALL) ALL

Управление только сервисами - группа linux-www-admins может перезапускать Nginx и Apache, читать логи:

%linux-www-admins ALL=(ALL) /usr/bin/systemctl restart nginx, /usr/bin/systemctl restart apache2, /usr/bin/journalctl -u nginx*, /usr/bin/journalctl -u apache2*

Управление пакетами без полного root-доступа - группа linux-operators:

%linux-operators ALL=(ALL) /usr/bin/apt update, /usr/bin/apt upgrade, /usr/bin/yum update

Просмотр логов без права изменять систему - группа linux-auditors:

%linux-auditors ALL=(ALL) /usr/bin/journalctl, /usr/bin/cat /var/log/*, /usr/bin/tail /var/log/*

Комбинируйте группы: пользователь может состоять и в linux-www-admins, и в linux-auditors - тогда он получит объединение разрешений. Это позволяет гибко собирать набор прав под конкретную должность.

Управление доступом к файловым ресурсам: SMB и NFS на TrueNAS

TrueNAS поддерживает прямое подключение к LDAP-каталогу для аутентификации пользователей и разрешения ACL на основе групп. Подробное руководство по настройке доступа через группы AD содержит готовые схемы ACL для разных типов данных. После интеграции группы LDAP появляются в выпадающих списках при редактировании разрешений, и вы назначаете права так же, как локальным группам.

Для NFS-экспортов схема аналогична: в настройках экспорта указываете сеть и группы LDAP, которым разрешён доступ. TrueNAS сопоставляет UID/GID из LDAP с правами на файловой системе ZFS. Важно, чтобы у пользователей LDAP были заполнены POSIX-атрибуты (uidNumber, gidNumber), иначе NFS не сможет корректно определить владельца.

Настройка LDAP-клиента в TrueNAS

В веб-интерфейсе TrueNAS перейдите в раздел Directory Services → LDAP. Заполните поля:

• Hostname: полное доменное имя LDAP-сервера (ldaps://ldap.domain.local)
• Base DN: корень поиска (dc=domain,dc=local)
• Bind DN: учётная запись для подключения (cn=binduser,dc=domain,dc=local)
• Bind Password: пароль bind-пользователя
• User Base DN: OU с пользователями
• Group Base DN: OU с группами

Нажмите Save и дождитесь статуса Healthy. Если статус Faulted, проверьте сетевое соединение с LDAP-сервером и корректность Bind DN. TrueNAS использует библиотеку nss_ldap, которая чувствительна к TLS-сертификатам - при использовании самоподписанных сертификатов импортируйте CA-сертификат в разделе System → Certificates.

Назначение прав на SMB-шару через группы LDAP

Создайте SMB-шару в разделе Sharing → SMB. После создания откройте редактирование ACL для файловой системы шар. В редакторе ACL нажмите Add ACL Item, выберите Group и введите имя группы LDAP (например, truenas-smb-admins). Назначьте права: Read, Write, Execute. Для группы truenas-smb-readers установите только Read и Execute.

Права применяются немедленно. Проверьте: подключитесь к шаре от имени пользователя, состоящего в truenas-smb-readers, и попробуйте создать файл. Операция должна быть отклонена. Руководство по делегированию прав в TrueNAS описывает расширенные сценарии совместной работы и помогает выстроить масштабируемую структуру разрешений для IT-команды.

Интеграция Kubernetes RBAC с группами LDAP

Kubernetes не поддерживает LDAP напрямую. Для интеграции используется внешний OIDC-провайдер, который аутентифицирует пользователей через LDAP и передаёт их группы в id_token. Kubernetes извлекает группы из поля groups токена и использует их в RBAC-привязках.

Dex - лёгкий OIDC-провайдер с встроенным LDAP-коннектором. Keycloak - более тяжёлый, но предоставляет веб-интерфейс для управления. Выбор зависит от масштаба: Dex подходит для небольших и средних кластеров, Keycloak - для корпоративных инсталляций с требованиями к SSO.

После настройки OIDC-провайдера администратор создаёт ClusterRoleBinding, где в subjects указывает группу из LDAP. Пользователь аутентифицируется через kubectl oidc-login или веб-интерфейс, получает токен с группами, и Kubernetes применяет RBAC-правила на основе этих групп. Различия моделей аутентификации и авторизации разобраны в отдельном материале с практическими схемами интеграции.

Настройка Dex для аутентификации через LDAP

Установите Dex через Helm-чарт или из манифестов. Пример конфигурации коннектора LDAP в values.yaml:

connectors:
- type: ldap
  id: ldap
  name: LDAP
  config:
    host: ldap.domain.local:636
    insecureNoSSL: false
    insecureSkipVerify: false
    bindDN: cn=dexbind,dc=domain,dc=local
    bindPW: secretpassword
    userSearch:
      baseDN: ou=Users,dc=domain,dc=local
      filter: "(objectClass=posixAccount)"
      username: uid
      idAttr: uid
      emailAttr: mail
      nameAttr: cn
    groupSearch:
      baseDN: ou=Groups,dc=domain,dc=local
      filter: "(objectClass=posixGroup)"
      userMatchers:
      - userAttr: uid
        groupAttr: memberUid
      nameAttr: cn

Dex выполняет поиск пользователя по uid, затем ищет группы, где memberUid совпадает с uid пользователя. Найденные группы попадают в поле groups id_token-а. Kubernetes API-сервер настраивается на приём токенов от Dex через флаг --oidc-issuer-url.

Создание RBAC-привязок для групп LDAP в Kubernetes

ClusterRoleBinding связывает группу LDAP с ClusterRole. Пример для группы k8s-cluster-admins:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ldap-cluster-admins
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: k8s-cluster-admins

Для группы k8s-developers создайте RoleBinding в конкретном namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ldap-developers
  namespace: development
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: edit
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: k8s-developers

Проверьте доступ: выполните kubectl auth can-i create pods --as=username от имени пользователя из группы k8s-developers. Если ответ yes - привязка работает. Если no - проверьте, что Dex передаёт группы в токене и что имена групп в ClusterRoleBinding совпадают с именами в LDAP с учётом регистра.

Типичные проблемы и их решение

Проблема: неверный маппинг групп. Симптом - пользователь состоит в группе LDAP, но id username не показывает эту группу. Причина: расхождение регистра (группа в LDAP называется Linux-Sudoers, а в sudoers указана linux-sudoers) или пробелы в имени группы. Решение: используйте команду getent group для проверки точного имени, которое видит система, и копируйте его в конфигурации.

Проблема: задержки обновления членства в группах. Симптом - пользователя добавили в группу LDAP, но sudo -l не показывает новых прав даже через 10 минут. Причина: кэширование SSSD. По умолчанию SSSD кэширует членство в группах на entry_cache_group_timeout (обычно 5400 секунд). Решение: очистите кэш командой sss_cache -E или уменьшите таймаут в sssd.conf: entry_cache_group_timeout = 300.

Проблема: ошибки TLS при подключении к LDAPS. Симптом - в логах SSSD сообщения о недоверенном сертификате. Причина: самоподписанный сертификат на LDAP-сервере не добавлен в доверенные на клиенте. Решение: скопируйте CA-сертификат в /etc/ssl/certs/ и выполните update-ca-certificates, либо укажите путь к сертификату в sssd.conf через ldap_tls_cacert.

Проблема: таймауты LDAP при большом количестве групп. Симптом - вход в систему занимает 30-60 секунд. Причина: SSSD рекурсивно обходит все группы пользователя, включая вложенные. Решение: ограничьте глубину обхода параметром ldap_group_nesting_level = 2 и используйте фильтры групп, чтобы исключить ненужные.

Диагностика проблем с SSSD и LDAP

Основные команды для диагностики:

• sssctl domain-status domain.local - статус домена, состояние подключения к LDAP-серверу
• sss_cache -E - полная очистка кэша, применяется после изменения членства в группах
• journalctl -u sssd -f - просмотр логов SSSD в реальном времени

Типичные ошибки в логах: "Authentication failed for user" - неверный пароль или пользователь не найден в LDAP; "TLS error" - проблема с сертификатом; "Connection timed out" - недоступен LDAP-сервер, проверьте сеть и firewall. Шпаргалка по диагностике LDAP содержит готовые команды ldapwhoami и tcpdump для быстрого поиска причин сбоев.

Заключение: единая система доступа на основе групп LDAP

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

Для дальнейшего усиления безопасности настройте аудит sudo через auditd - это даст журнал всех выполненных команд с привязкой к пользователю LDAP. Интегрируйте логи SSSD и sudo с централизованной системой мониторинга для оповещений о подозрительной активности. Автоматизируйте настройку клиентов через Ansible: плейбук, который устанавливает SSSD, копирует sssd.conf и правила sudoers, сокращает развёртывание нового сервера до минут. Руководство по аудиту политик доступа поможет выявить избыточные права и поддерживать инфраструктуру в безопасном состоянии.