# 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.