Pin apps-pg targets to railiance01 by cluster identity; seed RPF-WP-0020
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s

Two reachable clusters each carry a CNPG Cluster named apps-pg in a
namespace named databases. KUBECONFIG is an environment variable, so the
Makefile ?= default never applied, and RAILIANCE01_KUBECONFIG pointed at
config-hosteurope - a different cluster. Had the environment pointed at the
other reachable cluster instead of an unauthorized one, make apps-pg-deploy
would have applied RPF-WP-0019 connection limits, role timeouts and backup
config to the wrong cluster and reported success. The Unauthorized error was
the only thing that prevented it.

Filename selection cannot protect against this: both kubeconfigs resolve to
a 127.0.0.1 tunnel port and the environment wins either way. railiance01-guard
pins identity instead, comparing the live kube-system namespace UID against
RAILIANCE01_CLUSTER_UID, and fails closed on mismatch or unreachability. It
gates apps-pg deploy, backup-deploy, overflow-dry-run, status and shell.
Verified refusing on the wrong cluster, refusing when unreachable, and
passing on railiance01. Not global: db-status legitimately targets the other
cluster for gitea-db.

RPF-WP-0019 blocker note corrected - the cluster was never unreachable, our
wiring was wrong.

RPF-WP-0020 seeded for the pre-existing CCR test failure, which is two
unrelated problems: CCR-2026-0010 is an active lane missing its whole
openbao.auth block, and CCR-2026-0011 is an honest in-flight draft the suite
has no way to express.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
codex 2026-08-18 15:18:37 +02:00
parent 1cbde550b5
commit b1f973c2d5
4 changed files with 227 additions and 13 deletions

View file

@ -18,6 +18,30 @@ databases. It lives in the `databases` namespace and is owned by
into application namespaces, use it in S5 runtime configuration, or treat
it as a consumer credential.
## Which cluster this is
**Two reachable clusters each carry a CNPG `Cluster` named `apps-pg` in a
namespace named `databases`.** The one this document describes is
**railiance01** (k3s v1.35.1) — it also carries `platform-pg` and `forgejo-db`,
and holds both apps-pg consumers (`vergabe_db`, `coulomb_social_db`). The other
cluster carries `gitea-db` and only one apps-pg consumer.
Selecting the right one by kubeconfig filename is not safe: `KUBECONFIG` is an
environment variable that overrides the Makefile default, and both files
resolve to a `127.0.0.1` tunnel port. Every `apps-pg-*` target therefore runs
`railiance01-guard` first, which compares the live `kube-system` namespace UID
against `RAILIANCE01_CLUSTER_UID` and fails closed on mismatch or
unreachability.
```bash
make cluster-id # what KUBECONFIG currently selects
make railiance01-guard # assert it is railiance01, or refuse
```
If a target refuses, the fix is `KUBECONFIG=~/.kube/config-railiance01`, not
`--force` and not editing the pinned UID. `db-status` deliberately targets the
other cluster for `gitea-db`, which is why the guard is per-target.
## Consumer Onboarding
Each S5 application gets its own role, database, and runtime Secret. The