Обновление секретов¶

В продукте поддерживается обновление секретов без переустановки: ротация паролей учётных записей LDAP и SMTP, паролей компонентов LCM, а также паролей и секретов сервисов OpenStack.

Ротация учётных записей LDAP¶

Ротация паролей для компонентов LCM (GitLab, NetBox)¶

Поддерживаются два варианта настройки учётных записей LDAP для компонентов LCM: одна общая ТУЗ для GitLab и NetBox или две пары технических учётных записей (ТУЗ) с автоматической ротацией.

Использование одной учётной записи

GitLab и NetBox используют одну ТУЗ с фиксированным паролем. Пароль хранится в Kubernetes-секрете и обновляется вручную.

Для обновления пароля выполните следующие действия:

Обновите пароль учётной записи в Active Directory.

Обновите Kubernetes-секреты:

$ kubectl create -n lcm-gitlab secret generic gitlab-ldap \
    --from-literal=ldap_bind_password='<новый пароль>' \
    --from-literal=bind_dn='<DN учётной записи>' \
    --dry-run=client -o yaml | kubectl apply -f -

$ kubectl create -n lcm-netbox secret generic netbox-ldap \
    --from-literal=ldap_bind_password='<новый пароль>' \
    --from-literal=ldap_bind_dn='<DN учётной записи>' \
    --dry-run=client -o yaml | kubectl apply -f -

Перезапустите поды, чтобы изменения вступили в силу:

$ kubectl rollout restart deployment -n lcm-gitlab
$ kubectl rollout restart deployment -n lcm-netbox

Использование двух пар учётных записей с ротацией

Пароли ТУЗ, с которыми GitLab и NetBox подключаются к Active Directory, можно ротировать автоматически. Ротация выполняется через Vault LDAP Secrets Engine: на каждое приложение заводятся две static-роли, ротируется неактивная, после чего приложение переключается на неё. Функция работает только с внешним Vault (install_vault: false).

Предупреждение

Все операции включения и выключения ротации выполняются командой helmfile sync, а не helmfile apply. При helmfile apply изменения применяются только если helm-релиз изменился — если релиз не изменился, ресурсы ротации не создадутся и не удалятся.

Предварительные требования:

Должен быть подключен внешний Vault (в lcm-config.yaml значение параметра install_vault должно быть установлено как false).

В Vault должен быть настроен LDAP Secrets Engine с двумя static-ролями на каждое приложение — см. документацию HashiCorp Vault.
Должен быть создан Kubernetes-секрет cert-manager/vault-approle с ключом secret-id. При vault_pki_enabled: true создаётся автоматически; при другом значении создайте его вручную:
$ kubectl create secret generic vault-approle \
    --from-literal=secret-id=<secret-id> -n cert-manager
Параметр ldap_enable в lcm-config.yaml должен быть установлен в значение true.

Поддерживается работа с двумя хранилищами секретов: Vault OSS и SecMan. Выбор задаётся параметром vault_secman в lcm-config.yaml. Различаются только путь запроса учётных данных и поле пароля в ответе:

Vault OSS (vault_secman: false) — путь запроса static-cred/<role>, поле пароля password.

SecMan (vault_secman: true) — путь запроса creds/<role>, поле пароля current_password.

Логика ротации в обоих случаях остаётся одинаковой.

Пример ответа при запросе учётных данных роли:

# Vault OSS — endpoint static-cred/<role>
{ "username": "gitlab-ldap-1", "password": "…", "ttl": 3555 }

# SecMan — endpoint creds/<role>
{ "username": "gitlab-ldap-1", "current_password": "…", "last_password": "…", "ttl": 3555 }

Предупреждение

При использовании SecMan убедитесь, что параметр vault_secman установлен в значение true. Если оставить значение false, поле пароля придёт пустым и каждый запуск CronJob будет завершаться с ошибкой.

Для того чтобы включить автоматическую ротацию, выполните следующие действия:

Настройте параметры ротации в lcm-config.yaml:

enable_lcm_ad_passwords_rotation: true
lcm_exp_threshold_days: 30                                           # ротировать, если до истечения TTL роли осталось меньше N дней
lcm_pass_rotation_job_sch: "0 7 * * *"                               # расписание CronJob (ежедневно в 07:00)
vault_secman: false                                                  # true — SecMan, false — Vault OSS
vault_ldap: "ldap"                                                   # mount-путь LDAP Secrets Engine
ldap_gitlab_bind_dn: "CN=gitlab-ldap-1,CN=Users,DC=example,DC=com"
ldap_netbox_bind_dn: "CN=netbox-ldap-1,CN=Users,DC=example,DC=com"

