/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, DNS firewall, DNSSEC,
  DoH, TLS 1.3, ACME, step-ca, private CA, bastion, identity-aware proxy,
  DDoS, email spoofing, SPF, DKIM, DMARC. 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](../sota-cloud-infrastructure/SKILL.md)** ([rules/03](../sota-cloud-infrastructure/rules/03-networking.md) 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](../sota-kubernetes/SKILL.md)** 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](../sota-identity-access/SKILL.md)** 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](../sota-detection-engineering/SKILL.md)** 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](../sota-sandboxing/SKILL.md)** ([rules/02](../sota-sandboxing/rules/02-linux-os-hardening.md)–03) owns single-host nftables/seccomp and container hardening; this

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

• **[sota-code-security](../sota-code-security/SKILL.md)** ([rules/01](../sota-code-security/rules/01-input-injection.md) SSRF, [rules/05](../sota-code-security/rules/05-web-security.md) CORS/CSP), **[sota-api-design](../sota-api-design/SKILL.md)** ([rules/07](../sota-api-design/rules/07-security-operations.md) rate

limiting), **[sota-secrets-management](../sota-secrets-management/SKILL.md)** (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. an on-prem cluster with an eBPF CNI such as Cilium); existing PKI (e.g. a private CA such as step-ca), edge (e.g. a reverse proxy with a CRS WAF behind a CDN); 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](rules/02-segmentation-blast-radius.md)) precedes policy detail; identity-aware access ([rules/01](rules/01-zero-trust-architecture.md)) 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](rules/03-k8s-network-policy.md) §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

**Coverage:** every `rules/` file's Audit checklist applies in AUDIT mode. Mark one *not applicable* only with its reason in the report — never skip a file because the thing it checks for is absent, since that absence may be the finding.

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 z