Установка On-Premise

Rediacc может работать полностью на вашей собственной инфраструктуре. Автономный Docker-образ включает сервер аккаунтов, веб-портал, маркетинговый сайт и точку дистрибуции CLI. Внешние зависимости от облачных сервисов Rediacc не требуются.

Docker-образ

Загрузите автономный образ:

docker pull ghcr.io/rediacc/server:stable

Запустите с настройками по умолчанию:

docker run -p 80:80 -p 443:443 ghcr.io/rediacc/server:stable

Образ предоставляет:

Account API по адресу /account/api/v1/
Веб-портал по адресу /account/
Маркетинговый сайт по адресу /
Артефакты CLI по адресу /releases/
Бинарные файлы Renet по адресу /bin/

Установка CLI с вашего сервера

Пользователи могут устанавливать CLI напрямую с вашего on-premise сервера. Скрипт установки автоматически определяет канал обновлений и настраивает CLI для проверки обновлений на вашем сервере.

curl -fsSL https://account.example.com/install.sh | \
  REDIACC_SERVER_URL=https://account.example.com bash

Эта единственная команда:

Загружает бинарный файл CLI с эндпоинта /releases/ вашего сервера
Запрашивает /account/api/v1/.well-known/server-info для определения канала обновлений
Записывает server.json с URL вашего сервера, каналом обновлений и ключами шифрования
Настраивает rdc update для проверки обновлений на вашем сервере

Переменная REDIACC_CHANNEL не нужна. Скрипт установки считывает канал из конфигурации вашего сервера автоматически.

Конфигурация CLI с именованными конфигами

Для пользователей, подключающихся к нескольким серверам (on-premise, production, edge), именованные конфиги изолируют каждое окружение:

# Create a config for your on-premise server
rdc config init --name myserver --server https://account.example.com

# Log in using that config
rdc --config myserver subscription login

# All commands with --config use the on-premise server
rdc --config myserver machine query --name prod-1

Справочник CLI: rdc config init · rdc subscription login · rdc machine query

Каждый именованный конфиг хранит собственный URL сервера аккаунтов и токен подписки. Переключение конфига переключает весь контекст сервера.

Изолированные окружения (air-gapped)

Для окружений без доступа к интернету задайте как URL сервера, так и пользовательский URL релизов:

curl -fsSL https://account.example.com/install.sh | \
  REDIACC_SERVER_URL=https://account.example.com \
  REDIACC_RELEASES_URL=https://account.example.com/releases \
  bash

CLI будет проверять account.example.com/releases/cli/stable/manifest.json для обновлений вместо публичного CDN.

Если сервер полностью отключён от сети, установите CLI через npm из упакованного архива:

npm install -g https://account.example.com/npm/rediacc-cli-latest.tgz

Справочник переменных окружения

Переменная	Используется в	Назначение
`REDIACC_SERVER_URL`	Скрипт установки	URL сервера аккаунтов. Автоматически определяет канал и ключи шифрования.
`REDIACC_RELEASES_URL`	Скрипт установки, обновлятор CLI	Пользовательский эндпоинт релизов для бинарных файлов CLI. По умолчанию: `https://releases.rediacc.com`
`REDIACC_CHANNEL`	Скрипт установки	Переопределение канала обновлений. Автоопределяется с сервера, если не задан.
`REDIACC_ACCOUNT_SERVER`	Среда выполнения CLI	Переопределение URL сервера аккаунтов для всех команд CLI.
`RDC_UPDATE_CHANNEL`	Среда выполнения CLI	Переопределение канала обновлений для `rdc update`.

Конфигурация сервера

On-premise Docker-образ использует ту же переменную ENVIRONMENT, что и облачный сервис. Задайте её в конфигурации Docker или оркестратора:

ENVIRONMENT=production (по умолчанию): стандартные лимиты, клиентам рекомендуется stable-канал обновлений
ENVIRONMENT=edge: удвоенные лимиты Community, клиентам рекомендуется edge-канал обновлений

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

Что сервер сообщает CLI

При подключении CLI к вашему серверу он запрашивает /.well-known/server-info для определения:

Открытый ключ E2E-шифрования: для хранения конфигурации с нулевым разглашением
Минимальная версия CLI: блокирует устаревшие CLI от подключения
Канал обновлений: указывает CLI, какой канал релизов использовать для обновлений
Окружение: является ли это production или edge развёртыванием