Если имена ролей в Vault не следуют паттерну <mask>-1 / <mask>-2, задайте их явно:

lcm_gitlab_ldap_role_a: "gitlab-ldap-1"
lcm_gitlab_ldap_role_b: "gitlab-ldap-2"
lcm_netbox_ldap_role_a: "netbox-ldap-1"
lcm_netbox_ldap_role_b: "netbox-ldap-2"

Полный список параметров — см. Автоматическая ротация паролей LDAP (опционально).

Примените конфигурацию:
```
$ helmfile -e multi-node sync -l namespace=lcm-gitlab
$ helmfile -e multi-node sync -l namespace=lcm-netbox
```
При применении конфигурации будут созданы CronJob ldap-rotation, RBAC, NetworkPolicy, а Secret приложения будет синхронизирован с паролем активной роли.

Убедитесь, что CronJob создан:

$ kubectl get cronjob ldap-rotation -n lcm-gitlab
$ kubectl get cronjob ldap-rotation -n lcm-netbox

При применении конфигурации активная роль определяется по значению bind_dn в Secret приложения: из него извлекается CN и сравнивается с именами роли A и роли B. Если совпадение найдено, используется соответствующая роль и её пароль. Если bind_dn не совпадает ни с одной ролью — например, при первом включении ротации — выбирается роль A, а bind_dn формируется заново из ldap_<app>_bind_dn. Поды приложения перезапускаются только в том случае, если Secret изменился.

Для того чтобы выключить ротацию, выполните следующие действия:

Определите активный аккаунт:

$ kubectl get secret gitlab-ldap -n lcm-gitlab \
    -o jsonpath='{.data.bind_dn}' | base64 -d

$ kubectl get secret netbox-ldap -n lcm-netbox \
    -o jsonpath='{.data.ldap_bind_dn}' | base64 -d

Скопируйте полученный DN в ldap_bind_dn и выключите ротацию:

ldap_bind_dn: "CN=gitlab-ldap-1,CN=Users,DC=example,DC=com"
enable_lcm_ad_passwords_rotation: false

Примените конфигурацию:
```
$ helmfile -e multi-node sync -l namespace=lcm-gitlab
$ helmfile -e multi-node sync -l namespace=lcm-netbox
```
При применении конфигурации все ресурсы ротации будут удалены — CronJob, RBAC, NetworkPolicy.

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

$ kubectl get all,cronjob,netpol -n lcm-netbox \
    | grep -iE 'rotation|egress-vault'

Вывод должен быть пустым.

Если в работе ротации возникают ошибки, изучите логи последних запусков CronJob:

$ kubectl get jobs -n lcm-gitlab | grep ldap-rotation
$ kubectl logs -n lcm-gitlab job/<ldap-rotation-XXXXXXXX>

Ниже приведена таблица с наиболее частыми ошибками и путями их решения:

Ошибка	Причина	Решение
Ресурсы ротации не удалились после выключения	`helmfile apply` не обнаружил изменений — конфигурация не применилась	Выполнить `helmfile sync`
GitLab выдаёт ошибку аутентификации после включения	`bind_dn` в Secret не соответствует паролю активной роли	Проверить `ldap_<app>_bind_dn`; при следующем `sync` `bind_dn` будет пересобран
CronJob завершается с ошибкой при каждом запуске	Неверный путь запроса или поле пароля для SecMan	Проверить `vault_secman` и `vault_ldap_static_endpoint`
Ошибка вида «ротация не поддерживается при install_vault=true»	Включён встроенный Vault	Перейти на внешний Vault (`install_vault: false`)

Ротация паролей для компонентов региона (Keystone, SMTP)¶

Для сервисов региона поддерживаются два варианта настройки учётных записей LDAP: одна общая ТУЗ для Keystone и Alertmanager; две пары ТУЗ с ротацией.

Использование одной учётной записи

Keystone и Alertmanager используют одну ТУЗ с фиксированным паролем. Пароль хранится в файле паролей региона в Vault и обновляется вручную.

Для обновления пароля выполните следующие действия:

