# Лог мышления — 2026-04-04-02

## Агент: GitHub Copilot (Claude Sonnet 4.6)

Продолжение сессии от 2026-04-04 (файл 2026-04-04.md достиг 681 строки).

---

## Задача: MQTT WebSocket через nginx-ingress — отладка 404 → 400

### Контекст

Порт 1883 заблокирован NSX-T Edge firewall на уровне облака.
Временный workaround: EMQX WebSocket listener (8083) → nginx-ingress → `iot.kube5s.ru/mqtt`.

### Что нашёл

**Проблема 1 — 404:** Ingress не получил ADDRESS (IP не присвоен).
- Причина: annotation `nginx.ingress.kubernetes.io/configuration-snippet` заблокирован в nginx-controller v1.12.6.
  По умолчанию `allow-snippet-annotations=false`.
- Решение: убрал `configuration-snippet` из Ingress.
- Результат: Ingress получил sync (Scheduled for sync), но ADDRESS всё ещё пустой — это нормально для данного контроллера.

**Проблема 2 — 400:** После удаления snippet стало 400 вместо 404.
- nginx конфиг для `iot.kube5s.ru` правильный:
  - `proxy_set_header Upgrade $http_upgrade` — ЕСТЬ (nginx-ingress добавляет автоматически)
  - `proxy_http_version 1.1` — ЕСТЬ
  - `proxy_send_timeout/read_timeout 3600s` — ЕСТЬ
  - `proxy_pass → sless-emqx-ws-8083` — ЕСТЬ
- Значит 400 приходит от EMQX, а не от nginx.

### Гипотезы почему EMQX возвращает 400

EMQX WebSocket listener конфиг:
```
listeners.ws.default {
  bind = "0.0.0.0:8083"
  max_connections = 512
}
```

Нет явного `websocket.path`. По умолчанию EMQX ожидает путь `/mqtt`.
Но nginx из-за `pathType: Prefix` на `/mqtt` может передавать путь без trailing slash.

**Вариант A**: nginx передаёт запрос на `/mqtt` (без `/`) — EMQX ожидает `/mqtt` → должно работать.
**Вариант B**: EMQX в 5.5.1 ожидает `ws://host/mqtt` без всякого proxy path rewrite и есть баг с `X-Forwarded-Proto` — nginx шлёт `http`, а EMQX может редиректить.
**Вариант C**: `ssl_redirect: true` в nginx конфиге означает что HTTP запрос перенаправляется на HTTPS, и там 400.

### Следующий шаг

Проверить `$ssl_redirect = true` в nginx server block для нашего хоста:
- Если да — nginx делает redirect HTTP→HTTPS
- Добавить аннотацию `nginx.ingress.kubernetes.io/ssl-redirect: "false"` или тестировать через HTTPS

### Правило (новое)

Если файл `doc/thinking/ГГГГ-ММ-ДД.md` стал большим — создавать `ГГГГ-ММ-ДД-02.md`, `ГГГГ-ММ-ДД-03.md` и т.д.

---

## Задача: Анализ безопасности MQTT multitenancy

### Что исследовал

Пользователь спросил об угрозах межтенантного проникновения.

Изучил:
1. `emqx.conf` в поде — `authorization { no_match = allow }` — после CONNECT всё разрешено
2. `internal/api/handler/iot_device_handler.go` — `MQTTAuth` возвращает только `{"result":"allow"}` без ACL rules

### Вывод

**Auth (CONNECT) защищён:**
- HTTP auth endpoint проверяет namespace+deviceId+password (constant-time compare)
- enabled=true проверяется
- Secret изолирован по namespace

**ACL на pub/sub НЕТ:**
- `no_match = allow` — аутентифицированный клиент может SUBSCRIBE на любой топик
- EMQX HTTP auth plugin поддерживает возврат ACL rules в ответе на auth
- Формат ответа: `{"result":"allow","acl":[{"permission":"allow","action":"all","topic":"sless/ns/+"}]}`
- Текущий `mqttAuthResponse` содержит только `Result string` — ACL поле отсутствует

### Риски по приоритету

1. **Критично**: User A может SUBSCRIBE `sless/#` и читать все IoT данные всех пользователей
2. **Средне**: Нет rate limit на MQTT — один клиент может flood брокер
3. **Низко**: Нет TLS на 8083 (WebSocket без шифрования) — данные видны в сети

### План фикса

Добавить в `mqttAuthResponse` поле `ACL []aclRule` и возвращать из `MQTTAuth`:
```json
{
  "result": "allow",
  "acl": [
    {"permission": "allow", "action": "publish", "topic": "sless/{ns}/{deviceId}"},
    {"permission": "allow", "action": "subscribe", "topic": "sless/{ns}/{deviceId}"},
    {"permission": "deny", "action": "all", "topic": "#"}
  ]
}
```

