nexarch/archive/docs/RET-08-PRUEFPROTOKOLL.md

RET-08 – Prüfprotokoll: RET-06-API auf RBAC-06 migrieren (Provisorium abbauen)

Voraussetzung RBAC-06 (Core) und RET-06-API – beide bereits Fertig.

Umsetzung

• archive/internal/rbacclient (neu) – schlanker HTTP-Client für Core RBAC-06 (POST /authorize), service-token-authentifiziert. Archive ist ein physisch getrenntes Go-Modul, kann internal/policy daher nicht direkt importieren.
• archive/internal/retentionapi/authz.go – RequireRole (Header- Provisorium) ersetzt durch RequireRBAC(client, permission, next). Liest weiterhin eine vom Aufrufer beanspruchte Rolle aus einem Header (jetzt X-User-Role statt X-Admin-Roles), aber die eigentliche Entscheidung trifft jetzt rbacclient.Client.Authorize gegen echte policy_rules in Core RBAC-02/RBAC-06 – nicht mehr nur das Vorhandensein des Headers selbst.
• Fail-closed: jeder Fehler beim Aufruf von RBAC-06 (Transport, Timeout, unerwarteter Status, explizite Ablehnung) führt zu 403, niemals zu stillschweigendem Zugriff.
• archive/internal/retentionapi/handler.go – Mount nimmt jetzt zusätzlich einen *rbacclient.Client entgegen, alle vier Endpunkte gegen dasselbe Recht retention.configure geprüft.
• archive/cmd/retention-api/main.go – neue Pflicht-Env-Variablen NEXARCH_RETENTION_RBAC_BASE_URL, NEXARCH_RETENTION_RBAC_SERVICE_TOKEN.

Prüfungen

#	Prüfung	Ergebnis
1	403-Nachweis gegen echte Policy-Rules über RBAC-06, nicht nur Header	bestanden – TestRequireRBAC_DeniedRoleReturns403 (fehlender Header UND unbekannte Rolle gegen eine echte fake-RBAC-06-HTTP-Antwort); real auf 131: curl mit X-User-Role: archive_admin ohne existierende policy_rules-Zeile → 403, mit real per INSERT INTO policy_rules gesetzter Regel → 200, nach DELETE wieder 403
2	Bestehende RET-06-API-Tests laufen weiterhin grün nach der Migration	bestanden – TestConfigureAndListHandler_RealHTTPRoundTrip, TestDeactivateHandler_RealHTTPRoundTrip, TestPreviewHandler_MatchesPeriodicJobResult alle unverändert grün (Mount jetzt mit fake-RBAC-06-Server statt Header-Provisorium)
3	Ausfall von RBAC-06 führt zu Ablehnung, kein Fallback auf offenen Zugriff	bestanden – TestRequireRBAC_UnreachableRBACFailsClosed: rbacclient.Client zeigt auf nicht erreichbaren Endpunkt (http://127.0.0.1:1), Handler nachweislich nie erreicht, Antwort 403

Echte Verdrahtung auf 192.168.1.131

• retention-api neu gebaut, /etc/nexarch/archive-retention-api.env um NEXARCH_RETENTION_RBAC_BASE_URL=http://127.0.0.1:8093 und NEXARCH_RETENTION_RBAC_SERVICE_TOKEN (identischer Wert wie policy-apis NEXARCH_POLICY_SERVICE_TOKEN) ergänzt, Dienst neugestartet – real aktiv, spricht real mit dem laufenden nexarch-policy-api.service (RBAC-06).
• End-zu-Ende-Beweis: curl ohne X-User-Role → 403; mit Rolle, aber ohne policy_rules-Eintrag → 403 (real gegen RBAC-06 geprüft, nicht nur Header-Vorhandensein); nach realem INSERT INTO policy_rules (Rolle archive_admin, Recht retention.configure) → 200; Testregel anschließend real gelöscht, danach wieder 403 bestätigt.
• Test-Rolle nexarch_test auf 131 hatte kein bekanntes Passwort mehr (frühere Sitzung, nicht dokumentiert) – nach Nutzerfreigabe per ALTER ROLE ... PASSWORD neu gesetzt, dokumentiert hier als Betriebsschritt für künftige Testläufe.

Build/Test-Ergebnis (192.168.1.131)

go build ./...  -> clean
go vet ./...    -> clean
golangci-lint run ./...  -> 0 issues
go test ./... -p 1  -> alle Pakete bestanden (inkl. objectbackup, restoretest, retentionapi)

Gesamtergebnis

Bestanden. Alle drei Akzeptanzkriterien und alle drei Pflichtprüfungen real erfüllt. Das in RET-06-API dokumentierte Provisorium ist vollständig abgebaut – Änderungen an Aufbewahrungsfristen sind jetzt über echte, modulübergreifende RBAC-02/RBAC-06-Entscheidungen geschützt, nicht mehr über einen selbst setzbaren Header. RET-06 (Frontend) ist damit ohne weiteren RBAC-Blocker startbar.