исправление багов

docs/INFRASTRUCTURE.md

@@ -34,6 +34,9 @@ JWT_REFRESH_TOKEN_TTL=7d
 
 `POSTGRES_PASSWORD` обязателен для `docker compose up`: пароль не хранится в `compose.yaml`. `JWT_SECRET` должен быть случайным секретом длиной минимум 32 байта. В продакшене секреты задаются через Kubernetes Secret, а не через коммитимые файлы.
 
+Встроенного JWT fallback в приложении нет. Отсутствующее, короткое или шаблонное значение
+останавливает запуск; профиль `production` также требует Secure refresh-cookie.
+
 Локальный `backend/tenants.json` тоже не коммитится. Для ручного запуска backend вне Docker можно взять `backend/tenants.example.json`, создать рядом `tenants.json` и подставить локальный пароль.
 
 ### Dockerfile (Backend)
@@ -64,7 +67,7 @@ RUN chown -R www-data:www-data /usr/local/apache2/htdocs/
 |--------|-----|----------|
 | `backend` | Deployment | Spring Boot приложение |
 | `frontend` | Deployment | Apache httpd |
-| `tenants-config` | ConfigMap | JSON-список тенантов |
+| `tenants-secret` | Внешний Secret | JSON-список tenant-подключений; значения отсутствуют в манифестах |
 
 ### JWT настройки
 
@@ -74,16 +77,35 @@ RUN chown -R www-data:www-data /usr/local/apache2/htdocs/
 - `JWT_REFRESH_TOKEN_TTL=7d`
 - `JWT_REFRESH_COOKIE_SECURE=true`
 
-`app-secret` задаёт `JWT_SECRET`. Его нельзя логировать или хранить в публичных артефактах как реальный продакшн-секрет.
+`app-secret` задаёт `JWT_SECRET`. Этот Secret не создаётся файлами `../k8s/`: его заранее
+предоставляет внешний secret manager или оператор. Deployment явно включает профиль
+`production`, поэтому небезопасная cookie-конфигурация останавливает startup.
 
-### ConfigMap для тенантов
+### Secrets для приложения и тенантов
 
-ConfigMap `tenants-config` монтируется в под backend по пути `/config/tenants.json`.
+Обязательные внешние объекты:
+
+| Secret | Назначение |
+|---|---|
+| `app-secret` | JWT и fallback credentials backend |
+| `tenants-secret` | Полный `tenants.json` с credentials tenant-БД |
+| `otel-postgres-secret` | Credentials PostgreSQL receivers для OTel Collector |
+| `gitea-registry` | Доступ Kubernetes к registry |
+
+Secret `tenants-secret` монтируется в pod backend по пути `/config/tenants.json`.
 
 При добавлении тенанта через API:
 1. `DatabaseController` обновляет in-memory DataSource
-2. `ConfigMapUpdater` обновляет ConfigMap через Kubernetes API
-3. `TenantConfigWatcher` на остальных подах подхватывает изменения (каждые 30 сек)
+2. `KubernetesTenantSecretUpdater` обновляет Secret через Kubernetes API
+3. `TenantConfigWatcher` на остальных pod подхватывает смонтированное изменение (каждые 30 сек)
+
+Kubernetes-клиент доверяет только service-account CA и проверяет hostname API server.
+RBAC ограничен объектом `tenants-secret`. Скрипт `../k8s/deploy.sh` проверяет наличие
+объектов и ключей до rollout, не читая и не печатая их значения.
+
+Создание, ротация, отзыв скомпрометированных значений и очистка истории описаны в
+[`SECURITY_RUNBOOK.md`](SECURITY_RUNBOOK.md). Эти действия требуют полномочий оператора и
+не выполняются автоматически.
 
 ### Обновление backend
 
@@ -148,6 +170,9 @@ Tenant ID добавляется в:
 - Метрики производительности страниц
 - Трейсы пользовательских действий
 
+PostgreSQL receivers collector получают endpoint и credentials только из
+`otel-postgres-secret`; ConfigMap collector содержит лишь `${env:...}` ссылки.
+
 ### Дашборды SigNoz
 
 - JVM Dashboard (Heap, GC, Threads)