Такая автоконфигурация означает, что пользователям нужен только URL сервера. Всё остальное определяется автоматически.

Лицензирование для изолированных развёртываний

Изолированные и самостоятельно размещённые on-premise серверы выдают лицензии локально с использованием сертификата делегирования, подписанного вышестоящим мастер-ключом. Сертификат ограничивает on-premise сервер лимитами его плана и создаёт защищённую от подделки цепочку. См. Цепочка лицензий и делегирование для изучения криптографической конструкции (целостность цепочки, обнаружение форков, доказательства аудита).

В этом разделе описывается операционная настройка: генерация ключей, запрос сертификата, настройка автообновления и офлайн-поток продления (air-gapped).

Одна подписка - одна on-premise установка

Подписка может иметь не более одного активного сертификата делегирования одновременно. Каждая on-premise установка соблюдает ежемесячные лимиты и лимиты по машинам согласно собственному локальному реестру выдачи, поэтому несколько активных сертификатов умножили бы эффективную квоту без возможности согласования.

Если вам нужны отдельные окружения (production, staging, DR, мультирегион), приобретите по одной подписке на каждую установку. Принудительное соблюдение единственного активного сертификата закрепляет этот договор: попытка создать второй активный сертификат возвращает 409 DELEGATION_CERT_ALREADY_ACTIVE с идентификатором существующего сертификата и инструкциями по продлению (рекомендуется - сохраняет цепочку) или отзыву-и-созданию (сбрасывает цепочку).

1. Генерация пары ключей Ed25519 для on-premise

On-premise сервер использует отдельную пару ключей Ed25519 для подписи лицензий. Сертификат делегирования вышестоящего сервера авторизует именно этот открытый ключ.

# Generate a fresh keypair
openssl genpkey -algorithm Ed25519 -out onprem-private.pem
openssl pkey -in onprem-private.pem -pubout -out onprem-public.pem

# Convert to base64 (the format the on-premise expects in env vars)
ON_PREMISE_PRIVATE_KEY=$(openssl pkey -in onprem-private.pem -outform DER | base64 -w 0)
ON_PREMISE_PUBLIC_KEY=$(openssl pkey -in onprem-private.pem -pubout -outform DER | base64 -w 0)

Храните закрытый ключ вместе с другими секретами (например, в Docker secret или Kubernetes Secret). Он никогда не покидает on-premise сервер.

2. Запрос сертификата делегирования у вышестоящего сервера

Вы можете запросить сертификат у вышестоящего портала тремя способами:

Вариант A - самообслуживание Customer (рекомендуется). Войдите на вышестоящий портал как владелец или Admin организации и перейдите в /account/delegation-certs. Нажмите Create New, вставьте открытый ключ on-premise (base64 SPKI), выберите срок действия (или примите значение по умолчанию для плана) и скачайте получившийся файл .json.

Вариант B - Admin (межклиентский). Служба поддержки Rediacc или системный администратор вышестоящего сервера может использовать POST /admin/delegation-certs с теми же параметрами.

Вариант C - CLI rdc (планируется). Будущая команда CLI обернёт поток портала.

Возвращаемый .json выглядит так:

{
  "payload": "eyJ2ZXJzaW9uIjoxLCJzdWJzY3JpcHRpb25JZCI6...",
  "signature": "...",
  "publicKeyId": "..."
}

Срок действия сертификата определяется политикой валидности (значения по умолчанию и потолки для каждого плана, переопределение для каждой подписки, ограниченное датой окончания подписки + 3 дня льготного периода). Ответ также содержит effectiveDays и reason, чтобы вы могли видеть, почему было выбрано именно это значение. Полные правила см. в Цепочка лицензий - Политика валидности.

3. Установка сертификата на on-premise сервер

Сохраните загруженный .json по известному пути и укажите на него on-premise серверу:

DELEGATION_CERT_PATH=/etc/rediacc/delegation-cert.json

Или для рабочих процессов с эфемерными контейнерами или Docker secrets встройте сертификат в base64 в переменную окружения:

DELEGATION_CERT_BASE64=$(base64 -w 0 < delegation-cert.json)

