Pin apps-pg targets to railiance01 by cluster identity; seed RPF-WP-0020
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:
parent
1cbde550b5
commit
b1f973c2d5
4 changed files with 227 additions and 13 deletions
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue