Установка базового кластера с LDAP

Назначение и ограничения

В этой инструкции используются пользователи внешнего каталога Active Directory или LDAP вместо локальных пользователей. Инструкция дополняет сценарий установки базового кластера и описывает только отличия от него.

Топология, неймспейсы, PostgreSQL, Ingress и ZDS остаются без изменений. Используйте существующий LDAP: его установка в этот сценарий не входит.

Перед началом убедитесь, что:

• контроллер домена доступен из Pod Закрома.Хранение по LDAP или LDAPS;
• подготовлена служебная учётная запись (bind-пользователь) с правом чтения пользователей и групп;
• в каталоге существует группа, разрешающая доступ к Закрома.Хранение, и пользователь для роли первого администратора;
• при использовании LDAPS контейнер Gateway доверяет цепочке сертификата контроллера домена. Доверие на рабочем месте администратора не заменяет доверие внутри контейнера.

Настройка LDAP

Выполните шаги 1–4 базовой инструкции. Сохраните параметры PostgreSQL, доменов, Ingress, лицензии и собственную ключевую пару JWT Gateway.

В настроенном файле storage/values-storage.yaml измените параметры существующего блока global.config:

• в default_admin.login укажите пользователя каталога, который станет первым администратором;
• для adminUi.authType оставьте password;
• в auth.auth_provider и auth.user_provider укажите ldap;
• очистите список локальных пользователей, задав auth.file.list: [];
• в auth.ldap задайте параметры подключения, пароль bind-пользователя и настройки поиска.

Ниже приведены параметры, которые нужно изменить в global.config. Остальные настройки оставьте без изменений.

Copy
1global:
2  config:
3    default_admin:
4      login: "zakromaadmin"
5    adminUi:
6      authType: "password"
7    auth:
8      auth_provider: "ldap"
9      user_provider: "ldap"
10      file:
11        list: []
12      ldap:
13        user_group: "clouduser"
14        url: "ldaps://dc1.example.internal:636"
15        bind_dn: "CN=svc-zakroma,CN=Users,DC=example,DC=internal"
16        bind_password: "<LDAP_BIND_PASSWORD>"
17        user_filter: "objectCategory=person"
18        group_filter: "objectClass=group"
19        group_name_attribute: "cn"
20        group_search_dn: "OU=Groups,DC=example,DC=internal"
21        user_name_attribute: "sAMAccountName"
22        user_search_dn: "CN=Users,DC=example,DC=internal"
23        user_firstname_attribute: "givenName"
24        user_lastname_attribute: "sn"
25        user_email_attribute: "mail"
26        membership_attribute_name: "member"
27        membership_attribute_type: "dn"
28        memberof_attribute_name: "member"
29        memberof_attribute_type: ""

Пример рассчитан на Active Directory, в которой пользователи идентифицируются атрибутом sAMAccountName, а членство хранится в атрибуте member группы. Замените имена, DN и фильтры в соответствии со схемой своего каталога.

Защита чувствительных данных

Пароль bind_password хранится в storage/values-storage.yaml открытым текстом. Ограничьте доступ к файлу, параметрам Helm-релиза и ConfigMap по рекомендациям базовой инструкции.

Настройка доверия к сертификату LDAP

Если сертификат LDAP подписан внутренним CA, подготовьте files/ca-certificates.crt. Сохраните в файле полный набор доверенных CA контейнера и добавьте цепочку LDAP. Не оставляйте только внутренний CA, если Gateway также обращается к сервисам с публичными сертификатами.

На рабочем месте администратора создайте ConfigMap с подготовленным файлом:

Copy
1kubectl -n zakroma-storage create configmap ca-certificates \
2  --from-file=ca-certificates.crt=files/ca-certificates.crt

В том же файле storage/values-storage.yaml добавьте CA в списки volumes и volumeMounts блока zakroma-storage-gateway. Ниже приведены полные списки для базового примера с лицензией. Остальные параметры Gateway, включая config.jwt и service, сохраните без изменений:

Copy
1zakroma-storage-gateway:
2  volumes:
3    - name: licence
4      secret:
5        secretName: licence
6    - name: ca-certificates
7      configMap:
8        name: ca-certificates
9  volumeMounts:
10    - name: licence
11      mountPath: /opt/application/licence
12      subPath: licence
13      readOnly: true
14    - name: ca-certificates
15      mountPath: /etc/ssl/certs/ca-certificates.crt
16      subPath: ca-certificates.crt
17      readOnly: true

Сохранение монтирований

Helm заменяет списки volumes и volumeMounts целиком. Сохраните лицензию и включите в эти списки другие монтирования из базовой конфигурации, например для PostgreSQL.

Если все необходимые CA уже присутствуют в образе, ConfigMap и монтирование CA не требуются. После изменения ConfigMap, смонтированного через subPath, пересоздайте Pod для обновления файла. Автоматическое обновление доверенных CA в этом случае не выполняется.

Продолжение установки по базовой инструкции

Продолжите установку с шага 5 базовой инструкции: настройте ZDS и выполните последующие шаги. В командах Helm для Закрома.Хранение используйте storage/values-storage.yaml с подготовленными настройками LDAP.

Проверьте конфигурацию:

Copy
1helm lint charts/zakroma-storage-6.0.4.tgz \
2  -f storage/values-storage.yaml

Ожидаемый результат — helm lint завершается без ошибок.

Выполните helm template из шага 6 без изменения команды: она использует тот же файл. Сохраните вывод манифестов во временный каталог с ограниченным доступом, как в базовой инструкции.

Для установки на шаге 9 и повторного Helm upgrade используйте:

Copy
1helm upgrade --install zakroma-storage charts/zakroma-storage-6.0.4.tgz -n zakroma-storage \
2  -f storage/values-storage.yaml \
3  --wait --timeout 10m

Файл zds/values-zds.yaml и команды релиза ZDS оставьте без изменений. Файл storage/values-storage.yaml передавайте только релизу Закрома.Хранение. В этом сценарии используется LDAP; настройки Keycloak не применяйте. При повторном запуске сохраните настройки LDAP и собственные ключи JWT.

Проверка после установки

Выполните проверки готовности и функциональную проверку S3 из базовой инструкции. Затем проверьте авторизацию через LDAP:

1. Войдите в Admin UI пользователем default_admin с паролем из каталога.
2. Убедитесь, что синхронизированы пользователи разрешающей группы, соответствующие фильтрам.
3. Проверьте отказ при входе тестового пользователя, не входящего в разрешающую группу.
4. После повторного upgrade проверьте сохранение LDAP-авторизации и смонтированной лицензии.

При ошибке проверьте журналы Gateway командой kubectl -n zakroma-storage logs deployment/zakroma-storage-gateway. Перед передачей журнала в техническую поддержку удалите чувствительные данные. Подробности приведены в инструкции по получению журналов приложения.