Перейти к содержимому
ZentroZentroZentro

Zentro Identity — установка и эксплуатация

Zentro Identity — сервис единого входа (SSO): OIDC-провайдер для сайтов и панелей, MFA (TOTP, passkey), admin-API, проверка токенов для бэкендов (JWKS, gRPC mTLS). Этот комплект — готовая сборка для linux/amd64 и linux/arm64; способы запуска: Docker (run), Docker Compose, Docker Swarm, ВМ без Docker (systemd). Kubernetes — в одной из следующих версий.

Комплект один на всё: сервер Identity и, в папке portal/, панель администратора и личный кабинет той же версии. Сначала ставится сервер (эта страница), затем панель и кабинет — Установка панели и кабинета.

Скачать и проверить комплект

Заголовок раздела «Скачать и проверить комплект»

Комплект скачивается с сайта Zentro, раздел Скачать (https://zentro.su/download/), — без регистрации. Один архив подходит для серверов linux/amd64 и linux/arm64.

Окно терминала
VER=0.7.2
wget https://zentro.su/downloads/identity/$VER/zentro-identity-$VER.tar.gz
tar xzf zentro-identity-$VER.tar.gz && cd zentro-identity-$VER

Проверьте подпись Zentro до установки: так вы убедитесь, что архив выпущен Zentro и не изменён. Нужен OpenSSL 3 или новее.

Окно терминала
wget -qO zentro-release.pem https://zentro.su/downloads/identity/release-key.pem
openssl pkey -pubin -in zentro-release.pem -outform DER | tail -c 32 | sha256sum   # сверьте с отпечатком ниже


printf 'zentro-release-v1\n' | cat - SHA256SUMS > SHA256SUMS.msg
base64 -d < SHA256SUMS.sig > SHA256SUMS.bin
openssl pkeyutl -verify -pubin -inkey zentro-release.pem -rawin -in SHA256SUMS.msg -sigfile SHA256SUMS.bin
sha256sum -c SHA256SUMS        # все строки — OK

Ожидаемый результат: Signature Verified Successfully, затем OK у каждого файла.

Отпечаток ключа подписи Zentro:

6933 8056 d51c 8e6d 71f3 2135 2c32 c810 61b3 7b85 b095 a267 917c 38d3 dd7d 33e1

Сверьте его ещё с одним источником — страницей Скачать или письмом от Zentro. Если отпечаток не совпадает или проверка не прошла, не устанавливайте комплект и напишите нам. Дальше обновления проверяет сам скрипт upgrade.sh (ключ вшит в установленную версию) — см. Обновление и откат.

Состав

Заголовок раздела «Состав»
Путь Что
images/zentro-identity-<версия>-linux-<arch>.tar.gz Docker-образ (docker load), тег zentro-identity:<версия>
binaries/zentro-identity-<версия>-linux-<arch>.tar.gz бинарники + systemd-комплект для ВМ без Docker
deploy/prod/ Compose-файл, справочник переменных .env.example, nginx, Vault, роли БД, бэкапы
deploy/swarm/stack.yml Docker Swarm stack
deploy/vm/ systemd-юниты, env-шаблоны, identity-cli, install.sh (то же внутри binaries/…)
deploy/upgrade/ скрипты обновления и отката (upgrade.sh, rollback.sh)
portal/ панель администратора и личный кабинет (Docker Compose) — Установка панели и кабинета
integrations/ пошаговые инструкции подключения популярных систем
LICENSE.txt, THIRD_PARTY_NOTICES.txt условия использования Zentro и лицензии сторонних компонентов — см. Лицензия
SHA256SUMS, SHA256SUMS.sig, VERSION контрольные суммы всех файлов, подпись Zentro, версия комплекта

Образ: distroless (без shell), пользователь nonroot, бинарники /identity-server, /identity-worker, /identity-migrate; порты 8080 (HTTP), 9090 (gRPC mTLS); запись только в /data (том) и /tmp. Версия: docker run --rm zentro-identity:<версия> version · identity-server version.

Что нужно заранее

Заголовок раздела «Что нужно заранее»
Компонент Обязательно Зачем
PostgreSQL 16+ да всё состояние (схему создаёт identity-migrate up)
HashiCorp Vault да (прод) подпись JWT (Transit), ключи шифрования PII (KV), сертификаты gRPC (PKI). Без Vault — пилот или тест, ключи на диске сервера: Без Vault
TLS-прокси (nginx и т.п.) да HTTPS снаружи; сервис слушает HTTP. Готовый конфиг — deploy/prod/nginx/identity.conf
SMTP желательно письма: подтверждение email, сброс пароля, коды
Redis для >1 инстанса общий кэш (отзыв токенов, rate-limit). Один инстанс — CACHE_BACKEND=memory

Общая подготовка (для всех способов)

Заголовок раздела «Общая подготовка (для всех способов)»
  1. Vault (оператор с админ-токеном, один раз): VAULT_ADDR=… VAULT_TOKEN=&lt;admin&gt; SPIFFE_TRUST_DOMAIN=example.com OUT=./secrets deploy/prod/vault/setup.sh — ключи подписи, ключи PII (бэкап Vault обязателен: их потеря = потеря данных), PKI, политика, AppRole. Пишет secrets/vault_role_id (→ VAULT_ROLE_ID) и secrets/vault_secret_id.
  2. База: создайте БД identity и роль-владельца (identity). После первого identity-migrate up и до запуска сервера выполните psql … -v owner=identity -v server_password="$(cat secrets/db_password_server)" -f deploy/prod/db/roles.sql — это логин identity_app_login для сервера (аудит нельзя изменить/удалить из приложения). Без него сервер не запустится (password authentication failed for user "identity_app_login").
  3. Секреты — отдельными файлами: db_password_owner, db_password_server, vault_secret_id, oidc_pairwise_secret (openssl rand -base64 32, не менять после запуска), smtp_password (пустой — если почта без авторизации; vault_secret_id пустой — без Vault). Любая переменная-секрет задаётся как K или файлом K_FILE (не оба). Права (Docker): сервер в контейнере работает от uid 65532 — файлы отдайте ему, чтение оставьте своей группе: sudo chown -R 65532:"$(id -g)" secrets && sudo chmod 750 secrets && sudo chmod 640 secrets/* (с chmod 600 от своего пользователя сервер не стартует: permission denied). Пароль — без перевода строки в конце: printf '%s' '…' > secrets/db_password_owner (не echo).
  4. Переменные — deploy/prod/.env.example (справочник всех переменных с пояснениями). Обязательные помечены [обяз.]; при ENV=prod сервис проверяет конфигурацию на старте и не запустится, перечислив все ошибки (https-адреса, домен passkey, креды Vault, пароли БД…).
  5. TLS-прокси: deploy/prod/nginx/identity.conf (домен, сертификаты). Прокси обязан перезаписывать X-Forwarded-For, а сервису нужен TRUSTED_PROXY_CIDRS = адрес прокси, как его видит сервис (иначе rate-limit, IP сессий и аудит увидят адрес прокси). /healthz и /metrics наружу не публикуются.

Без Vault (пилот, тест)

Заголовок раздела «Без Vault (пилот, тест)»

Шаг 1 (Vault) пропускается. В файл переменных (.env, для ВМ — /etc/zentro-identity/identity.env):

Окно терминала
SECRETS_BACKEND=local
ALLOW_LOCAL_SECRETS=true
PII_DET_KEY=…                       # ключ шифрования персональных данных: openssl rand -base64 32
LOCAL_KEYS_DIR=/data/localkeys      # Docker (Compose и Swarm задают его сами); ВМ — /var/lib/zentro-identity/keys
  • PII_DET_KEY не меняйте после первого запуска и сохраните вне сервера, как и каталог LOCAL_KEYS_DIR (ключи подписи токенов): без них бэкап базы не расшифровать. Файл с ключом — только владельцу (chmod 600); на ВМ ключ удобнее держать файлом: PII_DET_KEY_FILE=/etc/zentro-identity/secrets/pii_det_key.
  • Файл секрета vault_secret_id оставьте пустым, VAULT_ADDR/VAULT_ROLE_ID не нужны.
  • Ключ подписи токенов создаётся в LOCAL_KEYS_DIR при первом старте сервера (или bootstrap-admin).
  • Без Vault не работает gRPC (сертификаты mTLS выдаёт Vault); REST API и OIDC работают полностью.
  • Не хватает переменной — сервис при ENV=prod не запустится и назовёт её.

Первый запуск во всех способах: миграции → сервер + worker → первый администратор. Демо-пользователей нет. Первого администратора можно завести двумя способами:

  • В панели. Пока администратора нет, сервер при старте печатает в журнал код установки (docker compose logs app | grep -A2 "Код установки", на ВМ — journalctl -u zentro-identity-server). Откройте панель — она предложит «Первый запуск»: код, логин, почта, пароль. Код действует 24 часа; после 10 неверных вводов он сгорает, новый — identity-migrate setup-code. Как только администратор создан, экран закрывается. Выключить этот способ: SETUP_WEB=false в .env.
  • Из консоли: bootstrap-admin <email> — временный пароль печатается один раз, при первом входе его нужно сменить.

В обоих случаях затем подключите второй фактор (TOTP или passkey) — панель администратора без него не откроется.

A. Docker (run)

Заголовок раздела «A. Docker (run)»

Команды — для bash (переменные $COMMON/$OWNER раскрываются в несколько аргументов).

Окно терминала
docker load < images/zentro-identity-0.7.2-linux-amd64.tar.gz            # arm64-сервер — …-linux-arm64
cp deploy/prod/.env.example identity.env && $EDITOR identity.env          # заполнить (см. «Общая подготовка»)
mkdir -p secrets                                                          # файлы секретов, права — «Общая подготовка», п. 3
docker network create --subnet 172.30.240.0/24 identity
docker volume create identity-data
IMG=zentro-identity:0.7.2
COMMON="--network identity --env-file identity.env -v $PWD/secrets:/run/secrets:ro -v identity-data:/data
  --read-only --tmpfs /tmp --cap-drop ALL --security-opt no-new-privileges
  -e VAULT_SECRET_ID_FILE=/run/secrets/vault_secret_id -e OIDC_PAIRWISE_SECRET_FILE=/run/secrets/oidc_pairwise_secret"
OWNER="-e DB_USER=identity -e DB_PASSWORD_FILE=/run/secrets/db_password_owner"


docker run --rm $COMMON $OWNER --entrypoint /identity-migrate $IMG up                     # 1. схема
psql "host=… dbname=identity user=postgres" -v owner=identity \
  -v server_password="$(cat secrets/db_password_server)" -f deploy/prod/db/roles.sql      # 2. учётка сервера
docker run -d --name identity-app --restart unless-stopped $COMMON \
  -e DB_USER=identity_app_login -e DB_PASSWORD_FILE=/run/secrets/db_password_server \
  -e SMTP_PASSWORD_FILE=/run/secrets/smtp_password -e TRUSTED_PROXY_CIDRS=172.30.240.1/32 \
  -p 127.0.0.1:8080:8080 -p 10.0.0.5:9090:9090 $IMG                                         # 3. сервер (за nginx)
docker run -d --name identity-worker --restart unless-stopped $COMMON $OWNER \
  --entrypoint /identity-worker $IMG                                                       # 4. фоновые задачи
docker run --rm $COMMON $OWNER --entrypoint /identity-migrate $IMG bootstrap-admin admin@example.com

Здоровье: docker exec identity-app /identity-server healthcheck (код 0 = ok) или curl -s 127.0.0.1:8080/healthz с хоста. --health-cmd у docker run не подойдёт — он выполняется через /bin/sh, а в образе shell нет (в Compose и Swarm healthcheck задан в exec-форме и работает). В сам образ HEALTHCHECK не встроен: его унаследовали бы worker/migrate.

CLI администратора: docker run --rm $COMMON $OWNER --entrypoint /identity-migrate $IMG admin-list (admin-recover <email> [--reset-mfa], bootstrap-admin <email>, version) — или короче через контейнер worker: docker exec identity-worker /identity-migrate admin-list.

B. Docker Compose

Заголовок раздела «B. Docker Compose»

Готовый deploy/prod/docker-compose.yml: migrate (схема перед стартом) → app + worker, секреты через docker secrets, read-only FS, лимиты, healthcheck, закреплённая подсеть (для доверенного прокси).

Окно терминала
docker load < images/zentro-identity-0.7.2-linux-amd64.tar.gz
cd deploy/prod
cp .env.example .env && chmod 600 .env && $EDITOR .env   # IDENTITY_IMAGE=zentro-identity:0.7.2, адреса, домены, БД, Vault
mkdir -p secrets && …                          # файлы секретов (см. secrets: в docker-compose.yml), права — п. 3 выше
docker compose run --rm migrate                # 1. схема базы
psql "host=… dbname=identity user=postgres" -v owner=identity \
  -v server_password="$(cat secrets/db_password_server)" -f db/roles.sql   # 2. учётка сервера
docker compose up -d                           # 3. сервер и фоновые задачи
docker compose run --rm migrate bootstrap-admin admin@example.com

HTTP публикуется на 127.0.0.1:8080 для nginx на этом же хосте (HTTP_PUBLISH_PORT), gRPC — GRPC_PUBLISH (внутренний IP). Без nginx на хосте (прокси в другом месте) — поменяйте публикацию и TRUSTED_PROXY_CIDRS.

Прокси в Docker-сети

Заголовок раздела «Прокси в Docker-сети»

Если TLS-прокси (nginx, Traefik, Caddy) сам работает в контейнере, подключите Identity к его сети файлом docker-compose.override.yml рядом с docker-compose.yml. Compose читает его сам, а файлы комплекта остаются нетронутыми — обновление их заменяет.

services:
  migrate: { networks: [default, proxy] }     # если Postgres — контейнер в этой сети
  worker:  { networks: [default, proxy] }
  app:
    networks:
      default: {}
      proxy: { aliases: [zentro-identity] }   # адрес для прокси: zentro-identity:8080
    ports: !reset []                          # наружу — только через прокси (Compose 2.18+)
networks:
  proxy: { external: true, name: <сеть прокси> }
  • TRUSTED_PROXY_CIDRS в .env — подсеть сети прокси: docker network inspect <сеть прокси> -f '{{range .IPAM.Config}}{{.Subnet}}{{end}}'. Через неё же приходят BFF панели и кабинета, если они в этой сети.
  • Postgres в контейнере этой сети: DB_HOST=<имя контейнера>, DB_SSLMODE=disable допустим (трафик не выходит из сети Docker), учётка сервера — docker exec -i <postgres> psql -U postgres -d identity -v owner=identity -v server_password="$(cat secrets/db_password_server)" < db/roles.sql.
  • В .env значение — всё после = до конца строки: пометки и комментарии в ту же строку не пишите.
  • На прокси закройте /metrics и /healthz (location = /metrics { return 404; }), как в nginx/identity.conf.

Метрики для Prometheus и готовый дашборд Grafana — deploy/prod/grafana/README.md.

CLI администратора: docker compose run --rm migrate admin-list · admin-recover <email> [--reset-mfa] (или docker compose exec worker /identity-migrate admin-list).

C. Docker Swarm

Заголовок раздела «C. Docker Swarm»

deploy/swarm/stack.yml: migrate (перезапускается при смене образа), app (1 реплика, порты в mode: host — чтобы сервис видел реальный IP клиента), worker (1 реплика). Секреты — swarm secrets.

Окно терминала
docker load < images/zentro-identity-0.7.2-linux-amd64.tar.gz   # на узле(ах), где будет сервис
docker node update --label-add identity.data=true <узел>         # узел с томом /data
cd deploy/swarm
cp ../prod/.env.example .env && $EDITOR .env                      # те же переменные; DB_USER_OWNER/DB_USER_SERVER
for s in db_password_owner db_password_server vault_secret_id oidc_pairwise_secret smtp_password; do
  docker secret create identity_$s ../prod/secrets/$s              # пустой секрет swarm не примет: для SMTP без
done                                                               # авторизации — любой заполнитель
./deploy.sh                                                        # = docker stack deploy (+ переменные из .env)
docker service logs identity_migrate                               # «goose: … migrated» → app/worker поднимутся
docker exec -it $(docker ps -q -f name=identity_worker | head -1) /identity-migrate bootstrap-admin admin@example.com

Масштабирование app > 1: CACHE_BACKEND=redis и общий том /data (NFS/CSI), затем снять placement и поменять публикацию порта (routing mesh + прокси, умеющий PROXY protocol, или прокси на каждом узле).

CLI администратора: docker exec -it $(docker ps -q -f name=identity_worker | head -1) /identity-migrate admin-list.

D. ВМ без Docker (systemd)

Заголовок раздела «D. ВМ без Docker (systemd)»

Статические бинарники (без зависимостей), любой Linux с systemd.

Окно терминала
tar xzf binaries/zentro-identity-0.7.2-linux-amd64.tar.gz && cd zentro-identity-0.7.2-linux-amd64
sudo ./install.sh          # пользователь zentro-identity, /usr/local/bin/identity-*, /etc/zentro-identity/, юниты
sudo $EDITOR /etc/zentro-identity/identity.env      # общие переменные (справочник: deploy/env-reference.example)
sudo $EDITOR /etc/zentro-identity/server.env /etc/zentro-identity/owner.env   # роли БД
# секреты: /etc/zentro-identity/secrets/* (root:zentro-identity, 640)
sudo systemctl enable --now zentro-identity-server zentro-identity-worker     # migrate выполнится сам перед ними
sudo identity-cli bootstrap-admin admin@example.com

Сервер слушает 127.0.0.1:8080 (nginx на этом хосте, TRUSTED_PROXY_CIDRS=127.0.0.1/32). Журналы: journalctl -u zentro-identity-server -f. Юниты с песочницей systemd (ProtectSystem=strict, без capabilities, запись только в /var/lib/zentro-identity).

CLI администратора: sudo identity-cli admin-list · sudo identity-cli admin-recover <email> [--reset-mfa] (тот же пользователь, env и песочница, что у сервисов).

Обновление и откат: sudo /opt/zentro-identity/upgrade/upgrade.sh --latest (или полный архив комплекта вместо --latest) — см. «Обновление и откат» ниже. Бинарники хранятся по версиям в /opt/zentro-identity/versions/, действующая — ссылка current.

Администратор: создание и восстановление доступа

Заголовок раздела «Администратор: создание и восстановление доступа»
Команда Что делает
bootstrap-admin <email> первый администратор (ключ подписи, системные роли, временный пароль). Если админ уже есть — ничего не делает
setup-code новый код установки для первого запуска в панели (прежний гасится). Если админ уже есть — отказ
admin-list администраторы: email, статус, число MFA-факторов, последний вход
admin-recover <email> вернуть доступ: разблокировать аккаунт и снять блокировку за неверные пароли, вернуть роль администратора, выдать временный пароль (печатается один раз), отозвать все сессии
admin-recover <email> --reset-mfa то же + снять MFA и доверенные устройства (потерян телефон/ключ)

Все действия пишутся в аудит (actor_type=system). Доступ к этим командам = доступ к серверу и паролю владельца БД. Пользователь, входящий только через внешний IdP (без пароля Zentro), восстанавливается в самом IdP.

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

Заголовок раздела «Проверка после установки»
Окно терминала
curl https://id.example.com/.well-known/openid-configuration     # issuer = PUBLIC_BASE_URL
curl -I https://id.example.com/.well-known/jwks.json              # 200, strict-transport-security
curl -s -o /dev/null -w '%{http_code}\n' https://id.example.com/healthz   # 404 снаружи — так и должно быть

Дальше — панель администратора и личный кабинет из папки portal/: Установка панели и кабинета. Затем вход администратором → смена пароля → второй фактор → Первые шаги администратора.

Панель необязательна: всё, что она делает, доступно через API Identity (описание — https://id.example.com/docs, https://id.example.com/openapi.yaml). Если у вас своя панель администратора или своя форма входа, папку portal/ можно не ставить.

Обновление и откат

Заголовок раздела «Обновление и откат»

Обновляет и откатывает администратор установки сам, на своём сервере — вендор удалённо ничего не делает. Админка показывает установленную версию, совместимость схемы базы, историю версий и вышедшую новую версию (Система → Версия и обновления, GET /api/v1/admin/system/version); выполняются команды ниже.

Обновление одной командой — сервер Identity и панель с кабинетом вместе. Compose — --dir каталога с docker-compose.yml и .env; ВМ — без него, sudo:

Окно терминала
./upgrade/upgrade.sh --dir /opt/identity --latest                          # последняя версия с сайта Zentro
./upgrade/upgrade.sh --dir /opt/identity --version 0.7.6                   # конкретная версия
./upgrade/upgrade.sh --dir /opt/identity zentro-identity-0.7.6.tar.gz      # архив, скачанный вручную
sudo /opt/zentro-identity/upgrade/upgrade.sh --latest                      # ВМ
# панель и кабинет: их каталог указывается один раз, дальше скрипт его помнит
./upgrade/upgrade.sh --dir /opt/identity --latest --portal-dir /opt/portal
# скриптов ещё нет в установке или они старше 0.7.4 — из распакованного нового архива:
./zentro-identity-0.7.6/deploy/upgrade/upgrade.sh --dir /opt/identity zentro-identity-0.7.6.tar.gz

Откуда берётся новая версия. --latest и --version скачивают полный архив с сайта Zentro (раздел «Скачать», все версии доступны всем, без регистрации), сверяют его контрольную сумму с сайтом, дальше проверяют подпись вендора, как у архива. Нужен curl или wget. Без интернета — скачайте архив на другом компьютере и передайте его скрипту. Админка (Система → Версия и обновления) показывает, вышла ли новая версия, и готовую команду.

Панель и кабинет. После того как новый Identity ответил на проверку готовности, скрипт загружает образы панели и кабинета из того же комплекта, ставит VERSION в их .env и перезапускает их с теми же файлами compose (TLS, docker-compose.override.yml), с которыми их запускали. Не поднялись — возвращается их прежняя версия, Identity остаётся новым. --no-portal — не трогать панель и кабинет.

Подпись вендора. Комплект содержит SHA256SUMS.sig — подпись SHA256SUMS ключом вендора. Скрипт проверяет её установленной версией (ключ вшит в её сборку) — подменённый архив вместе с суммами не пройдёт; комплект без подписи не принимается (--allow-unsigned — только комплекты до 0.6.2 / свои сборки). Версии до 0.6.2 подпись не проверяют (предупреждение) и скачивать не умеют — первое обновление с них делается архивом.

Что делает: проверяет подпись и контрольные суммы архива → загружает образ (ВМ — бинарники в versions/) → новой версией проверяет базу (identity-migrate upgrade-check: какие миграции будут применены; база новее — отказ) → бэкап базы (pg_dump с хоста или из образа postgres:16-alpine) → останавливает сервис → миграции → запускает новую версию → ждёт /healthz → обновляет панель и кабинет. Прежние версии остаются на сервере. Сбой миграций — запускается прежняя версия, печатается команда отката. Ключи: --yes (без вопросов), --backup-dir, --no-backup (только если схема не меняется).

Условия лицензии. Если в новой версии изменились условия лицензии, скрипт покажет их кратко, даст ссылку на лицензионный договор и спросит согласие; без согласия обновление не начнётся. Для запуска без вопросов (например, из планировщика) добавьте --accept-license — ключ --yes согласием с новыми условиями не считается. Принятые редакции записываются в .upgrade/license-accepted.tsv и в историю версий.

Откат на любую прежнюю версию — два режима, выбирает администратор:

Окно терминала
./upgrade/rollback.sh --dir /opt/identity --list                         # версии на сервере, бэкапы, история
./upgrade/rollback.sh --dir /opt/identity --to 0.5.5                     # только версия, база не трогается
./upgrade/rollback.sh --dir /opt/identity --to 0.5.5 --restore-db        # + база из бэкапа перед обновлением с 0.5.5
./upgrade/rollback.sh --dir /opt/identity --to 0.5.5 --restore-db /backups/identity-….dump   # + база из указанного бэкапа

Панель и кабинет откатываются на ту же версию, если её образы есть на сервере; --no-portal — не трогать.

  • Без восстановления базы — данные, появившиеся после обновления, сохраняются. Возможно, только если прежняя версия понимает текущую схему (обновление было без миграций); иначе скрипт откажет и подскажет бэкап.
  • С восстановлением (--restore-db) — база возвращается к моменту бэкапа: так же откатывают ошибочные данные, попавшие в базу после обновления. Всё, что изменилось после бэкапа (входы, пользователи, настройки, аудит), теряется — скрипт предупреждает. Перед восстановлением текущая база сохраняется ещё одним бэкапом (откат можно отменить). Восстановление атомарное: таблицы, дамп и права учётки приложения (включая append-only аудита) — одной транзакцией; сбой — база как была, запускается прежняя версия.
  • Версия запускается только со «своей» схемой: если база новее версии, сервер не стартует и подсказывает откат с восстановлением (иначе старый код молча портил бы данные).

Обязательно: бэкап базы без ключей Vault бесполезен (PII и секреты зашифрованы) — Vault бэкапится по его регламенту; при SECRETS_BACKEND=local сохраните PII_DET_KEY и каталог ключей подписи. Бэкапы — в <каталог установки>/backups (Compose) / /var/backups/zentro-identity (ВМ); храните их вне сервера. Если pg_dump/psql на хосте нет — используется образ PG_IMAGE=postgres:16-alpine (сеть — PG_DOCKER_NETWORK, по умолчанию host; если база — сервис в compose-сети, укажите её).

Swarm: одной команды пока нет (миграции — сервис стека, секреты — в Swarm). Порядок вручную: docker load нового образа на узлы → docker run … identity-migrate upgrade-check (проверка) → бэкап (deploy/prod/backup/backup.sh) → IDENTITY_IMAGE в .env → ./deploy.sh; откат — прежний IDENTITY_IMAGE (+ восстановление бэкапа, если схема менялась: deploy/upgrade/sql/drop-schema.sql + pg_restore + deploy/upgrade/sql/repair-grants.sql одной транзакцией).

Бэкапы

Заголовок раздела «Бэкапы»

deploy/prod/backup/backup.sh (pg_dump по cron, ротация) и restore-check.sh (проверочное восстановление во временную БД). Дамп без Vault бесполезен: PII и секреты зашифрованы ключами из Vault — бэкап Vault по его регламенту. При SECRETS_BACKEND=local — сохраните ключ PII_DET_KEY и каталог ключей подписи.

Лицензия

Заголовок раздела «Лицензия»

Zentro Identity — проприетарное программное обеспечение. Без ключа лицензии действует бесплатный тариф Free: установку можно использовать в своей организации в его пределах. Возможности и лимиты платных тарифов — по ключу лицензии, который вводится в панели (Лицензия). Состав тарифов — на странице «Тарифы» сайта Zentro.

Условия использования — файл LICENSE.txt комплекта; лицензии сторонних компонентов — THIRD_PARTY_NOTICES.txt и portal/THIRD_PARTY_NOTICES.txt.

Ограничения версии

Заголовок раздела «Ограничения версии»
  • Kubernetes-манифесты — в одной из следующих версий.
  • Мультитенантный обмен токенов (/auth/exchange) требует сервиса UCM — в этой версии не использовать.
  • Больше одного инстанса сервера — только с Redis (CACHE_BACKEND=redis).