coulomb/risk-nexus
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
risk-nexus/docs/verifications/2026-08-20-flex-auth-networkpolicy.md
tegwick 97fcc56a4d 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>
2026-08-20 08:46:06 +02:00

4.1 KiB
Raw Blame History

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.