/sota-network-security

name: sota-network-security
description: >-
  State-of-the-art network security as a discipline (2026) for BOTH
  designing/building secure networks AND auditing segmentation and exposure.
  Use for zero-trust architecture, network segmentation and blast-radius
  control, Kubernetes NetworkPolicy/CiliumNetworkPolicy depth, service mesh
  and mTLS, edge/ingress/egress security (WAF, egress allowlisting,
  metadata-endpoint blocking), DNS/TLS/PKI transport and certificate
  lifecycle, and remote access (WireGuard, ZTNA, bastion vs identity-aware
  proxy). Triggers — network security, zero trust, ZTNA, microsegmentation,
  east-west traffic, lateral movement, NetworkPolicy, default-deny, Cilium,
  Hubble, service mesh, mTLS, Istio, Linkerd, SPIFFE, ingress, egress, WAF,
  CRS, Coraza, egress gateway, FQDN allowlist, IMDS, 169.254.169.254, DNS
  firewall, DNSSEC, DoH, TLS 1.3, ACME, step-ca, private CA, WireGuard,
  bastion, identity-aware proxy, DDoS, segmentation audit. Owns SECURITY posture on
  top of cloud network setup (sota-cloud-infrastructure owns VPC/subnet/DNS
  setup).

SOTA Network Security

Purpose

This skill encodes the 2026 state of the art for **network security as a discipline**: how to verify rather than trust, contain blast radius, encrypt traffic in motion, control what enters and leaves, and secure the naming and transport plumbing (DNS, TLS, PKI). Every rule exists to prevent a real failure class — lateral movement after one foothold, plaintext credentials on the wire, an over-broad rule that exposes a secrets store to the world, a renewal nobody automated, or an SSRF that reaches the cloud metadata endpoint.

**Ownership — reference siblings, do not duplicate:**

• **sota-cloud-infrastructure** (rules/03 networking) owns cloud-provider network *setup*: VPC/subnet

layout, CIDR/IPAM, route tables, LB/CDN provisioning, registrar hygiene, DNS zone setup. **This skill owns the security posture layered on top** and the on-prem / Kubernetes / mesh side.

• **sota-kubernetes** owns admission control and RBAC — *where NetworkPolicy is admitted and CNI

enforcement is wired*; this skill owns the policy *content and depth*.

• **sota-identity-access** owns SPIFFE/SPIRE workload identity issuance, ZTNA user identity, and the

identity-aware proxy's auth plane; this skill consumes those identities for network authorization.

• **sota-detection-engineering** owns network IDS (Suricata), DNS-exfil detection, and flow-log

detection content; this skill produces the telemetry (Hubble flows, flow logs) it consumes.

• **sota-sandboxing** (rules/02–03) owns single-host nftables/seccomp and container hardening; this

skill owns the inter-host / cluster-wide fabric.

• **sota-code-security** (rules/01 SSRF, rules/05 CORS/CSP), **sota-api-design** (rules/07 rate

limiting), **sota-secrets-management** (TLS private keys) — referenced where they intersect.

BUILD mode

Use when designing or extending a secure network (zero-trust plan, NetworkPolicy set, mesh rollout, ingress/egress controls, PKI/DNS posture, remote access).

1. **Establish context first:** on-prem vs cloud vs hybrid; CNI and orchestrator (e.g. on-prem Talos K8s + Cilium); existing PKI (step-ca), edge (Caddy + CRS WAF, Cloudflare in front); data sensitivity; who needs remote access. A 3-node homelab and a regulated fleet get different answers from the same rules. 2. **Read the matching rules file before writing config.** Segmentation (rules/02) precedes policy detail; identity-aware access (rules/01) frames everything. 3. **Default-deny in both directions, always.** Ingress *and* egress deny by default, per namespace and per zone. Every allow is explicit, justified in a comment, and references identity (workload identity, label selector, SG/service account) — never a bare CIDR or `world` entity **wherever the policy language can express identity**. Where it genuinely cannot — vanilla NetworkPolicy has no identity selector for a destination *outside* the cluster — a tight `ipBlock` is a **documented exception, not a default**: name the destination and the reason, and prefer a CNI that can (rules/03 §3). Inside the cluster there is no exception: pod IPs are recycled, so a CIDR there silently re-points the allow. 4. **Encrypt every hop that crosses a trust boundary.** No plaintext credentials, JWTs, or DB traffic on the pod/internal network — mTLS via mesh or TLS terminated close to the workload. 5. **State the failure mode and the blast radius** of what you propose. "If this pod is popped, it can reach X and Y" belongs in the design, not the postmortem. 6. **Produce policy as code** (NetworkPolicy/CiliumNetworkPolicy YAML, mesh AuthorizationPolicy, nftables, ACME/cert-manager manifests) — never click-ops, never "we'll lock it down later."

AUDIT mode

Use when reviewing an existing network for segmentation gaps and exposure.

Process: inventory the fabric (zones, namespaces, CNI policies, mesh config, ingress/egress paths, DNS zones, certs, remote-access entry points); walk the Audit checklist at the end of each relevant rules file; **confirm reachability before reporting** — render the effective policy, run a probe (`kubectl exec ... curl`, Hubble flow query, `nmap`), read the actual rule. Do not infer exposure from a resource name.

Severity conventions

| Severity | Meaning | Examples | |---|---|---| | **Critical** | External or any-workload party can reach a sensitive service or read traffic now | Secrets store / DB / registry reachable from a `world`/`0.0.0.0/0` entity; plaintext DB creds or JWTs on the wire (sniffable from any pod); SSH open to the internet on a prod host; admin/dashboard reachable unauthenticated from outside | | **High** | One foothold from broad lateral movement, or a guaranteed exposure/outage class | "Default-deny" that actually allows all intra-cluster traffic; no egress control (free C2/exfil path); flat L2/L3 network with no segm