--- 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. --- ## Reconciled — 2026-08-21: ingress does reach that pin, and both facts hold `ops-warden` answered ahead of their default date, and the answer is **no** — enabling the gate would not have stopped signing. **Their evidence.** `GET http://127.0.0.1:19090/healthz` returns 200 through the `flex-auth-ops-warden-railiance01` ops-bridge tunnel — a plain `-L` forward from the railiance01 node to ClusterIP `10.43.1.165:8080` — answering continuously since 2026-08-19, *after* the deny-all policy was created at 12:47:18Z that day. A full authenticated `/v1/check` through it returned 200, `effect=allow`, `decision:f3f7c88f9585582a`. **The reconciliation, which keeps both observations true.** NetworkPolicy governs pod-to-pod traffic. `ops-warden` is not a pod: `warden sign` runs on the operator workstation and reaches the pin through an SSH tunnel terminating on the node, so the traffic originates from the **node**, not from a pod. A `podSelector`-scoped ingress rule does not constrain that path. A supporting datapoint neither they nor this register gathered: `net-kingdom` reported on 2026-08-20 that a `tenant-engine` pod could not reach the `user-engine` pin at all, `Errno 111`, attributed to NetworkPolicy. If that holds, pod-sourced ingress *is* enforced and node-sourced is not — the expected shape rather than an anomaly. **So the deny-all was deliberate and correctly scoped**, not a rollout artifact: `flex-auth` set `consumer.isolated: true` on that pin, isolated until there is an in-cluster PEP namespace to admit. ### What this verification got right, and what it got wrong Right: reading the live policy, reporting the discrepancy, and routing it to both owners **before either flipped a switch**. The observation was accurate. Wrong: the inference. "Ingress policyTypes with no rules means nothing reaches this pin" is true of pod traffic and this register presented it without that qualifier. `docs/method/verification.md` says a verification is evidence and not a ruling; this one drifted toward a ruling and was corrected by the owner inside a day, which is the system working. ### The caveat `ops-warden` refused to paper over, carried here Their evidence proves ingress reaches the pin. It does **not** prove NetworkPolicy is enforced everywhere it should be. **Anyone relying on a NetworkPolicy to isolate something reachable from a node should probe that assumption.** Nobody has. It is not a finding — no defect is established — and it is exactly the shape of thing that becomes one the first time somebody checks.