4. Настройка проверки вышестоящего сервера + автообновление (необязательно, но рекомендуется)

Если ваш on-premise сервер имеет исходящий HTTPS-доступ к вышестоящему серверу, настройте автоматическое продление, чтобы сертификат обновлялся до истечения срока действия без ручного вмешательства:

# Required for /onprem/cert-upload to verify uploaded certs against the upstream master key.
# Fails-fast at boot if UPSTREAM_API_KEY is set without this.
UPSTREAM_PUBLIC_KEY="<upstream master Ed25519 SPKI public key, base64>"

# Required for the auto-renew loop. Mint via the portal:
#   Org owner/admin → /account/delegation-certs → "Get auto-renew token"
# This is the ONLY way to obtain a delegation:renew-scoped api token.
UPSTREAM_URL="https://www.rediacc.com"
UPSTREAM_API_KEY="rdt_..."

# Optional tuning (defaults shown).
AUTO_RENEW_INTERVAL_HOURS=24
RENEW_THRESHOLD_DAYS=14

Цикл автообновления on-premise запускается один раз при загрузке, а затем с заданным интервалом. Он использует адаптивный порог (min(env.RENEW_THRESHOLD_DAYS, ceil(certValidityDays / 3))), поэтому 15-дневный COMMUNITY сертификат продлевается при 5 оставшихся днях, а не сразу. 90-дневный BUSINESS сертификат продлевается при 14 оставшихся днях (применяется потолок из переменной окружения).

Если продление не удаётся, сертификат продолжает использоваться до естественного истечения срока. Ошибка регистрируется в ${DELEGATION_CERT_PATH}.status.json и доступна через GET /onprem/cert-status, с откатом на 1 час между попытками.

5. Продление в изолированном окружении (без исходящего HTTPS)

Если ваш on-premise сервер не может обратиться к вышестоящему, используйте поток ручной передачи:

Загрузите запрос на продление с портала администратора on-premise. Будучи root системы on-premise, обратитесь к GET /onprem/renewal-request. Это возвращает JSON-манифест с текущей вершиной локальной цепочки, делегированным открытым ключом и защищённой от подделки подписью Ed25519 от вашего закрытого ключа on-premise.
Передайте манифест на вышестоящий сервер через USB, зашифрованную почту или любой внеполосный канал. Манифест невелик (несколько КБ) и не содержит секретов.
Обработайте манифест на вышестоящем сервере. Владелец/Admin организации открывает /account/delegation-certs -> Upload renewal request -> выбирает файл манифеста. Вышестоящий сервер проверяет подпись манифеста по delegatedPublicKey активного сертификата (доказывает, что он исходит от владельца закрытого ключа on-premise), проверяет защиту от воспроизведения (манифесты старше 7 дней отклоняются), затем выдаёт новый сертификат.
Скачайте новый сертификат с портала вышестоящего сервера в виде файла .json.
Передайте сертификат обратно на on-premise сервер.
Загрузите на on-premise через локальный портал администратора (POST /onprem/cert-upload). On-premise сервер проверяет новый сертификат по UPSTREAM_PUBLIC_KEY и подтверждает, что genesisSequence сертификата по-прежнему связывается с записью в локальном реестре выдачи (продвижение цепочки в процессе транзита поддерживается - цепочка расширяется естественным образом).

Весь этот цикл не требует исходящего сетевого трафика с on-premise сервера.

Коды ошибок манифеста

Код	Причина	Решение
`NO_ACTIVE_CERT`	У вышестоящего сервера нет активного сертификата для этой подписки	Выдайте новый сертификат через поток создания вместо продления
`DELEGATED_KEY_MISMATCH`	`delegatedPublicKey` манифеста отличается от активного сертификата	Манифест может быть воспроизведением с другой on-premise установки
`MANIFEST_SIGNATURE_INVALID`	Подпись не проходит проверку по делегированному открытому ключу	Манифест был изменён при передаче, или вы сгенерировали его на другом on-premise сервере
`MANIFEST_EXPIRED`	Манифест старше 7 дней	Сгенерируйте новый запрос на продление с on-premise сервера

Коды ошибок загрузки сертификата