Зайдите в Vault в файл паролей региона secret_v2 / deployments / <LCM FQDN> / <имя региона> / passwords_yml и обновите значения параметров:
- ldap_password — новый пароль ТУЗ для Keystone;
- smtp_password — новый пароль ТУЗ для Alertmanager.
Сохраните изменения для новой версии.
Запустите пайплайн развёртывания:
1. Откройте веб-интерфейс развёрнутого GitLab.
2. Перейдите в репозиторий project_k / deployments / <имя региона>.
3. Создайте новый пайплайн: Build > Pipelines > New Pipeline.
4. В открывшемся окне добавьте переменную KOLLA_ARGS со значением -t keystone,prometheus --limit prometheus-alertmanager.
5. Запустите пайплайн New pipeline.
6. Запустите задачу deploy в созданном пайплайне.
7. Дождитесь завершения выполнения задачи.

Использование двух пар учётных записей с ротацией

Для сервисов региона поддерживается автоматическая ротация паролей ТУЗ: LDAP-аккаунта для аутентификации в Keystone и SMTP-аккаунта для почтовых уведомлений Alertmanager. Ротация выполняется через Vault LDAP Secrets Engine. Расписание запуска ротации настраивается через Pipeline Schedules.

Важно

Для ротации LDAP требуются две ТУЗ: одна для сервисов LCM (GitLab, NetBox) и отдельная для Keystone. Это должны быть разные учётные записи.

Предварительные требования:

Пользователь Active Directory, используемый в Vault LDAP Secrets Engine, должен иметь права, достаточные для ротации паролей ТУЗ в Active Directory.

В HashiCorp Vault должен быть включён и настроен Secrets Engine ldap с созданными парами ролей для каждого настраиваемого сервиса — для настройки см. документацию HashiCorp Vault.

Для ротации LDAP: должна быть настроена интеграция с каталогами LDAP и ролевая модель — см. Включение ролевой модели в KeyStack.

Для ротации SMTP: должен быть настроен шаблон почтового уведомления об алертах.

Для настройки ротации выполните следующие действия:

Зайдите в Vault в файл паролей региона secret_v2 / deployments / <LCM FQDN> / <имя региона> / passwords_yml и обновите значения параметров:
- для ротации LDAP:
  - ldap_user — пользователь из LDAP для настройки ролевой модели в формате ldap-ro;
  - ldap_password — пароль для пользователя ldap_user;
- для ротации SMTP:
  - smtp_user — пользователь из LDAP для шаблона почтового уведомления об алертах;
  - smtp_password — пароль для пользователя smtp_user.
Сохраните изменения для новой версии.
Откройте веб-интерфейс развёрнутого GitLab и перейдите в репозиторий project_k / deployments / <имя региона>.
Перейдите в конфигурационный файл региона (по умолчанию это globals.d/REGION.yml) и добавьте параметры:
```
ldap_roles:                                     # для ротации LDAP
  - <название первой роли в Vault ldap>
  - <название второй роли в Vault ldap>
smtp_fqdn: "<доменное имя почтового сервера>"   # для ротации SMTP
smtp_roles:                                     # для ротации SMTP
  - <название первой роли в Vault ldap>
  - <название второй роли в Vault ldap>
```
где:
- ldap_roles — список из двух имён ролей в Vault LDAP Secrets Engine для ротации учётной записи Keystone;
- smtp_fqdn — доменное имя почтового сервера, используемое для поиска пользователей в Active Directory;
- smtp_roles — список из двух имён ролей в Vault LDAP Secrets Engine для ротации учётной записи Alertmanager.
Перейдите в раздел Settings > CI/CD > Variables и создайте переменную vault_ldap_mount со значением, указывающим на название Vault Secrets Engine ldap (например, ldap).

Также можно добавить опциональные переменные:
- EXP_THRESHOLD_DAYS — количество дней до окончания TTL роли, по умолчанию 30;
- EXP_THRESHOLD_SECONDS — количество секунд до окончания TTL роли, вычисляется автоматически как EXP_THRESHOLD_DAYS * 86400.
Запустите пайплайн, чтобы применить конфигурацию и выполнить первую ротацию:
1. Откройте веб-интерфейс развёрнутого GitLab.
2. Перейдите в репозиторий project_k / deployments / <имя региона>.
3. Создайте новый пайплайн: Build > Pipelines > New Pipeline.
4. В открывшемся окне добавьте переменную SCHEDULE_TASK со значением rotate-sa.
5. Запустите пайплайн New pipeline.
6. Запустите задачу deploy в созданном пайплайне.
7. Дождитесь завершения выполнения задачи.

Для настройки регулярного выполнения ротации по расписанию обратитесь к разделу Ротация сервисных аккаунтов.