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