tegwick
e482423523
RISK-F-0006 fixed and public — railiance-platform's restore evidence was read, not taken: 56s restore, all 13 coulomb_social row counts matching, plus the BestEffort QoS this register had graded on, plus a failed first WAL attempt recorded alongside the successful one. RISK-F-0004 high -> medium. tenant-engine corrected in both directions: payloads are returned (worse than graded) but there is no HTTP event-read route, so the live network-reachable read this register wrote down does not exist. L3 was a reachability claim inherited from a summary and never tested. RISK-F-0002: reading (c) confirmed — nothing blocks policy.enabled, it is off by decision. ADR-0006 retires it in favour of zone-scoped enforcement. Ruled: the framing is superseded, the risk is not. A control retired before its replacement exists is still an absent control. The successor's blocker is 26 of 27 lanes having no identifiable workload, which is RISK-N-0004 with a number on it. RISK-F-0009: uncovered count 8 -> 6, corrected by the reporter against themselves; the token was never expired; and the deployed policy differs from the file, which moves 'a file is not a safe proxy for the server' from suspicion to evidence and amends verification.md — including the admission that fix_tracker.py reads records, and a record can be stale. RISK-V-0001 reconciled: ops-warden reaches the pin from the node through a tunnel, so a podSelector ingress rule does not constrain it. The observation was right and the inference was not. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
150 lines
6.6 KiB
Markdown
150 lines
6.6 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.
|
|
|
|
---
|
|
|
|
## 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.
|