docs: Claude Sonnet review of GPT-5.4 analysis + security roadmap
- Added sonnet-review-of-gpt-analysis.md - GPT-5.4 правильно выявил lifecycle issues (event model, invocation history) - Но пропустил security roadmap (gVisor, NetworkPolicy, LLM validation) - Дополнен production security roadmap для следующего агента - Updated progress.md — зафиксированы оба анализа
This commit is contained in:
“Naeel”
@@ -0,0 +1,313 @@
|
||||
# Claude Sonnet 4.6: Review of GPT-5.4 Analysis
|
||||
|
||||
Дата: 2026-03-10
|
||||
Автор: Claude Sonnet 4.6
|
||||
Контекст: Анализ документа `agent-handoff-2026-03-10.md`, подготовленного GPT-5.4
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
GPT-5.4 провёл детальный code review и выявил реальные архитектурные проблемы в текущей реализации sless. Анализ качественный, приоритизация разумная, но **фокус исключительно на lifecycle/data consistency**, при этом **полностью упущен security roadmap для production**.
|
||||
|
||||
**Мой вердикт:**
|
||||
- ✅ GPT-5.4 правильно определил проблемы event model (A1, A2)
|
||||
- ✅ Invocation history gap (A3) — точное попадание
|
||||
- ✅ Приоритизация задач логична для текущего MVP
|
||||
- ⚠️ **Критичный пробел:** безопасность multi-tenant serverless платформы вообще не упомянута
|
||||
- ⚠️ Не учтён контекст беседы с пользователем про gVisor, LLM validation, runtime isolation
|
||||
|
||||
---
|
||||
|
||||
## Где GPT-5.4 абсолютно прав
|
||||
|
||||
### 1. Event Model Problems (A1, A2) — критично
|
||||
|
||||
**Проблема:**
|
||||
```go
|
||||
// trigger_controller.go
|
||||
func (r *TriggerReconciler) SetupWithManager(mgr ctrl.Manager) error {
|
||||
return ctrl.NewControllerManagedBy(mgr).
|
||||
For(&sllessv1alpha1.Trigger{}). // ❌ нет watch на Function
|
||||
Complete(r)
|
||||
}
|
||||
```
|
||||
|
||||
Trigger может зависнуть в `waiting` если Function не Ready на момент создания. Reconcile не произойдёт автоматически когда Function станет Ready.
|
||||
|
||||
**Почему это важно:** Классическая ошибка в operator patterns. Это не "незавершённая фича" а реальный race condition.
|
||||
|
||||
**Моё мнение:** Приоритет A1/A2 — верный. Это базовая корректность reconciliation loop.
|
||||
|
||||
### 2. Invocation History (A3) — не реализована
|
||||
|
||||
GPT-5.4 правильно выявил: таблица `invocations` есть, SaveInvocation() реализован, но **нигде не вызывается**.
|
||||
|
||||
```go
|
||||
// invoke.go — должно быть, но нет:
|
||||
// store.SaveInvocation(ctx, &storage.Invocation{...})
|
||||
```
|
||||
|
||||
**Моё мнение:** Согласен. Это не мелкая недоработка — это разрыв между API контрактом и реальностью.
|
||||
|
||||
### 3. Multi-tenancy через namespace в URL (A4) — проблема для production
|
||||
|
||||
```go
|
||||
// router.go
|
||||
r.HandleFunc("/v1/namespaces/{namespace}/functions", ...)
|
||||
```
|
||||
|
||||
Пользователь передаёт `namespace` в URL, но auth не проверяет принадлежность. Один токен = все namespace.
|
||||
|
||||
**Моё мнение:** Верно, но это known limitation для MVP. Важно не забыть при переходе к реальному tenant model.
|
||||
|
||||
### 4. Config inconsistency (B1) — мнимая конфигурируемость
|
||||
|
||||
```go
|
||||
// config.go
|
||||
FunctionNamespacePrefix string // есть поле
|
||||
|
||||
// function_controller.go
|
||||
targetNS := "sless-fn-" + fn.Namespace // 🔥 хардкод, игнорирует конфиг
|
||||
```
|
||||
|
||||
**Моё мнение:** Полностью согласен. Либо убрать поле либо использовать везде. Сейчас это вводит в заблуждение.
|
||||
|
||||
---
|
||||
|
||||
## Где GPT-5.4 поверхностен или не учёл контекст
|
||||
|
||||
### 1. Security для multi-tenant serverless — критичный пробел
|
||||
|
||||
GPT-5.4 **вообще не упомянул:**
|
||||
- Container escape protection (gVisor/Kata)
|
||||
- Network isolation между namespace (NetworkPolicy)
|
||||
- Code validation перед деплоем
|
||||
- Resource abuse prevention
|
||||
- Kernel-level isolation
|
||||
|
||||
**Проблема:** Для публичного managed serverless это не "nice to have" — это базовое требование безопасности.
|
||||
|
||||
**Контекст из беседы:**
|
||||
Пользователь спрашивал: "как быть? всё должно быть безопасно". Обсуждали:
|
||||
- gVisor — sandbox runtime для защиты от container escape
|
||||
- NetworkPolicy — изоляция трафика между namespace
|
||||
- LLM validation — проверка кода на malicious patterns
|
||||
- Capsule/vCluster — для усиленной изоляции
|
||||
|
||||
**Мой вывод:** GPT-5.4 дал план для "внутреннего инструмента", но не для "облачного продукта".
|
||||
|
||||
### 2. LLM integration для security — не упомянута
|
||||
|
||||
**Контекст из беседы:**
|
||||
- "LLM скоро запустят в облаке. и он должен себя оправдывать"
|
||||
- Идея: builder вызывает LLM для проверки кода перед сборкой
|
||||
- Защита от криптомайнеров, ботнетов, DDoS-агентов
|
||||
|
||||
GPT-5.4 вообще не включил это в roadmap, хотя пользователь явно видит это частью системы.
|
||||
|
||||
**Мой вывод:** LLM validation должна быть в плане после исправления lifecycle issues, но до production launch.
|
||||
|
||||
### 3. Go runtime — не упомянут
|
||||
|
||||
**Контекст из беседы:**
|
||||
- "пока не надо, но надо golang будет"
|
||||
- Обсуждали двухэтапный Dockerfile (builder → scratch)
|
||||
- Go даёт ~5-10MB бинарь vs ~100MB Python/Node
|
||||
|
||||
GPT-5.4 не включил Go runtime в roadmap, хотя это логичный next step после стабилизации существующих рантаймов.
|
||||
|
||||
### 4. Production deployment model — не рассмотрен
|
||||
|
||||
GPT-5.4 правильно отметил что один бинарь (API + operator) "нормален для v1", но не дал vision когда и как разделять.
|
||||
|
||||
**Что пропущено:**
|
||||
- API становится data plane proxy → bottleneck
|
||||
- HA для operator manager (leader election есть, но не обсуждается)
|
||||
- Separate control/data plane для масштабирования
|
||||
|
||||
**Мой вывод:** Для MVP текущая архитектура OK, но GPT-5.4 мог дать более чёткий trigger point для refactor.
|
||||
|
||||
---
|
||||
|
||||
## Где я частично не согласен
|
||||
|
||||
### 1. Timeout enforcement (B2) — не приоритет сейчас
|
||||
|
||||
GPT-5.4 включил TimeoutSec в "критичность B", но реально это less critical чем security.
|
||||
|
||||
**Моё мнение:**
|
||||
- Runtime timeout — nice to have для MVP
|
||||
- Можно задокументировать как "informational field" и вернуться позже
|
||||
- Важнее NetworkPolicy + gVisor чем timeout enforcement
|
||||
|
||||
### 2. Test coverage (B4) — правильно отмечено, но слишком общо
|
||||
|
||||
GPT-5.4: "Тестов ядра почти нет".
|
||||
|
||||
**Моё мнение:**
|
||||
- Да, это проблема
|
||||
- Но конкретные приоритеты тестов должны быть:
|
||||
1. Event model (Trigger/FunctionJob watch на Function)
|
||||
2. Cleanup finalizers
|
||||
3. Invocation history recording
|
||||
- Не надо гнаться за coverage %, надо покрыть critical paths
|
||||
|
||||
---
|
||||
|
||||
## Production Security Roadmap (пропущен GPT-5.4)
|
||||
|
||||
Это должно быть в handoff, но отсутствует.
|
||||
|
||||
### Immediate (до первых external users)
|
||||
|
||||
1. **gVisor RuntimeClass**
|
||||
```yaml
|
||||
spec:
|
||||
runtimeClassName: gvisor
|
||||
```
|
||||
- Защита от container escape
|
||||
- ~10-20% performance overhead
|
||||
- Установка на ноды + RuntimeClass в k8s
|
||||
|
||||
2. **NetworkPolicy per namespace**
|
||||
```yaml
|
||||
kind: NetworkPolicy
|
||||
spec:
|
||||
podSelector: {}
|
||||
policyTypes: ["Ingress", "Egress"]
|
||||
ingress: [] # Deny all by default
|
||||
```
|
||||
- Запретить трафик между `sless-fn-*` namespace
|
||||
- Разрешить только к external services + internal DNS
|
||||
|
||||
3. **ResourceQuota per tenant**
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ResourceQuota
|
||||
spec:
|
||||
hard:
|
||||
requests.cpu: "10"
|
||||
requests.memory: 20Gi
|
||||
pods: "50"
|
||||
```
|
||||
|
||||
### Near-term (параллельно с lifecycle fixes)
|
||||
|
||||
4. **Static code analysis в builder**
|
||||
- Python: `bandit` before Docker build
|
||||
- Node.js: `npm audit`
|
||||
- Блокировка деплоя при critical issues
|
||||
|
||||
5. **Image scanning**
|
||||
- Trivy/Grype после kaniko build
|
||||
- Reject образа если critical CVE
|
||||
|
||||
### Medium-term (перед production launch)
|
||||
|
||||
6. **LLM validation hook**
|
||||
- API call к облачному LLM перед сборкой
|
||||
- Детект криптомайнеров, port scanners, DDoS agents
|
||||
- Premium feature или throttled для free tier
|
||||
|
||||
7. **True tenant isolation**
|
||||
- Identity из JWT → namespace mapping
|
||||
- User не может передать namespace в URL
|
||||
- RBAC per tenant
|
||||
|
||||
---
|
||||
|
||||
## Рекомендуемый порядок работ (мой взгляд vs GPT-5.4)
|
||||
|
||||
### GPT-5.4 предложил:
|
||||
1. Event model (Trigger/FunctionJob watch)
|
||||
2. Invocation history
|
||||
3. Timeout/validation sync
|
||||
4. Config consistency
|
||||
5. Tests
|
||||
|
||||
### Я рекомендую:
|
||||
1. ✅ Event model — согласен, приоритет #1
|
||||
2. ✅ Invocation history — согласен, приоритет #2
|
||||
3. ⚠️ **Добавить: gVisor + NetworkPolicy** (до external users)
|
||||
4. ✅ Config consistency
|
||||
5. ✅ Tests (но фокус на critical paths)
|
||||
6. ⚠️ **Добавить: Static analysis в builder**
|
||||
7. Timeout enforcement (lower priority)
|
||||
8. ⚠️ **Добавить: LLM validation (перед production)**
|
||||
|
||||
---
|
||||
|
||||
## Практические дополнения для следующего агента
|
||||
|
||||
### Что делать с GPT-5.4 handoff
|
||||
|
||||
**Использовать как base**, но:
|
||||
1. После этапа 2 (invocation history) → добавить security hardening
|
||||
2. Перед production launch → полный security audit + LLM integration
|
||||
3. Go runtime → после стабилизации Python/Node (не urgent)
|
||||
|
||||
### Конкретные файлы для security work (пропущены GPT-5.4)
|
||||
|
||||
**gVisor:**
|
||||
- `controllers/function_controller.go` — добавить `RuntimeClassName: "gvisor"` в PodSpec
|
||||
- Установка на ноды (вне кода)
|
||||
|
||||
**NetworkPolicy:**
|
||||
- `deployments/k8s/network-policy.yaml` — создать template
|
||||
- `controllers/function_controller.go` — создавать NetworkPolicy per namespace
|
||||
|
||||
**Code validation:**
|
||||
- `internal/builder/builder.go` — добавить pre-build validation hook
|
||||
- `internal/validator/` (новый) — интеграция с bandit/npm audit
|
||||
|
||||
**LLM validation:**
|
||||
- `internal/validator/llm.go` — API client к облачному LLM
|
||||
- `internal/api/handler/upload.go` — вызов перед S3 upload
|
||||
|
||||
---
|
||||
|
||||
## Файлы которые следующий агент должен создать/изучить
|
||||
|
||||
**GPT-5.4 не упомянул, но критичны:**
|
||||
|
||||
1. `doc/security/multi-tenancy-model.md` — дизайн tenant isolation
|
||||
2. `doc/security/runtime-isolation.md` — gVisor/Kata decision + implementation
|
||||
3. `deployments/k8s/network-policy-template.yaml` — NetworkPolicy per tenant
|
||||
4. `deployments/k8s/resource-quota-template.yaml` — ResourceQuota per tenant
|
||||
5. `internal/validator/` — новый пакет для code validation
|
||||
6. `doc/decisions/gvisor-vs-kata.md` — почему gVisor for MVP
|
||||
|
||||
---
|
||||
|
||||
## Окончательный вердикт
|
||||
|
||||
**GPT-5.4 провёл отличный технический аудит кода**, но смотрел через призму "внутреннего инструмента", а не "managed cloud service".
|
||||
|
||||
**Сильные стороны анализа:**
|
||||
- ✅ Детальный разбор lifecycle problems
|
||||
- ✅ Конкретные файлы и строки кода
|
||||
- ✅ Приоритизация по критичности
|
||||
- ✅ Практичный план для MVP stabilization
|
||||
|
||||
**Пробелы:**
|
||||
- ❌ Security roadmap отсутствует
|
||||
- ❌ Не учтён контекст беседы (gVisor, LLM, Go runtime)
|
||||
- ❌ Production deployment model не рассмотрен
|
||||
- ❌ Tenant isolation strategy не обсуждается
|
||||
|
||||
**Рекомендация:**
|
||||
Использовать GPT-5.4 handoff как **техническую базу**, дополнить моими замечаниями по security, затем скомбинировать в единый production roadmap.
|
||||
|
||||
**Для следующего агента:**
|
||||
1. Читать GPT-5.4 документ для lifecycle issues
|
||||
2. Читать этот документ для security roadmap
|
||||
3. Начинать с lifecycle (приоритет GPT-5.4)
|
||||
4. После стабилизации — security hardening (мой приоритет)
|
||||
5. Перед production launch — полный аудит (желательно Claude Opus 4.6)
|
||||
|
||||
---
|
||||
|
||||
## Действия для этой сессии
|
||||
|
||||
Следующий шаг: обновить `doc/progress.md`, зафиксировать оба анализа (GPT-5.4 + мой), чтобы следующий агент видел полную картину.
|
||||
+10
-1
@@ -1,11 +1,20 @@
|
||||
# Прогресс разработки
|
||||
|
||||
Последнее обновление: 2026-03-09 (operator v0.1.18, provider v0.1.11)
|
||||
Последнее обновление: 2026-03-10 (добавлен подробный архитектурный handoff-документ для следующего агента)
|
||||
|
||||
## Статусы: ✅ готово | 🔄 в процессе | ⏳ не начато
|
||||
|
||||
---
|
||||
|
||||
## 2026-03-10 — Архитектурный разбор и handoff для следующего агента
|
||||
|
||||
| # | Задача | Статус | Заметки |
|
||||
|---|--------|--------|---------|
|
||||
| 1 | GPT-5.4: Подробный разбор кода и lifecycle issues | ✅ | `doc/architecture/agent-handoff-2026-03-10.md` — детальный code review, event model problems, invocation history gap, приоритеты |
|
||||
| 2 | Claude Sonnet 4.6: Review + security roadmap | ✅ | `doc/architecture/sonnet-review-of-gpt-analysis.md` — где GPT-5.4 прав, что пропустил (gVisor, LLM validation, NetworkPolicy), production security roadmap |
|
||||
|
||||
---
|
||||
|
||||
## v1 — Базовый сервис
|
||||
|
||||
### Код
|
||||
|
||||
Reference in New Issue
Block a user