Код	Причина	Решение
`CHAIN_HEAD_BEHIND`	`genesisSequence` нового сертификата опережает вершину локальной цепочки	Вышестоящий сервер находится на форкнутой цепочке - проведите расследование
`CHAIN_FORK_ON_UPLOAD`	Хеш цепочки при `genesisSequence` сертификата не совпадает с локальным реестром	Локальная цепочка разошлась с вышестоящей - проведите расследование
`Signature verification failed`	Сертификат не подписан настроенным `UPSTREAM_PUBLIC_KEY`	Проверьте, что `UPSTREAM_PUBLIC_KEY` совпадает с мастер-ключом вышестоящего сервера

6. Статус и мониторинг

Запросите состояние локального сертификата on-premise в любое время:

curl https://onprem.example.com/account/api/v1/onprem/cert-status \
  -H "Cookie: <admin session>"

Возвращает subscriptionId, planCode, validUntil, daysUntilExpiry загруженного сертификата, а также блок autoRenew (enabled, lastSuccessAt, lastErrorAt, lastError). Подключите это к вашей системе мониторинга для оповещения об устаревшем lastSuccessAt или ненулевом lastError.

Для резервного копирования и аудита администратор on-premise может также загрузить текущий подписанный сертификат через GET /onprem/cert-current (требует расширенной сессии).

Справочник переменных окружения сертификата делегирования

Переменная	Обязательна?	Назначение
`ON_PREMISE_MODE`	Да	Установите `true` для включения подмножества on-premise маршрутов
`ON_PREMISE_PRIVATE_KEY`	Да	Закрытый ключ Ed25519 PKCS8 в base64 для делегированной подписи
`ON_PREMISE_PUBLIC_KEY`	Да	Открытый ключ Ed25519 SPKI в base64 (должен совпадать с `delegatedPublicKey` сертификата)
`DELEGATION_CERT_PATH`	Одно из двух	Путь в файловой системе к подписанному JSON сертификата
`DELEGATION_CERT_BASE64`	Одно из двух	JSON сертификата в base64 (альтернатива пути к файлу)
`UPSTREAM_PUBLIC_KEY`	Обязательна, если задан `UPSTREAM_API_KEY`, или для работы `/onprem/cert-upload`	Открытый ключ SPKI вышестоящего мастер-ключа в base64. Быстрый сбой при запуске, если отсутствует.
`UPSTREAM_URL`	Для автообновления	Базовый URL вышестоящего сервера аккаунтов, например `https://www.rediacc.com`
`UPSTREAM_API_KEY`	Для автообновления	API-токен с областью `delegation:renew`. Получите через портал - см. шаг 4.
`AUTO_RENEW_INTERVAL_HOURS`	Необязательна	По умолчанию 24. Как часто проверять, нужно ли обновить сертификат.
`RENEW_THRESHOLD_DAYS`	Необязательна	По умолчанию 14. Действует как потолок адаптивного порога 1/3 от срока действия.

Краткое описание модели угроз

Модель сертификата делегирования защищает от:

Поддельных лицензий: on-premise может подписывать только в пределах лимитов плана; renet отклоняет всё, что выходит за рамки сертификата.
Общего использования сертификата на нескольких установках: расхождение цепочки обнаруживается при продлении (возвращает CHAIN_FORK_DETECTED).
Обхода квоты через несколько установок: обеспечивается на вышестоящем сервере принципом единственного активного сертификата (один сертификат на подписку).
Отката цепочки: renet хранит максимальный виденный номер последовательности для каждой подписки и отклоняет любой блоб с меньшим номером.
Скомпрометированных учётных данных вышестоящего сервера: токен delegation:renew при начальной настройке можно получить только через специальный эндпоинт портала с ограничением для Admin. Токен предоставляет только право продления - он не может читать или изменять другие ресурсы.
Атак воспроизведения на манифесты: манифесты старше 7 дней отклоняются.

От чего это не защищает:

Скомпрометированный закрытый ключ on-premise: утечка закрытого ключа позволяет злоумышленнику подписывать лицензии до validUntil сертификата. Меры по снижению риска: смените пару ключей (отзовите старый сертификат и создайте новый с новым ключом) и считайте все лицензии, подписанные старым ключом, подозрительными.
Скомпрометированный мастер-ключ вышестоящего сервера: это корень доверия. Процедуры ротации выходят за рамки данного документа.