sysops
1e8a6c22cd
- cmd/kek-api: startet internal/kek.Handler.TenantKEKHandler (API-10), tenantResolverAdapter bildet tenant.Registry.GetBySlug auf kek.TenantResolver ab (nur Signatur-Anpassung) - reines Wiring, kein Diff an internal/kek|moduleregistry|tenant (verifiziert) - real deployed auf 131, end-zu-ende bewiesen: echtes Modul registriert+provisioniert, echter Tenant-KEK erzeugt, curl gegen laufenden Dienst liefert exakt denselben KEK zurueck (byte-fuer-byte verglichen), falsches Credential -> 403 - reale Grant-Luecke gefunden und behoben (nexarch_core auf tenant_keks), verifiziert Pruefungen siehe docs/API-12-PRUEFPROTOKOLL.md
62 lines
2.9 KiB
Markdown
62 lines
2.9 KiB
Markdown
# API-12 – Prüfprotokoll: KEK-Bezugsdienst starten (API-10 als laufender Dienst)
|
||
|
||
Voraussetzung API-10 – bereits Fertig, hier UNVERÄNDERT.
|
||
|
||
## Reines Wiring, keine neue Logik
|
||
|
||
`git diff --stat internal/kek/ internal/moduleregistry/ internal/tenant/`
|
||
liefert KEINEN Diff. `cmd/kek-api/main.go` setzt ausschließlich
|
||
bestehende Konstruktoren zusammen; `tenantResolverAdapter` bildet nur
|
||
`tenant.Registry.GetBySlug` auf `kek.TenantResolver` ab (Signatur-
|
||
Anpassung, kein neuer Fachcode).
|
||
|
||
## Umsetzung
|
||
|
||
- `cmd/kek-api/main.go` – `POST /internal/kek/tenant?tenant=<slug>`,
|
||
authentifiziert über dasselbe Service-Credential-Verfahren wie jeder
|
||
andere Modul-Core-Aufruf (API-02), zusätzlich Tenant-Aktivierungs-
|
||
prüfung (identisches Muster wie in `internal/kek.Handler` bereits
|
||
vorgesehen).
|
||
- `deploy/systemd/nexarch-kek-api.service.tmpl`.
|
||
|
||
## Prüfungen
|
||
|
||
| # | Prüfung | Ergebnis |
|
||
|---|---|---|
|
||
| 1 | Dienst startet und bleibt stabil (systemctl status aktiv) | **bestanden** – real auf 131: `nexarch-kek-api.service` aktiv |
|
||
| 2 | Realer Aufruf mit gültigem Service-Credential liefert den erwarteten Tenant-KEK, ohne/mit falschem Credential wird abgelehnt | **bestanden** – real per `curl`: echtes Modul registriert+provisioniert, echter Tenant-KEK über `kek.Store.CreateForTenant` erzeugt (Klartext-Hex zum Vergleich notiert) — Aufruf mit korrektem Credential liefert exakt denselben KEK (Base64-dekodiert übereinstimmend mit dem erzeugten Hex-Wert verifiziert); Aufruf mit falschem Credential → 403 |
|
||
| 3 | Code-Review: keine Änderung an internal/kek/ selbst, nur main.go+systemd neu | **bestanden** – `git diff --stat` bestätigt: `internal/kek/`, `internal/moduleregistry/`, `internal/tenant/` unverändert |
|
||
|
||
## Echte Verdrahtung auf 192.168.1.131
|
||
|
||
- `kek-api` gebaut nach `/opt/nexarch-core/bin/`,
|
||
`/etc/nexarch/kek-api.env` (0600, echter zufälliger 32-Byte-
|
||
Master-Key), Dienst installiert/aktiviert.
|
||
- Reale Grant-Lücke gefunden und behoben (gleiches Muster wie zuvor):
|
||
`nexarch_core` hatte keine Rechte auf `tenant_keks` — `GRANT`
|
||
nachgezogen und über `information_schema.role_table_grants`
|
||
verifiziert.
|
||
- End-zu-Ende-Beweis: echtes Modul registriert, Service-Credential
|
||
provisioniert, echter Tenant + Tenant-KEK real erzeugt, `curl` gegen
|
||
den laufenden Dienst liefert exakt diesen KEK zurück (Byte-für-Byte
|
||
verglichen), falsches Credential real abgelehnt. Testdaten
|
||
anschließend entfernt.
|
||
|
||
## Build/Test-Ergebnis (192.168.1.131)
|
||
|
||
```
|
||
go build ./... -> clean
|
||
go vet ./... -> clean
|
||
golangci-lint run ./cmd/kek-api/... -> 0 issues
|
||
```
|
||
|
||
Keine neuen Go-Tests nötig (kein neuer Fachcode außer main.go/Adapter,
|
||
die eigentliche Logik ist bereits durch API-10s eigene Tests
|
||
abgedeckt).
|
||
|
||
## Gesamtergebnis
|
||
|
||
**Bestanden.** API-10 ist jetzt ein real laufender, über systemd
|
||
verwalteter Dienst — Voraussetzung für Mail ARC-02 und künftig DMS
|
||
FDN-09-Nachnutzung.
|