258 lines
12 KiB
Markdown
258 lines
12 KiB
Markdown
# S3 tenancy posture declaration
|
||
|
||
Work record: `RPF-WP-0018` T01
|
||
Declared: 2026-08-17
|
||
Framework: `net-kingdom/canon/standards/tenancy-posture_v0.1.md` (draft-8, proposed)
|
||
Contract version of this document: `1.0.0`
|
||
|
||
Machine-readable source: `tenancy.yaml`. This document preserves the review
|
||
reasoning; where a snippet and the root declaration differ, `tenancy.yaml` is
|
||
authoritative.
|
||
|
||
This is `railiance-platform`'s response to the Tenancy Posture ratification
|
||
test (§20.2): *"Each publishes its own posture vector as part of review. The
|
||
framework is validated by whether it can describe them accurately."*
|
||
|
||
It declares under §6 — **conformance is accuracy, not altitude**. Several
|
||
levels below are `0`. None of them is an admission of weakness, and §6 is
|
||
explicit that a declared low level is conformant while an unevidenced high
|
||
level is not.
|
||
|
||
**Every level below carries what §13 requires of it.** §13.1: a level is
|
||
claimed only with its evidence artifact present. §13.1a: at or below the
|
||
"no control" rung, a declaration requires a **stated reason** instead, because
|
||
there is nothing to overclaim at the bottom of a ladder. Floor claims here
|
||
carry `reason:`; claims above the floor carry `evidence:`. A claim with
|
||
neither would be the overclaim §6 prohibits.
|
||
|
||
Where `target` equals `current`, that is a **settled position, not a stalled
|
||
trajectory** — §6 permits a low level to be permanent by design, on the
|
||
`flex-auth` precedent (`I1` forever, because verifying its own inputs would
|
||
make it the identity provider its scope refuses to be). Those lines carry
|
||
`permanent: true` so §12's guard does not nag them.
|
||
|
||
## Why this is a vector *set* and not a vector
|
||
|
||
§5 asks a **service** for one level per axis. `railiance-platform` is an OAS
|
||
**layer** holding custody of several services with materially different
|
||
postures. A single vector for the repo would be an average of things that are
|
||
not alike, which is the inaccuracy §6 prohibits.
|
||
|
||
So: one vector per service, plus an explicit statement of what this repo owns
|
||
versus what it merely holds policy for. The distinction matters because
|
||
`RAILIANCE-WP-0012` and `RAILIANCE-WP-0015` deliberately moved the deployable
|
||
surface to the `rapp-*` repos while custody and policy stayed here.
|
||
|
||
| Service | This repo's relationship | Deployable owned by |
|
||
| --- | --- | --- |
|
||
| `apps-pg` | **owns** — cluster CR is `helm/apps-pg-cluster.yaml` | this repo |
|
||
| `forgejo-db` | **owns** — cluster CR is `helm/forgejo-db-cluster.yaml` | this repo |
|
||
| `openbao` | **custody and policy**; package extracted | `rapp-openbao` |
|
||
| `platform-pg` | **policy only**; consumer contract and grants here | `rapp-postgres` |
|
||
| Valkey, MinIO | declared capability, no live instance | — |
|
||
|
||
## The vectors
|
||
|
||
### `apps-pg` — shared cluster for S5 application databases
|
||
|
||
```yaml
|
||
tenancy:
|
||
service: apps-pg
|
||
role: storage-provider
|
||
current: { I: 0, A: 0, E: 0, P: "n/a", R: 0, V: 0 }
|
||
target: { I: 0, A: 0, E: 0, P: "n/a", R: 2, V: 1 }
|
||
service_class: interactive
|
||
reviewed: "2026-08-17"
|
||
gap:
|
||
R: "No backup is configured on this cluster at all — no barmanObjectStore,
|
||
no retentionPolicy, no deletion path. R0 is the accurate reading and
|
||
it is worse than it looks: R0 here means no recovery, not merely no
|
||
erasure policy. Closing this is the highest-value item this
|
||
declaration surfaced. Target R2 requires a backup target first."
|
||
notes:
|
||
- "I/A/E are 0 by construction, not by neglect. apps-pg holds no tenant
|
||
concept, carries no tenant claim, and applies no tenant predicate. The
|
||
tenant boundary for data on this cluster sits entirely in the consuming
|
||
S5 application. See the provider note below."
|
||
- "P is n/a rather than a number. See §P-axis note."
|
||
```
|
||
|
||
### `forgejo-db` — dedicated cluster for the forge
|
||
|
||
```yaml
|
||
tenancy:
|
||
service: forgejo-db
|
||
role: storage-provider
|
||
current: { I: 0, A: 0, E: 0, P: "n/a", R: 0, V: 0 }
|
||
target: { I: 0, A: 0, E: 0, P: "n/a", R: 2, V: 1 }
|
||
service_class: interactive
|
||
reviewed: "2026-08-17"
|
||
gap:
|
||
R: "Backup exists as a documented procedure (docs/forgejo-backup.md), not
|
||
as a declared retention with a published erasure horizon. R2 needs the
|
||
horizon published to the consumer, which is the point of the level."
|
||
notes:
|
||
- "Single-consumer cluster. Provides P2 to forgejo; is not itself at P2."
|
||
```
|
||
|
||
### `openbao` — platform secrets service
|
||
|
||
```yaml
|
||
tenancy:
|
||
service: openbao
|
||
role: credential-provider
|
||
current: { I: 0, A: 0, E: 0, P: 0, R: 0, V: 0 }
|
||
target: { I: 0, A: 0, E: 0, P: 0, R: 1, V: 1 }
|
||
permanent: [I, A, E]
|
||
service_class: latency-critical
|
||
reviewed: "2026-08-17"
|
||
reason:
|
||
I: "No tenant concept. OpenBao authenticates workloads via Kubernetes
|
||
auth; it never receives, parses or validates a NetKingdom tenant
|
||
identifier. Permanent by design — a secrets engine that resolved
|
||
tenant identity would be duplicating tenant-engine."
|
||
A: "No tenant context is carried, so there is nothing to bind. Permanent
|
||
by design, on the §6 flex-auth precedent."
|
||
E: "No tenant-keyed data. OpenBao holds workload secrets, not tenant
|
||
records."
|
||
P: "One instance, every consumer shares it. Single-node rail; §17
|
||
scaling demands apply."
|
||
R: "No retention position on audit device output or on KV version
|
||
history."
|
||
gap:
|
||
R: "R1 (platform default) is reachable cheaply and is not yet declared.
|
||
The only line here with a real trajectory."
|
||
```
|
||
|
||
**Correction, 2026-08-17.** This vector first declared `A: 2`. That was
|
||
wrong twice over and both errors are worth recording rather than quietly
|
||
editing.
|
||
|
||
*It was internally incoherent.* `E: 0` was justified on the ground that
|
||
OpenBao has no tenant dimension. §4.2's `A2` reads "a single local
|
||
authorization boundary; **tenant context** bound once, centrally" — the same
|
||
dimension. A declaration cannot invoke the absence of tenant context to claim
|
||
the floor on one axis and ignore it to claim a rung on the next.
|
||
|
||
*It was unevidenced at the moment of claiming.* §13.1 requires the artifact to
|
||
be present when the level is claimed, and none was cited. §13.1a would not
|
||
have rescued it: the table defines an artifact from `A2` upward, so `A2` is
|
||
precisely the first rung where the exemption stops applying.
|
||
|
||
The irony is the point. This repo routed a finding about unevidenced claims
|
||
in the same week it made one.
|
||
|
||
**What the corrected zeros conceal, and why the provider note below exists.**
|
||
`A: 0` now reads as though OpenBao performs no authorization. It performs a
|
||
great deal, it is central, and it is mechanically evidenced —
|
||
`scripts/openbao-verify-token-grants.py` mints a scoped child token, asserts
|
||
it *can* sign with `ssh/sign/agt-role`, and asserts it *cannot* read policy
|
||
metadata, then revokes by accessor. That is exactly the shape §13 asks for at
|
||
`A2`: choke point identified, unbound request refused. It is pointed at the
|
||
**consumer** boundary, and none of the tenancy axes has anywhere to put it.
|
||
|
||
That evidence is therefore cited under the provider statement rather than
|
||
against a consumer axis. Consumer separation in OpenBao is structural — a
|
||
workload token's policy cannot address another workload's path at all, which
|
||
is `E4`-shaped machinery — and the framework's honest application scores it
|
||
`0`.
|
||
|
||
`A3` is not a target: a PDP in the credential path would put `flex-auth` on
|
||
OpenBao's availability path and OpenBao on `flex-auth`'s.
|
||
|
||
### `platform-pg` — policy relationship only
|
||
|
||
Declared by `rapp-postgres`. This repo does not restate it. What this repo
|
||
declares about it is in `docs/placement-policy.md`: the rule, the placement
|
||
owner per consumer, and the triggers. The numbers — `instances: 1`,
|
||
`max_connections: 100`, `1Gi`, `retentionPolicy: 30d` — are `rapp-postgres`'s
|
||
cluster CR and its declaration to make.
|
||
|
||
## The P-axis note — why two entries are `n/a`
|
||
|
||
The P ladder describes **which substrate holds a tenant's data**, from the
|
||
point of view of the workload whose data it is. `apps-pg` and `forgejo-db` are
|
||
the substrate. Asking a cluster what its own placement level is has no
|
||
well-formed answer: `apps-pg` *provides* P1 to each of its consumers, and
|
||
`forgejo-db` *provides* P2 to forgejo, but neither *is* at a level.
|
||
|
||
Declaring `P: 1` for `apps-pg` would read as though the cluster had a
|
||
placement, and a later reader would use it to argue about isolation. `n/a`
|
||
plus the provider statement is the accurate canonical form.
|
||
|
||
For `apps-pg`, the provider statement is now backed by live evidence dated
|
||
2026-08-20. A separately restored cluster recovered both consumer databases in
|
||
56 seconds from the governed 30-day backup path, establishing current R2/V1
|
||
for the provider. The 14-assertion isolation harness then proved own-database
|
||
access, cross-database denial, both role timeouts, the 20-connection boundary,
|
||
and peer availability while one role exhausted its allowance. The measured
|
||
wall-time increase is recorded but is not a latency SLO. Evidence:
|
||
`docs/evidence/RPF-WP-0019-backup-restore-2026-08-20.md` and
|
||
`docs/evidence/RPF-WP-0019-isolation-2026-08-20.md`.
|
||
|
||
## Finding adopted by `net-kingdom`
|
||
|
||
**The six ladders describe a consumer of storage. They do not describe a
|
||
provider of it.**
|
||
|
||
**Resolved in draft-7 and formalised in draft-8.** Decision 5.5 adopted the
|
||
provider declaration; the draft-8 schema standardises `available`, `maximum`,
|
||
conditions and evidence per axis. The canonical form is now in `tenancy.yaml`.
|
||
|
||
**Narrowed on re-reading, 2026-08-17.** An earlier version of this finding
|
||
claimed the framework had no way to say "this zero is structural, not weak".
|
||
That was wrong: §6 says exactly that, and §13.1a supplies the mechanism —
|
||
`target` equal to `current` with a stated reason is a settled position, on the
|
||
`flex-auth` `I1`-forever precedent. This declaration now uses it. Half of the
|
||
finding is withdrawn.
|
||
|
||
What survives is the other half, and it is not expressible: a provider cannot
|
||
state **what level it makes reachable for the workloads it holds**, nor record
|
||
a control that is real, mechanically evidenced, and simply not on any of the
|
||
five consumer axes.
|
||
|
||
Every service above scores at or near zero on I, A and E, and in each case for
|
||
the same structural reason rather than for a weakness: a storage or credential
|
||
platform has no tenant dimension of its own. It is exactly as strong or weak as
|
||
its consumers make it. The framework anticipates this in §3.3 and in the
|
||
"newly absorbed repo" example, but the vector shape gives a provider no way to
|
||
say the useful thing, which is not *what level am I at* but **what level do I
|
||
make reachable for the workloads I hold**.
|
||
|
||
The concrete case is the `openbao` E line. `E: 0` is literally correct and
|
||
actively misleading — the mechanism in place is credential-scoped structural
|
||
separation, the same machinery E4 describes, pointed at a consumer boundary
|
||
rather than a tenant one. A reader scanning a table of E values would rank
|
||
OpenBao below a service doing per-query filtering in application code, which
|
||
inverts the actual security position.
|
||
|
||
**Proposed amendment at draft-5, offered as the first correction from review rather than
|
||
from research (§Status observes that every correction so far came from research
|
||
or relocation):** add a **provider declaration** beside the posture vector — a
|
||
platform service states, per axis, the maximum level it makes reachable and
|
||
what the consumer must do to reach it. For `apps-pg` that is: E4 unreachable
|
||
(shared credential per consumer, no per-tenant credential), E3 reachable once
|
||
the GUC contract exists, R2 blocked on a backup target. That is the sentence a
|
||
consumer actually needs, and no arrangement of the consumer ladders produces
|
||
it. Draft-8 adopted and standardised that amendment; the root declaration is
|
||
now authoritative.
|
||
|
||
This is offered as an addition, not a replacement. The consumer vector is
|
||
right for consumers, and this repo is not asking for the ladders to be
|
||
renumbered.
|
||
|
||
## What this repo accepts
|
||
|
||
- The P0–P4 ladder as written, by reference. It describes our estate correctly.
|
||
- §8.1's monitoring obligation, with the deferrals stated in
|
||
`docs/placement-policy.md` rather than silently.
|
||
- §9.1 — no static long-lived database credentials above E0. Already how the
|
||
credential broker works; no change needed.
|
||
- §10.2 — quota disclosure. Landed in `docs/s3-consumer-interfaces.md` 1.1.0.
|
||
- §6 — accuracy over altitude, which is why this document declares four zeros.
|
||
|
||
## Review interval
|
||
|
||
Six months, or on any of: a service moving placement level, a backup target
|
||
becoming available, or the framework reaching `accepted`. Next review due
|
||
**2027-02-17**.
|