tegwick
97fcc56a4d
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>
100 lines
4.1 KiB
Markdown
100 lines
4.1 KiB
Markdown
---
|
|
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.
|