Concept and mechanism
Start by drawing the paths the service actually needs: client, API, dependencies, DNS, and administration. A network rule helps only if the implementation enforces it and selectors match intended objects. NetworkPolicies add allowances. An old broad policy can retain access despite adding default-deny. In the same peer element, namespaceSelector and podSelector combine conditions; in separate elements, they represent alternatives. This difference changes who can connect without changing the port. Demonstrate the boundary with an authorized client and another that should be denied. Record source, destination, namespace, protocol, and result so APS can repeat verification.
Guided application
Also protect administrative endpoints and workload access to cloud metadata. Changing a port authenticates nobody. For Ingress terminating TLS and using downstream HTTP, also protect the backend segment when encryption through to the application is required; confirm controller capabilities. For service-to-service encryption, confirm the actual mechanism; permitting TCP 443 does not prove TLS. In an Istio sidecar mesh, inventory and migrate clients before moving from PERMISSIVE to STRICT. In a fictional banking project, include DNS, probes, and batch integrations in rehearsal to avoid discovering an outage during close. Hardening reports must match the distribution and version in use. Every exception should identify compensating control, owner, and closure condition, with technical evidence available to RUN.
An old allow-all rule still permits the test Pod: review the applicable set, not only the latest manifest.
Common pitfalls
Assumed deny precedence; namespace treated as firewall; port treated as TLS proof; report for another distribution.
Related topics: API identities and authorization · Linux hardening and kernel controls
A boundary exists when the authorized path works and the unauthorized path is actually denied.
Reference: Network policies · Kubernetes v1.35; current six-domain CKS outline