Ждём подтверждения от пользователя перед реализацией.

---

## Архитектурная дискуссия — IoT телеметрия и хранение данных

### Контекст разговора

Пользователь задал вопрос: "куда пишутся данные с IoT датчиков?"

Выяснилось что сейчас данные теряются — function pod получает событие но никуда не сохраняет. Это нормально для serverless (пользователь сам решает), но для IoT платформы нужно автоматическое хранение.

### Анализ сценариев использования

Реалистичные клиенты для Nubes (облачный провайдер СНГ, малый/средний бизнес):
1. Мониторинг объектов (склады, серверные, торговые точки) — температура, влажность, протечка
2. Умные счётчики / ЖКХ — снятие показаний без выезда
3. Небольшое производство / агро — теплицы, мини-заводы

Общий паттерн для всех: датчик → данные в БД → алерт если порог → график

### Решение по хранению данных

**Вопрос**: один большой Postgres или отдельный на каждого?
**Ответ**: один Postgres инстанс, но отдельная DATABASE на каждого tenant.

Причины:
- Вариант со одной таблицей + tenant_id — изоляция программная, ошибка в коде = утечка
- Отдельная DATABASE — физическая изоляция, разные connection string, разные пароли
- Клиент B не может подключиться к DATABASE клиента A даже при баге в коде платформы

Структура:
```
Postgres инстанс
├── sless_platform DB  — системные таблицы (tenants, invocations)
├── tenant_abc DB      — только данные клиента A
└── tenant_def DB      — только данные клиента B
```

### Решение по доступу клиента

**Вопрос**: давать клиенту прямой доступ к Postgres?
**Ответ**: нет. Только через REST API платформы.

Причины:
- Postgres внутри кластера, снаружи не торчит (security)
- Единый endpoint `iot.kube5s.ru`
- Легко добавить rate limit, биллинг, кеш
- Клиент не зависит от деталей реализации хранилища

API:
```
GET /v1/namespaces/{ns}/iot/telemetry?device=X&from=T&to=T
GET /v1/namespaces/{ns}/iot/devices/{id}/last
```

### Решение по schema.sql

Клиент может положить `schema.sql` рядом с функцией. При деплое платформа выполняет его в БД tenant'а.
Это даёт низкий порог входа — клиент не шарит в Python, но может написать SQL по шаблону.

### Ключевое архитектурное решение — разделение операторов

**Решение**: sless-operator и iot-operator — ОТДЕЛЬНЫЕ компоненты.
Пока в одном кластере, но сделать так чтобы могли быть в разных.

**Namespace layout:**
```
namespace: sless          — платформа sless (operator, event-dispatcher, RabbitMQ, Postgres invocations)
namespace: sless-{hash}   — tenant функции (function pods)
namespace: iot            — платформа IoT (iot-operator, EMQX, Postgres telemetry)
namespace: iot-{hash}     — tenant IoT (IoTDevice CRDs)
```

**Связь**:
- Общий идентификатор tenant: `{hash}` одинаковый в обоих namespace
- MQTT событие → RabbitMQ в sless → function pod в sless-{hash}
- IoT operator НЕ импортирует пакеты sless-operator (loose coupling)
- Общение только через k8s API и RabbitMQ

**Postgres**:
- sless имеет свой Postgres (invocations)
- iot имеет свой Postgres (telemetry per tenant)
- Разные StatefulSet, разные PVC

### Что делает пользователь

Клиент:
1. Подключает устройство → данные автоматически пишутся в его `iot_telemetry`
2. Пишет функцию которая реагирует на события
3. Функция получает `DB_DSN` в env var (автоматически из Secret)
4. Может делать SELECT/INSERT в свою БД через обычный SQL в коде функции
5. Может читать телеметрию через REST API

### Plan — следующие шаги (этап IoT Postgres)

1. Поднять Postgres StatefulSet в namespace `iot`
2. В iot-operator при создании IoTDevice namespace → `CREATE USER`, `CREATE DATABASE`, `CREATE TABLE iot_telemetry`, `CREATE TABLE iot_devices`
3. Credentials → k8s Secret `iot-tenant-{ns}-pg`
4. В iot-mqtt-bridge при получении MQTT сообщения → INSERT в tenant БД
5. REST API endpoint для чтения телеметрии
6. При деплое function → прокинуть `DB_DSN` в env var из Secret
7. При деплое function → если есть `schema.sql` → выполнить в tenant БД

### Технические решения

- Postgres: `postgres:16-alpine` StatefulSet с PVC 10Gi в namespace `iot`
- Connection pool: pgxpool (pgx v5) per-tenant, lazy init, max 5 conn per tenant
- Таблица telemetry: `(id bigserial, device_id text, ts timestamptz default now(), payload jsonb)`
- Индекс: `(device_id, ts DESC)` для быстрых запросов по устройству за период
- Retention: пока без TTL, добавить позже через pg_partman или cron job


---
## 2026-04-04 — IoT Console UI: план и реализация

**Агент**: GitHub Copilot (Claude Sonnet 4.6)

### Постановка задачи

Пользователь сформулировал: нужен UI для управления IoT устройствами.
Причина: не все пользователи работают через Terraform/API напрямую.
Нужно: создать устройство, получить credentials, прошить в устройство, проверить отправку данных.

### Ключевое решение: эмулятор устройства в браузере

MQTT WebSocket уже работает: `ws://iot.kube5s.ru:80/mqtt`.
Браузер через mqtt.js (CDN) может подключиться как устройство напрямую.
Это значит: эмулятор — это не "симуляция", а реальная публикация MQTT сообщений.

Когда у клиента ещё нет физического устройства — он тестирует через эмулятор.
Это закрывает весь цикл без необходимости устанавливать MQTT-клиент.

### Архитектурные решения UI

**Стек**: ванильный HTML/CSS/JS + mqtt.js (CDN). Никаких фреймворков.
**Где хранить**: встраиваем в бинарник оператора через `go:embed`.
  - Файл: `internal/api/ui/iot-console.html`
  - Маршрут: `GET /console`

**Где доступен**: `http://iot.kube5s.ru/console`
  - Ingress добавляем path `/console` → `sless-operator:9090`

**Почему не `https://sless.kube5s.ru/console`:**
  - UI на HTTPS + MQTT WS без TLS = mixed content, браузер блокирует
  - UI на HTTP + MQTT WS = нет mixed content, всё работает
  - HTTP → HTTPS API вызовы разрешены (это не mixed content)
  - Нужен только CORS на API стороне

**CORS**: заголовки `Access-Control-Allow-Origin: http://iot.kube5s.ru` + OPTIONS preflight

### Страницы

1. Вход: API адрес + MQTT брокер + namespace + токен → localStorage
2. Список устройств: таблица, создать, удалить
3. Устройство (3 вкладки):
   - Credentials: username, password скрыт, топик, инструкция
   - Эмулятор: подключиться → JSON payload → send / авто
   - Телеметрия: "скоро"

### Следующие шаги после UI

1. Postgres StatefulSet в namespace `iot`
2. INSERT в iot_telemetry из mqtt-bridge
3. REST API для чтения телеметрии
4. Заполнить вкладку "Телеметрия" в UI

---
# Агент: GitHub Copilot (Claude Sonnet 4.6) — продолжение сессии 2026-04-04

## Исправления и улучшения IoT Console UI (v0.1.53 → v0.1.58)

### Проблема 1: `crypto.subtle.digest` — Cannot read properties of undefined

**Симптом:** Пользователь вставил токен, получил ошибку "Cannot read properties of undefined (reading 'digest')".

**Анализ:** `crypto.subtle` доступен ТОЛЬКО на HTTPS-страницах (Secure Context). Консоль раздавалась по HTTP (`http://iot.kube5s.ru/console`). На HTTP `crypto.subtle === undefined`.

**Решение:** Перевести консоль на HTTPS — это устранит корень проблемы и заодно уберёт необходимость в pure-JS SHA256. Попытка написать pure-JS SHA256 была правильной как fallback, но правильнее — исправить инфраструктуру.

**Действия:**
1. `emqx-ws-ingress.yaml`: добавлена TLS-секция + `cert-manager.io/cluster-issuer: letsencrypt-prod`, `ssl-redirect: "true"`, `secretName: iot-kube5s-ru-tls`
2. `router.go`: CORS `Allow-Origin`: `http://` → `https://iot.kube5s.ru`
3. `iot-console.html`: дефолт MQTT брокера `ws://` → `wss://`
4. cert-manager автоматически выпустил сертификат Let's Encrypt (READY: True за ~34 сек)
5. Собрали v0.1.54, задеплоили

**Косяк при apply:** `kubectl apply` взял старый Ingress из кэша (только путь `/mqtt`, без `/console`). Пришлось использовать `kubectl replace` вместо `apply`.

**Итог:** `https://iot.kube5s.ru/console` → 200, TLS v1.3, `CN=iot.kube5s.ru`, Let's Encrypt R13. `crypto.subtle` заработал.

---

### Проблема 2: 404 после перехода на HTTPS (v0.1.54)

**Симптом:** После `kubectl apply` + rollout — curl возвращал 404.

