docs(security): record tb-client-dev-templates EKS substrate-verified seal row (client-runtime#199)

[saqlainsyed007]

What

Records the substrate-verified SEAL-CHECK row for the dev EKS fleet tb-client-dev-templates, per the RFC-0003 D6 flip runbook on client-runtime#199 (which explicitly permits pre-verifying a fleet's substrate row without flipping). Docs-only; read-only cluster inspection — no chart/config/cluster change.

Why held, not flipped

The dev flip was scoped to CV / non-NLP fleets only. On dev there is exactly one client-runtime fleet — tracebloc / tracebloc-templates — and it is a mixed template-validation fleet whose ingest configs include substantial NLP (masked_language_modeling ×36, text_classification ×15, token_classification, sentence_pair_classification, causal_language_modeling, embeddings) alongside CV/tabular/time-series. The jobs-manager sets noTRANSFORMERS_OFFLINE / HF_HUB_OFFLINE, so NLP templates still runtime-fetch HuggingFace today; sealing egress now would break them by design (the #1501 gate). Per the runbook guard, NLP fleets are not flipped per-fleet — so the flip is held until HF runtime-fetch support is removed.

Substrate evidence (2026-08-24)

kube-system/aws-node runs the VPC CNI network-policy agent — aws-network-policy-agent:v1.2.7-eksbuild.2, --enable-network-policy=true, NETWORK_POLICY_ENFORCING_MODE=standard. The cluster does enforce NetworkPolicy egress (chart's 60s retry covers standard-mode reconcile), so the fleet is sealable in principle and the egress-enforcement probe is expected to PASS once flipped.

Also noted: this fleet currently sets networkPolicy.training.enabled: false (no netpol rendered — kubectl get netpol -A empty), so any future flip must additionally set networkPolicy.training.enabled=true before routeWorkloads=true / allowExternalHttps=false.

🤖 Generated with Claude Code

---

Note

Low Risk
Documentation-only update to SEAL-CHECK.md; no chart, cluster, or runtime behavior changes.

Overview
Records that the EKS training-egress guarantee is substrate-verified (not fully sealed) for the tb-client-dev-templates fleet, matching the existing k3d pattern.

The §8.3 matrix EKS cell now cites VPC CNI netpol agent v1.2.7 (--enable-network-policy=true, standard mode, 2026-08-24). A new status section is the single record of that read-only inspection: the cluster can enforce NetworkPolicy egress, but the full-chart egress-enforcement probe is held (NLP HuggingFace runtime-fetch; training NetworkPolicy currently disabled). The fleet stays UNSEALED until the lockdown flip.

^{Reviewed by Cursor Bugbot for commit ab586a5. Bugbot is set up for automated code reviews on this repo. Configure here.}

[LukasWodka]

Substrate claims independently confirmed from a second source — one thing the record is missing

This is a PR whose claims are the deliverable, so I checked them against AWS rather than re-reading the prose. The EKS addon API is an independent source from the DaemonSet spec you inspected, and it agrees:

$ aws eks describe-cluster --name tb-client-dev-templates
{ "status": "ACTIVE", "version": "1.36", "vpc": "vpc-08a4ede4dc64572c4" }
$ aws eks describe-addon --cluster-name tb-client-dev-templates --addon-name vpc-cni
{ "version": "v1.20.5-eksbuild.1",
"status": "ACTIVE",
"config": "{\"enableNetworkPolicy\":\"true\"}" }

• amazon-k8s-cni:v1.20.5-eksbuild.1 — exact match with the recorded image.
• --enable-network-policy=true — confirmed from the addon's own configurationValues, so the flag isn't just a container arg someone could have read off a stale pod.
• mode standard — corroborated indirectly and worth stating that way: configurationValues sets onlyenableNetworkPolicy, so nodeAgent.enforcingMode is unset and takes the addon default, which is standard. Same conclusion by a different route.
• enforcementProbeTimeoutSeconds: 60 is genuinely the chart default (client/values.yaml:302), so the sentence about the retry covering the standard-mode reconcile window is accurate rather than aspirational.

The cluster is also in vpc-08a4ede4dc64572c4, which is the same VPC I've been measuring on backend#2068 this morning — consistent with the topology recorded there (three public subnets, one main route table, no NAT).

Holding UNSEALED rather than claiming a seal is the right call, and the reason is the interesting part: the fleet is mixed template-validation with substantial NLP, and with no TRANSFORMERS_OFFLINE / HF_HUB_OFFLINE injected, sealing egress would break HuggingFace runtime-fetch by design. Recording "substrate verified, probe not run, fleet UNSEALED" is exactly the distinction a seal document exists to keep straight — a substrate that can enforce is not a fleet that does.

---

One finding, non-blocking: the record states the state but not the reason, and here the reason is the load-bearing half.

this fleet currently sets networkPolicy.training.enabled: false … so a future flip must additionally set networkPolicy.training.enabled=true

The chart default is true (client/values.yaml:274). So this isn't a fleet that hasn't got around to enabling it — it's an explicit override away from the chart's default posture, and the doc's phrasing reads like a routine extra checkbox on the flip. It might be the riskiest step in it: if the training NetworkPolicy was turned off because it broke something on this fleet, re-enabling it is the change that needs the care, and the two lockdown flags are the easy part.

For a document whose whole job is telling a future operator what they're walking into, one clause would close it — either why it's off, or "reason not established; determine before flipping". Right now a reader could reasonably assume false is the norm and that flipping is additive.

Not approving yet:Unit tests and Bugbot are still IN_PROGRESS. Nothing else outstanding from me.

[LukasWodka]

Approving — green at ab586a5e, substrate claims confirmed from a second source

Gate: 15/15 checks pass, MERGEABLE, no threads, no change-request.

Since this is a PR whose claims are the deliverable, I checked them against AWS rather than re-reading the prose — and the EKS addon API is independent of the DaemonSet spec you inspected. It agrees:

$ aws eks describe-cluster --name tb-client-dev-templates
{ "status": "ACTIVE", "version": "1.36", "vpc": "vpc-08a4ede4dc64572c4" }
$ aws eks describe-addon --cluster-name tb-client-dev-templates --addon-name vpc-cni
{ "version": "v1.20.5-eksbuild.1", "status": "ACTIVE",
"config": "{\"enableNetworkPolicy\":\"true\"}" }

amazon-k8s-cni:v1.20.5-eksbuild.1 is an exact match; --enable-network-policy=true is confirmed from the addon's own configurationValues rather than a container arg off a possibly-stale pod; and mode standard follows because configurationValues sets onlyenableNetworkPolicy, leaving nodeAgent.enforcingMode at the addon default. Same conclusion by a different route. enforcementProbeTimeoutSeconds: 60 is genuinely the chart default (client/values.yaml:302), so the sentence about the retry covering the standard-mode reconcile window is accurate rather than aspirational.

Recording it as substrate-verified-but-UNSEALED is the right call, and it's the distinction this document exists to keep straight: a substrate that can enforce is not a fleet that does. The held-not-flipped reasoning is sound — a mixed template-validation fleet with substantial NLP, and no TRANSFORMERS_OFFLINE / HF_HUB_OFFLINE injected, so sealing egress would break HuggingFace runtime-fetch by design.

---

Carrying my one note forward as a follow-up rather than holding the PR for it. The record says the fleet sets networkPolicy.training.enabled: false and that a future flip must set it true — but the chart default is true (client/values.yaml:274), so that's an explicit override away from the default posture, not a box left unticked. If the training NetworkPolicy was disabled because it broke something on this fleet, re-enabling it is the step that needs care and the two lockdown flags are the easy part.

One clause would close it — why it's off, or "reason not established; determine before flipping". As written, a reader could reasonably assume false is the norm and that the flip is purely additive. Worth adding whenever you next touch the section; the PR is a clear improvement either way.

[aptracebloc]

Docs-only seal-check record. Reviewed the substrate-verification note — it's careful and honest: it marks tb-client-dev-templates substrate-VERIFIED (VPC CNI netpol agent v1.2.7, --enable-network-policy=true, mode standard) but deliberately keeps the fleet UNSEALED for egress, with the two real reasons spelled out (NLP templates still runtime-fetch HuggingFace with no TRANSFORMERS_OFFLINE, so sealing would break them per the #1501 gate; and networkPolicy.training.enabled=false means a flip needs that set first). The matrix cell and the new section agree. No overclaiming.

LGTM.

— drafted with Claude Code