RISK-WP-0004-T05: establish what this register can verify, by trying it

Cluster reads work from this host; OpenBao returns 403, the same wall
ops-warden hit. So the register can check what the cluster admits and
cannot check what the secret store permits, and every grade touching an
OpenBao policy is a grade on a document. That asymmetry is recorded
rather than closed: a risk register holding production secret-store
access would have traded a verification problem for a worse one.

RISK-V-0001 is the first verification. It confirms RISK-F-0001's ingress
claim against the live cluster — the first grade here standing on
evidence this repo gathered — contradicts the 'egress: []' claim, which
live shows as 443/6443 to anywhere, and surfaces a third policy created
the day of the fix whose Ingress policyType carries no rules, which bears
on whether enabling ops-warden's gate would fail closed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/verifications/2026-08-20-flex-auth-networkpolicy.md

@@ -0,0 +1,100 @@
+---
+id: RISK-V-0001
+type: verification
+title: "flex-auth NetworkPolicy, verified against the live cluster"
+date: "2026-08-20"
+verified_by: risk-nexus
+method: "read-only kubectl against railiance01"
+findings: [RISK-F-0001, RISK-F-0002]
+result: "ingress claim confirmed; egress claim contradicted; one policy not previously reported"
+---
+
+# RISK-V-0001 — the NetworkPolicy, actually looked at
+
+`RISK-F-0001` was graded twice on a fact nobody had checked. `flex-auth` said
+so honestly — "I can tell you what is specified, not what is admitted" — and
+named the command that would settle it. This register ran that command.
+
+```
+kubectl -n flex-auth get networkpolicy -o json
+```
+
+## What is confirmed
+
+**The ingress claim is exactly right**, and now rests on the live cluster
+rather than a manifest:
+
+| Policy | Ingress from | Port |
+| --- | --- | --- |
+| `flex-auth-user-engine` | `namespaceSelector: user-engine` **and** `podSelector: user-engine` | 8080/TCP |
+| `flex-auth-tenant-engine` | `namespaceSelector: tenant-engine` **and** `podSelector: tenant-engine` | 8080/TCP |
+
+Created 2026-08-09 and 2026-08-08 respectively — eleven days old, predating the
+caller-authentication work, as `flex-auth` said. The reachable set during the
+`A0` period was one workload per Deployment, not the cluster.
+
+`RISK-F-0001`'s `L2` grade is therefore **verified**, not inferred. That is the
+first grade in this register standing on evidence this repo gathered itself.
+
+## What is contradicted
+
+`flex-auth` stated `egress: []` — "empty, i.e. none at all". **Live, all three
+policies permit egress to any destination on TCP 443 and 6443**, with no `to`
+selector.
+
+```json
+"egress": [{"ports": [{"port": 443, "protocol": "TCP"},
+                      {"port": 6443, "protocol": "TCP"}]}]
+```
+
+6443 is the Kubernetes API server, which ADR-0004's TokenReview needs, so its
+presence is unsurprising. 443 to anywhere is a different statement from "none
+at all".
+
+This does **not** change `RISK-F-0001`'s grade — the finding is about who can
+reach the decision surface, and ingress is what governs that. It does change
+the evidence base, and it matters because the same sentence has been repeated
+into two records.
+
+Routed to `flex-auth` as a question rather than a correction: does the
+committed manifest say `egress: []`, in which case the deployed policy differs
+from the file, or did the message misdescribe the manifest? Only they can say
+which, and the two answers mean very different things.
+
+## What was not previously reported
+
+A **third** policy exists: `flex-auth-ops-warden`, created 2026-08-19T12:47Z —
+the same day `flex-auth` reported the fix.
+
+```
+podSelector: app.kubernetes.io/name=flex-auth-ops-warden
+policyTypes: [Ingress, Egress]
+ingress:     (no rules)
+egress:      443, 6443
+```
+
+`policyTypes` includes `Ingress` with no ingress rules, which in Kubernetes
+means **deny all ingress**. On its face, nothing can reach that pin.
+
+**This bears directly on `RISK-F-0002`.** The remaining question there is
+whether enabling `policy.enabled` breaks signing on availability grounds now
+that the attestation hazard has lifted. If the flex-auth pin that `ops-warden`
+is meant to call admits no ingress, then enabling a `fail_closed` gate against
+it would fail closed — every `warden sign` would stop.
+
+The register is **not** concluding that. A policy may be mid-rollout, the pin
+may not be the one `ops-warden` targets, and a second policy elsewhere may
+admit the traffic. What the register is doing is putting the observation in
+front of both owners before either of them flips a switch, which is precisely
+what `RISK-F-0002` exists to prevent happening blind.
+
+## Limits of this verification
+
+- Read-only, and a point-in-time snapshot of 2026-08-20.
+- It confirms what the API server admits **as specified**. Whether the CNI
+  enforces NetworkPolicy at all is a cluster property this check does not
+  establish, and `flex-auth` was right to flag it.
+- OpenBao could not be checked: `bao token lookup` and
+  `bao policy read agent-high-risk-boundary` both return **403 permission
+  denied** from this host, the same wall `ops-warden` hit. `RISK-F-0009`
+  therefore still rests on file comparison.