Безопасность
Безопасность — не отдельная фича Soul Stack, а первичный критерий при каждом архитектурном выборе. Где возникает компромисс между удобством и безопасностью, по умолчанию выигрывает безопасность, а ослабление выражается явным, аудируемым opt-out-ом оператора, а не молчаливым поведением.
Этот раздел описывает модель безопасности: на чём стоит идентичность узлов, как защищён транспорт между ними и как система обращается с секретами.
Что вы получаете из коробки
Заголовок раздела «Что вы получаете из коробки»| Контур | Что даёт | Подробнее |
|---|---|---|
| mTLS-транспорт | Весь обмен Keeper ↔ агент идёт по взаимно аутентифицированному TLS. Обе стороны предъявляют сертификаты; ни одна не доверяет анонимному пиру. | Транспорт |
| Идентичность через CSR | Приватный ключ агента генерируется на самом хосте и никогда его не покидает. На Keeper-е заводится только отпечаток (fingerprint) сертификата — ни PEM, ни приватных ключей в базе нет. | Идентичность |
| Встроенный RBAC | Каждый вызов Operator API проходит проверку прав оператора (Архонта). Политика по умолчанию — deny: не разрешённое явно запрещено. | Управление операторами |
| Аудит-журнал | Каждая операция оператора фиксируется в аудит-журнале с указанием инициатора (AID) и результата. | Управление операторами |
| Интеграция с Vault | PKI Vault выпускает сертификаты агентов, KV Vault хранит секреты, подставляемые в конфиги при рендере. Секреты не материализуются на диск кластера. | Секреты |
| Маскинг секретов | Значения, помеченные секретными, маскируются на всех выходах — в логах, OTel-трейсах, UI, API-ответах и отчётах о прогоне. | Секреты |
| Тонкий агент | Рендер Destiny (CEL + шаблоны, чтение Vault) выполняется на Keeper-е. Агент не несёт vault-клиента и логики резолва секретов — поверхность атаки на управляемом хосте минимальна. | Секреты |
Принцип тонкого агента
Заголовок раздела «Принцип тонкого агента»Ключевое следствие модели — на управляемом хосте живёт минимум кода и минимум прав.
- Рендер — на Keeper-е. Шаблонизация и резолв секретов из Vault происходят на стороне Keeper-а; агент получает уже готовый набор задач. Агенту не нужен ни vault-клиент, ни доступ к Vault-токенам.
- Никакого входящего трафика. Стрим к Keeper-у инициирует сам агент. На управляемых хостах не нужно открывать входящие порты — наружу торчит только локальный listener метрик (по умолчанию на loopback).
- Минимум секретов на хосте. Из чувствительного на хосте лежит только приватный ключ собственной идентичности агента — и тот сгенерирован локально и никогда не покидал машину.
Под-страницы раздела
Заголовок раздела «Под-страницы раздела»- Идентичность — как узлы и операторы доказывают, кто они: SID, SoulSeed, онбординг через CSR, bootstrap-токены, Архонты и AID.
- Транспорт — gRPC-стрим поверх mTLS, направление инициации соединения, общий PKI-корень.
- Секреты — интеграция с Vault, резолв на стороне Keeper-а, маскинг на выходе, ключ
no_log.
Детали RBAC вынесены в раздел Управление операторами: bootstrap первого Архонта — Архонты, каталог permissions и роли — Роли, группы операторов (Synod) и scoped-видимость (Purview) — Synod и Purview.