Учетные записи и секреты платформы в Kubernetes

Учетные записи и секреты платформы в Kubernetes#

При развертывании в кластере Kubernetes (Operator) секреты учетных записей платформы задаются объектами Kubernetes Secret, на которые ссылается ресурс Custom Resource AstraAutomation; оператор сверяет их с состоянием платформы. Состав и подготовка этих секретов при установке описаны в разделе Подготовка секретов. Ниже приведен перечень учетных записей и секретов платформы и порядок их смены на работающей установке.

Порядок управления секретами отличается от развертывания из Deb-пакетов на ВМ (там секреты задаются в inventory, а изменения применяются запуском aa-setup). Общие требования к хранению секретов описаны в разделе Управление учетными данными и секретами.

Перечень учетных записей и секретов#

Учетная запись / секрет

Назначение

Где задается (поле CR → Secret, ключ)

Инструмент для смены

Доменные УЗ

Пароль администратора веб-интерфейса (admin, вход в платформу через Platform Gateway)

Вход администратора в веб-интерфейс платформы

admin_password_secret → Secret, ключ password (см. Секрет для доступа к Platform Gateway)

CLI компонента (см. Особые случаи)

Да

Роли PostgreSQL (по компонентам)

Сервисное подключение компонентов к базе данных

database_secret → Secret (пароль роли — ключ password; полный состав — Секреты для доступа к базам данных)

Объект Secret

Нет

Ключи объектного хранилища S3

Доступ Automation Hub к объектному хранилищу артефактов

object_storage_s3_secret → Secret (ключи s3-access-key-id / s3-secret-access-key; полный состав — Секрет для доступа к хранилищу S3)

Объект Secret

—

Для входа администраторов в веб-интерфейс Astra Automation поддерживает внешнюю аутентификацию через провайдеров идентификации (LDAP, SAML, OIDC и др.) — доменные учетные записи можно использовать наравне со встроенной admin (см. Методы аутентификации). Сервисные роли PostgreSQL и ключи S3 — внутренние и внешнюю аутентификацию не используют.

Смена секретов#

Конфигурацию подов формирует оператор по данным из Kubernetes Secret и ресурса AstraAutomation, поэтому секреты изменяют через соответствующий объект Secret, а не правкой конфигурации внутри подов.

Порядок смены секрета:

  1. Обновите значение в соответствующем Kubernetes Secret, например:

    kubectl -n astra-automation create secret generic <name> ... --dry-run=client -o yaml | kubectl apply -f -

  2. Дождитесь, пока оператор обнаружит изменения в ресурсе AstraAutomation (или, если требуется указать другой объект Secret, измените сам ресурс).

  3. При необходимости перезапустите поды соответствующего компонента, чтобы новое значение было считано, например:

    kubectl -n astra-automation rollout restart deployment/<CR_name>-gateway

  4. Проверьте результат: вход в веб-интерфейс, состояние подов (kubectl get pods), подключение к базе данных.

Формат каждого Secret приведен в разделе Подготовка секретов.

Особые случаи#

Пароль администратора. Оператор создает учетную запись администратора только если она отсутствует, поэтому изменение admin_password_secret не меняет пароль уже существующего администратора. Для смены пароля действующего администратора выполните команду в контейнере api соответствующего пода:

kubectl -n astra-automation exec deploy/<CR_name>-gateway -c api -- aap-gateway-manage update_password --username admin --password <new_password>

Роли PostgreSQL: встроенная и внешняя СУБД. Тип СУБД определяется ключом type в объекте Secret базы данных (database_secret) — аналогично параметру config_dynamic_database при развертывании на виртуальных серверах:

  • type: managed — встроенная СУБД: PostgreSQL разворачивается и обслуживается оператором в кластере, объект Secret с параметрами подключения создается автоматически.

  • type: unmanaged — внешняя СУБД: подключение к внешнему серверу PostgreSQL, которым вы управляете самостоятельно. Для смены пароля роли измените его на сервере базы данных (ALTER ROLE <role> WITH PASSWORD '<new_password>';), затем обновите ключ password в объекте Secret этой роли (database_secret).