jakman85andClaude Opus 5
bacb4c61ee
CNPGNoRecentBaseBackup's own remediation hint said `kubectl get backup`. On this cluster longhorn.io, postgresql.cnpg.io and velero.io each register kind Backup, so the bare short name resolves to Longhorn's empty set and prints 'No resources found' while CNPG backups exist. An on-call following the alert that fires BECAUSE backups look stale would have been told, with authority, that no backups exist at all — and might re-bootstrap a database over good ones. Fully qualify it. Co-Authored-By: Claude Opus 5 <[email protected]>
platform/cnpg
CloudNativePG — the PostgreSQL operator that runs Keycloak's DR-critical database.
- Governing ADR: ADR-0014 — IdP: Keycloak
- Serves: R-IDP-05 (DR-critical datastore), supports R-IDP-01
- Owner: WS-SEC
Why CNPG (not the Bitnami-bundled Postgres)
The original Keycloak stub used the Bitnami Keycloak chart with a bundled Bitnami PostgreSQL. Bitnami's free Docker Hub images were purged/relocated (DECISIONS-LOG F-KY1) — a deploy on stock Bitnami tags ImagePullBackOffs. CloudNativePG:
- ships from ghcr.io/cloudnative-pg (unaffected by the Bitnami purge),
- runs Postgres as a replicated
Clusteron Longhorn (3 instances → survives node loss), - gives declarative backup/restore (
ScheduledBackup+ Barman object store) — the clean DR hook for R-IDP-05 (off-cluster backup) once the backup target lands (OQ-BKP, Phase 4).
Controllers/configs split (F-MON1)
This directory installs only the operator + CRDs (controllers). The keycloak database Cluster
CR lives in ../../platform-config
(dependsOn: platform, wait) so the postgresql.cnpg.io CRDs exist before the CR applies.