**Анализ:** Запрос доходил до пода (видно в логах), но оператор отвечал 404. Значит маршрут `/console` не регистрировался. Проверили: файл `iot-console.html` существует на диске, `go:embed` прописан, маршрут в `router.go` есть. **Причина:** первый `docker build` взял Go-слои из кэша Docker — старый бинарь без `/console` маршрута.

**Решение:** Пересборка с `--no-cache`. После пуша нового диджеста и `kubectl rollout restart` — заработало.

---

### Улучшение: убрать поля API/MQTT из формы входа (v0.1.56)

**Анализ:** Пользователь справедливо спросил "ЗАЧЕМ юзеру это вводить?" — адреса `https://sless.kube5s.ru` и `wss://iot.kube5s.ru/mqtt` фиксированы для данного деплоя. Пользователь не должен их трогать.

**Решение:** Удалены `<input id="f-api">` и `<input id="f-mqtt">` из формы. В `doLogin()` адреса берутся из хардкода, не из DOM. Форма стала: только поле токена + кнопка "Войти".

**Параллельно:** Добавлен блок `<details class="help-block">` внизу страницы устройства — 5 шагов инструкции: Credentials → формат JSON → Эмулятор → Авто → Телеметрия (скоро).

---

### Ребрендинг: Nubes brand design (v0.1.57)

**Задача:** "Оформи чтобы строго, чётко — как на terra.k8c.ru".

**Исследование:**
- Скачал SVG логотипа: `https://terra.k8c.ru/docs/nubes/nubes/2.0.2/30_registry/assets/logo.svg`
- Логотип залит `#001C34` — это основной Nubes Navy цвет
- Сайт nubes.ru использует тёмно-синий (#001C34) как бренд-прайм

**Палитра:**
| Переменная     | Цвет       | Назначение                   |
|----------------|------------|------------------------------|
| brand primary  | `#001C34`  | Navbar, карточки, логотип    |
| page bg        | `#001120`  | Фон страницы                 |
| card surface   | `#001929`  | Карточки .card               |
| borders        | `#0b2d50`  | Границы, разделители         |
| accent         | `#1a7fd4`  | Кнопки, табы, ссылки         |
| text primary   | `#e2ecf6`  | Основной текст               |
| text secondary | `#6b8eaa`  | Метки, подписи               |
| text muted     | `#2d5070`  | Отключённые, подсказки       |

**Изменения в CSS:**
- Navbar: `background: #001C34`, логотип SVG с `filter: brightness(0) invert(1)` (белый)
- Badges: прямоугольные (`border-radius: 4px`), UPPERCASE, компактные
- Кнопки: `font-weight: 600`, `letter-spacing: 0.02em`
- Таблицы: заголовки `color: #2d5070` — строгие, тихие
- `.help-num`: квадратные (4px), не круглые

**Форма входа:** логотип SVG (инвертированный) вместо `⚡`, подпись `IoT Console` uppercase вместо названия по-русски.

---

### Favicon (v0.1.58)

**Задача:** Иконка вкладки браузера — как у Nubes docs.

**Исследование:** `curl https://terra.k8c.ru/docs/nubes/nubes/2.0.2/` → `<link rel="icon" href="30_registry/assets/favicon.png">`

**URL:** `https://terra.k8c.ru/docs/nubes/nubes/2.0.2/30_registry/assets/favicon.png`

**Решение:** Добавлена одна строка в `<head>`:
```html
<link rel="icon" href="https://terra.k8c.ru/docs/nubes/nubes/2.0.2/30_registry/assets/favicon.png">
```

---

## Итоговые версии

| Версия  | Изменение                                       | Коммит   |
|---------|-------------------------------------------------|----------|
| v0.1.54 | TLS на iot.kube5s.ru, wss://, CORS https       | fb6f9d4  |
| v0.1.55 | Help-блок на странице устройства                | e547871  |
| v0.1.56 | Убраны поля API/MQTT из формы входа             | e547871  |
| v0.1.57 | Nubes brand rebrand — палитра, логотип          | 0400f97  |
| v0.1.58 | Favicon Nubes                                   | 93e87a3  |

## Текущее состояние

- ✅ `https://iot.kube5s.ru/console` — работает, TLS, Nubes-дизайн, favicon
- ✅ MQTT: `wss://iot.kube5s.ru/mqtt`
- ✅ `crypto.subtle` работает (HTTPS)
- ✅ Форма входа: только токен
- ✅ Namespace скрыт от пользователя
- ❌ Телеметрия — заглушка, бэкенд не написан

## Следующий шаг

Бэкенд телеметрии:
1. Postgres StatefulSet в namespace `iot`
2. Tenant provisioning при создании IoTDevice
3. INSERT в mqtt-bridge
4. REST API чтения
5. Вкладка Телеметрия в UI