Files

T

sysops 1e8a6c22cd API-12: kek-bezugsdienst-starten

- 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

2026-08-30 23:54:07 +02:00

2.9 KiB

Raw Blame History

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.

2.9 KiB Raw Blame History Unescape Escape