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

id	type	title	date	verified_by	method	findings	result
RISK-V-0001	verification	flex-auth NetworkPolicy, verified against the live cluster	2026-08-20	risk-nexus	read-only kubectl against railiance01	RISK-F-0001 RISK-F-0002	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.

"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.