- 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
71 lines
4.0 KiB
Markdown
71 lines
4.0 KiB
Markdown
# 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.
|