Идентичность

В Soul Stack две разновидности субъектов, и каждая доказывает свою личность по-своему:

• управляемые хосты (Souls) — через mTLS-сертификат, приватный ключ которого никогда не покидает хост;
• операторы (Архонты) — через JWT, привязанный к идентификатору AID.

Идентичность хоста (Soul)

Идентичность управляемого хоста строится на трёх сущностях.

SID = FQDN

Идентификатор хоста (SID) — это его FQDN, а не случайный UUID. Следствия:

• переустановка агента на тот же хост автоматически дедуплицируется — SID совпадает, новая запись не плодится;
• переименование FQDN трактуется как миграция (старый хост → новый); смена SID «на месте» не поддерживается.

SoulSeed

SoulSeed — пара «mTLS-сертификат + приватный ключ», которой агент аутентифицируется при подключении к Keeper-у.

• Приватный ключ генерируется на самом хосте и никогда его не покидает. Наружу уходит только запрос на подпись (CSR).
• SoulSeed регулярно ротируется по живому стриму, без участия оператора.
• В базе Keeper-а хранится только отпечаток (fingerprint) сертификата — ни PEM, ни тем более приватного ключа в базе нет.

Главная криптографическая защита идентичности — приватный ключ удостоверяющего центра (CA), который живёт в Vault, а не на дисках кластера.

Coven

Coven — произвольная стабильная метка для логического объединения хостов (по ЦОДу, проекту, окружению). Используется в RBAC (ограничение прав оператора по covens) и в таргетинге задач. К доказательству личности Coven отношения не имеет — это группировка, не идентификатор.

Онбординг через CSR

Первое подключение агента — обмен одноразового bootstrap-токена на постоянную mTLS-идентичность. Приватный ключ при этом ни на каком шаге не передаётся по сети.

1. Оператор регистрирует хост и получает короткий bootstrap-токен — это именно токен на одноразовое предъявление, не сертификат и не ключ.
2. Токен доставляется на хост вместе с исполняемым файлом агента (способ доставки — на выбор оператора).
3. На хосте агент:
   • локально генерирует приватный ключ (он никогда не покинет хост);
   • формирует CSR (запрос на подпись);
   • предъявляет Keeper-у токен и CSR на отдельном bootstrap-listener-е (server-only TLS);
   • получает подписанный сертификат — SoulSeed;
   • кладёт сертификат рядом с приватным ключом и сжигает токен;
   • открывает основной gRPC-стрим, уже используя SoulSeed как mTLS-идентичность.

Защиты bootstrap-токена

Токен — самый чувствительный момент онбординга (это пропуск к получению подписанного сертификата), поэтому он обвязан тремя защитами:

• Одноразовость. Токен сжигается при первом успешном предъявлении CSR; повторно использовать его нельзя.
• Короткий TTL. Токен живёт ограниченное время (по умолчанию 24 часа) и протухает, если не был использован.
• Привязка к SID. Токен действителен только для того хоста, под который выпущен.

В базе хранится не сам токен, а его хеш — даже при доступе к базе восстановить действующий токен нельзя.

Зачем приватный ключ остаётся на хосте

Поскольку приватный ключ генерируется локально и не передаётся по сети, его невозможно перехватить при доставке и невозможно извлечь из базы Keeper-а — там его попросту нет. Скомпрометировать идентичность конкретного хоста можно, только получив доступ к самому хосту.

Идентичность оператора (Архонт)

Оператор Soul Stack называется Архонт (Archon). Его идентификатор — AID (Archon ID).

• AID — устойчивый строковый идентификатор оператора (например, archon-alice, archon-ops-01). Под этим идентификатором оператор фигурирует в аудит-журнале и в привязках ролей.
• Credential — JWT. Оператор предъявляет Operator API подписанный JWT. Ключ подписи живёт в Vault.
• Первый Архонт заводится отдельной административной командой Keeper-а при инициализации кластера и получает роль cluster-admin. Все последующие Архонты создаются уже через Operator API существующим администратором.
• Ревокация. Архонта можно отозвать; при коротком TTL токена это даёт быстрое отключение доступа.

Полная модель прав оператора — роли, каталог permissions, группы (Synod) и scoped-видимость (Purview) — в разделе Управление операторами.

Push-режим: идентичность без mTLS

В push-режиме (управление хостом по SSH без установленного агента) у хоста нет mTLS-идентичности — её роль играет SSH-сторона (ключи и аутентификация SSH). Такой хост — это запись в том же реестре с пометкой transport: ssh; SoulSeed для него не выпускается. Подробнее о транспорте обоих режимов — Транспорт.