Files
nexarch/archive/docs/RET-08-PRUEFPROTOKOLL.md
T
sysops b30e16cb4f RET-08: ret-06-api auf rbac-06 migrieren
- internal/rbacclient: HTTP-Client fuer Core RBAC-06 (POST /authorize)
- retentionapi.RequireRole (Header-Provisorium) ersetzt durch
  RequireRBAC, echter Aufruf gegen RBAC-06, fail-closed bei Fehlern
- Mount nimmt jetzt rbacclient.Client entgegen
- alle bestehenden RET-06-API-Tests weiterhin gruen
- neue Tests: verweigerte Rolle (403 gegen echte RBAC-06-Antwort),
  erlaubte Rolle (200), RBAC-06 nicht erreichbar -> fail-closed (403)
- real deployed auf 131, end-zu-ende per curl nachgewiesen (403/403/200/403)

Pruefungen siehe archive/docs/RET-08-PRUEFPROTOKOLL.md
2026-08-30 08:43:00 +02:00

71 lines
4.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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-api`s `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.