Skip to content

docs/ops: §8.2 egress lockdown — NetworkPolicy prereq + probe caveat + flip runbook (umbrella) #248

Description

@saadqbal

Context

The §8.2 training-pod egress lockdown (tracebloc/client-runtime#102) only actually blocks egress on a CNI that enforces egress NetworkPolicy. Verified on tb-client-dev-templates (EKS, self-managed VPC CNI with NetworkPolicy disabled): a DNS-only egress policy did not block https://example.com (probe returned 200). On such a fleet, flipping networkPolicy.training.allowExternalHttps=false is cosmetic — the rule renders but nothing is enforced (false sense of security).

What

Sharpen the docs + rollout guidance:

  • SECURITY.md §8.2 / §4.2: name the enforcing-CNI requirement concretely — Calico, Cilium, OpenShift OVN, or EKS VPC CNI only with the managed-addon enableNetworkPolicy=true (the bare DaemonSet flag is insufficient — needs the control-plane PolicyEndpoint controller).
  • Rollout checklist: add a per-fleet pre-flight egress probe as a required gate before flipping allowExternalHttps=false:
    # in a throwaway ns: run a curl pod, apply a DNS-only egress NetworkPolicy,
    # then `curl https://example.com` from the pod — it MUST fail. If it returns 200,
    # the CNI isn't enforcing egress; fix the CNI before enabling the lockdown.
    

Acceptance criteria

  • §8.2 lists the enforcing CNIs incl. the EKS enableNetworkPolicy=true prerequisite.
  • Rollout notes include the pre-flight probe as a gate.

Refs tracebloc/client-runtime#102. Found during the #102 G2 e2e (EC2/k3d passed; dev EKS surfaced the non-enforcement gap).

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions