Skip to main content
Source

This page is generated from devops-agent/eks-security/references/workload-security.md. Edit the source, not this page.

Layer 3 — Workload Security (Pod Security + Network)

Two compounding concerns: pod security posture (what a pod is allowed to do) and network policy (what a pod is allowed to talk to).

Pod security — three layers that compound​

3a — Pod Security Admission (PSA, Kubernetes-native)
     restricted profile   → MOST WORKLOADS (default for new namespaces)
     baseline profile     → workloads needing limited extra privileges
     privileged profile   → AVOID; only system / kube-system

3b — Custom policy engine (choose ONE)
     Kyverno              → Kubernetes-native, no Rego DSL; preferred for new adoption
     OPA Gatekeeper       → Rego-based; for teams with existing OPA/Rego expertise

3c — Image admission control (a sub-rule of 3b)
     Kyverno verifyImages → block unsigned / high-severity images at admission
  • PSA restricted is the default recommendation for production namespaces. Roll out in audit mode first, confirm no workloads break, then switch to enforce.
  • Kyverno is preferred for new adoption (Kubernetes-native YAML policies, no Rego). OPA Gatekeeper suits teams already invested in Rego/OPA. Both are CNCF.
  • PodSecurityPolicy (PSP) was removed in Kubernetes 1.25+ — clusters on 1.25+ have no PSP. PSA + Kyverno/OPA is the canonical replacement. Do not recommend PSP.

References: Pod Security Admission (Kubernetes) · Pod Security Standards · aws/aws-eks-best-practices OPA policies · Kyverno policy library.

Network policy on EKS — VPC CNI is now native​

  • VPC CNI native NetworkPolicy — the AWS VPC CNI enforces standard Kubernetes NetworkPolicy without a third-party CNI. Default-deny on production namespaces, then allowlist required ingress/egress. Reference: Limit pod traffic with Kubernetes network policies.
  • Enhanced capabilities (current versions matter). EKS added cluster-wide enforcement via ClusterNetworkPolicy and FQDN-based egress policies (filter egress to cluster-external destinations by domain name). Availability specifics, framed precisely: the VPC CNI v1.21 managed add-on with these features is offered for Kubernetes 1.29+ (a practical packaging constraint, not a hard API gate — the base NetworkPolicy prerequisites still list 1.26.7/1.27.4); use VPC CNI v1.21.0+, with v1.21.1+ recommended (v1.21.0 has a documented Network Policy Agent defect); ClusterNetworkPolicy works in all cluster launch modes, while DNS/FQDN-based policies are supported only on EKS Auto Mode-launched EC2 instances. References: Enhanced network security policies (Dec 2025) · Enhanced network policy capabilities · DNS and Admin Network Policies.
    • CRD specifics. Both CRDs live in apiGroup networking.k8s.aws/v1alpha1 (alpha, AWS's own group, not upstream policy.networking.k8s.io) on VPC CNI v1.21.1+ (Kubernetes 1.29+ is the Auto Mode / new-cluster rollout floor, not a ClusterNetworkPolicy gate). ClusterNetworkPolicy is cluster-scoped with a tier: Admin | Baseline field (the Admin tier is evaluated first and cannot be overridden by namespace policies; Baseline is an overridable default). ApplicationNetworkPolicy is a namespaced EKS Auto Mode CRD that supports all standard NetworkPolicy fields and adds an FQDN-based egress filter; the FQDN egress applies only on Auto Mode nodes. Egress policies must allow TCP and UDP port 53 to the CoreDNS service IP or DNS and FQDN filtering breaks. See security-runtime-network.md for detail.
  • EKS Auto Mode supports NetworkPolicy out of the box. Reference: Network policies with EKS Auto Mode.
  • Cilium CNI — not supported on EKS Auto Mode (as of 2026-07-17); available on self-managed / managed node groups for advanced features (eBPF, Hubble, Cluster Mesh).

Security Groups for Pods (SGP)​

For compliance workloads needing network-layer isolation between pods (e.g., PHI-handling pods isolated from non-PHI pods in the same cluster), attach VPC Security Groups at pod granularity via the VPC CNI trunk/branch-ENI feature. Reference: Leveraging CNI custom networking alongside Security Groups for Pods.

SGP limitations — material for a compliance design (don't promise isolation it doesn't deliver). Per Security groups for Pods:

  • Not supported on EKS Auto Mode or Windows nodes (hard exclusion) — if you need pod-SG isolation, you can't be on Auto Mode.
  • Same-node traffic: in standard mode, pod SG rules are not applied to traffic between pods on the same node; the default strict mode does apply them but routes all pod traffic through the VPC, which breaks NodeLocal DNSCache and externalTrafficPolicy=Local.
  • No t-family instance support; trunk/branch ENIs reduce pod density per node. Combine SGP with Kubernetes NetworkPolicy (default-deny) rather than treating SGP alone as the isolation boundary.

Service-mesh mTLS (east-west encryption in transit)​

For intra-cluster pod-to-pod mTLS, use a service mesh — Istio (sidecar mode), Linkerd, or Cilium Service Mesh — all run on EKS and issue/rotate workload certificates for east-west traffic.

Don't position VPC Lattice as an mTLS mesh — it isn't one. VPC Lattice provides cross-VPC / cross-cluster service connectivity with IAM-based authentication (SigV4), not certificate-based mTLS between pods. Use it for secure cross-boundary service-to-service connectivity; use a service mesh (Istio/Linkerd/Cilium) for intra-cluster mTLS. References: VPC Lattice integration · VPC Lattice SigV4 auth.

Gotcha: AWS App Mesh end of support: September 30, 2026 (announced date; new sign-ups already closed — verify current status on the notice page). Do not recommend App Mesh for new deployments regardless of where that date stands — use Istio/Linkerd/Cilium mesh or VPC Lattice. Reference: AWS App Mesh end-of-support notice.

Shared responsibility (Layer 3)​

AWS managesCustomer manages
VPC CNI + NetworkPolicy enforcement engine; PSA controller (built into the managed control plane); SGP trunk/branch ENI plumbingPSA profile labels per namespace; Kyverno/OPA policy authoring + rollout; NetworkPolicy rules (default-deny + allowlists); SGP assignment; service-mesh deployment + mTLS config

Sources​