Kubernetes Security: Pod Security and Network Policies

By Khimananda Oli | Last reviewed: August 2026

Securing a Kubernetes cluster requires enforcing boundaries at both the workload and network layers simultaneously. Kubernetes Security: Pod Security and Network Policies provides this defense-in-depth by restricting what containers can do and controlling which services they can communicate with. Without these controls, a single compromised pod can lead to full cluster takeover or lateral movement across namespaces. This guide covers the exact configurations needed to implement these safeguards effectively.

How Do You Configure Pod Security Standards in Kubernetes?

Pod Security Admission (PSA) replaced the deprecated PodSecurityPolicy in Kubernetes 1.25+. It operates via namespace labels rather than custom resources, making it simpler to audit and manage. For teams familiar with deploying apps to Kubernetes clusters, PSA adds a mandatory validation layer before pods are even scheduled.

Understanding the Three Security Levels

• Privileged: Unrestricted policy, allowing all capabilities including host access. Use only for system namespaces like kube-system.
• Baseline: Minimally restrictive, preventing known privilege escalations (no hostNetwork, hostPID, privileged containers). Suitable for most legacy workloads.
• Restricted: Heavily locked down, requiring non-root users, read-only root filesystems, and dropped capabilities. Mandatory for sensitive data processing.

Applying Namespace Labels for Enforcement

You must label namespaces to activate PSA. The three modes—enforce, audit, and warn—allow gradual rollout without breaking existing deployments:

# Enforce restricted standard on production namespace
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted \
  pod-security.kubernetes.io/warn=restricted \
  --overwrite

# Verify labels applied correctly
kubectl get namespace production --show-labels

A common mistake is applying enforce mode immediately. Start with warn and audit modes for two weeks, review violations in API server logs, fix offending manifests, then switch to enforce. This prevents outages during security hardening.

What Are Kubernetes Network Policies and How Do They Work?

NetworkPolicies define allowed traffic flows at Layer 3/4 using pod selectors, namespace selectors, and IP blocks. By default, all pods can communicate freely; NetworkPolicies flip this to deny-all unless explicitly permitted. This is critical because containerized applications often assume unrestricted network access during development.

Creating a Default Deny Policy

Always start with a default-deny baseline per namespace, then add allow rules incrementally:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}  # Applies to all pods in namespace
  policyTypes:
  - Ingress
  - Egress

Allowing Specific Traffic Flows

After denying all traffic, create targeted allow policies. This example permits the frontend to reach the backend API on port 8080:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-api
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api-backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Critical note: NetworkPolicies require a CNI plugin that supports them (Calico, Cilium, Weave Net). AWS VPC CNI, Azure CNI, and GKE dataplane v2 all support NetworkPolicies natively. Flannel does not support them without additional configuration.

How Does Pod Security Differ From Network Policies?

These mechanisms address different threat vectors and must be used together. Understanding their distinct roles prevents misconfiguration gaps when implementing Kubernetes Security: Pod Security and Network Policies.

In practice, PSA stops a malicious container from mounting the host filesystem, while NetworkPolicies prevent that same container from reaching your database if compromised through an application vulnerability. Neither alone is sufficient.

What Common Mistakes Break Kubernetes Security Controls?

After auditing dozens of production clusters for SOC 2 compliance, I see the same patterns repeatedly. Avoid these pitfalls when hardening environments, whether on managed EKS/AKS/GKE or self-managed infrastructure configured via Terraform infrastructure as code.

Overlooking Egress Restrictions

Most teams configure ingress policies but leave egress wide open. A compromised pod can then exfiltrate data to any external IP or reach internal metadata services (169.254.169.254). Always restrict egress to required destinations:

spec:
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: database-ns
    ports:
    - protocol: TCP
      port: 5432
  - to:
    - ipBlock:
        cidr: 10.0.0.0/8
    ports:
    - protocol: TCP
      port: 443  # Internal API gateway only

Mixing PSA Modes Incorrectly

Setting enforce=baseline but audit=restricted creates confusion. Pods pass enforcement but generate audit noise for restricted violations you never intended to fix. Align all three modes to the same level once validated, or use warn for the stricter level during transition periods.

Forgetting DNS Egress

Default-deny egress breaks DNS resolution, causing cascading failures. Always allow UDP port 53 to kube-dns/CoreDNS:

egress:
- to:
  - namespaceSelector:
      matchLabels:
        kubernetes.io/metadata.name: kube-system
    podSelector:
      matchLabels:
        k8s-app: kube-dns
  ports:
  - protocol: UDP
    port: 53
  - protocol: TCP
    port: 53

Testing Without Validation Tools

Never assume policies work as written. Use kubectl-np-viewer or Cilium's policy verdict tool to simulate traffic flows before deploying to production. Manual testing with curl/netshoot pods catches selector typos that YAML linting misses.

Implementing Production-Ready Kubernetes Security

Effective Kubernetes Security: Pod Security and Network Policies requires treating both controls as interdependent components of a single security posture. Start with PSA in warn mode to identify violations without disruption, deploy default-deny NetworkPolicies with explicit allow rules for known traffic flows, validate with connectivity testing tools, then graduate to enforcement. Document every exception with business justification for audit trails—this matters for ISO 27001 and SOC 2 evidence collection.

If your team needs help designing compliant Kubernetes architectures or validating existing security controls against production requirements, reach out to discuss your specific environment. Proper hardening now prevents incident response costs later.