K8s Security Pro
#20 Network Security enterprise

Complete 3-Tier Network Policy Set

A production-ready set of 6 NetworkPolicies implementing zero-trust networking for a 3-tier application: default deny, frontend, backend, database, Redis cache, and Prometheus monitoring.

CIS Benchmark
5.3.25.3.1
MITRE ATT&CK
T1046T1021

Overview

This template provides a complete zero-trust network policy set for a 3-tier application architecture (frontend, backend, database) with Redis caching and Prometheus monitoring. It includes 6 NetworkPolicies: default deny-all, frontend (ingress from internet, egress to backend/DNS/HTTPS), backend (ingress from frontend, egress to database/Redis/DNS/HTTPS), database (ingress from backend only, egress DNS only), Redis cache, and Prometheus scraping exception.

Security threat addressed: Kubernetes flat networking allows any pod to communicate with any other pod. A single compromised frontend pod can directly access the database, exfiltrate data, or scan internal services for further exploitation.

When to use: Apply to every production application with a multi-tier architecture. This template covers the most common pattern (web + API + database + cache + monitoring) and can be adapted for other architectures.

Threat Model

  • Microsegmentation: Each tier can only communicate with its authorized neighbors. Frontend cannot reach the database; the database cannot reach the internet.
  • Zero-trust foundation: Default deny-all ensures no traffic flows without explicit authorization.
  • Data exfiltration prevention: Database and Redis egress is limited to DNS only, preventing any outbound data theft from the most sensitive tiers.
  • Monitoring without compromise: Prometheus scraping is explicitly allowed on port 9090, restricted to pods in the monitoring namespace.

MITRE ATT&CK:

  • T1046 — Network Service Discovery: Default-deny prevents attackers from scanning services within the namespace. Each tier sees only what it is authorized to reach.
  • T1021 — Remote Services: Lateral movement via service ports is blocked. A compromised frontend cannot reach the database directly.

Real-world scenario: An attacker exploits a vulnerability in the frontend application and tries to directly connect to the PostgreSQL database on port 5432. The backend NetworkPolicy restricts database ingress to only backend pods, so the frontend’s connection is dropped by the CNI.

YAML Source

# SECTION 1: DEFAULT DENY ALL (INGRESS + EGRESS)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: app-production
  labels:
    app.kubernetes.io/name: k8s-security
    app.kubernetes.io/part-of: k8s-security-pro
    app.kubernetes.io/managed-by: k8s-security-pro
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress
---
# SECTION 2: FRONTEND NETWORKPOLICY
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-network-policy
  namespace: app-production
  labels:
    app.kubernetes.io/name: k8s-security
    app.kubernetes.io/part-of: k8s-security-pro
    app.kubernetes.io/managed-by: k8s-security-pro
spec:
  podSelector:
    matchLabels:
      app: frontend
      tier: frontend
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from: []
      ports:
        - protocol: TCP
          port: 80
        - protocol: TCP
          port: 443
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: backend
              tier: api
      ports:
        - protocol: TCP
          port: 8080
# ... truncated -- get backend, database, Redis, and Prometheus policies
# at k8s-security.pro/pricing

Get the complete template with all 6 NetworkPolicies covering backend (PostgreSQL + Redis + external HTTPS), database (strict ingress, DNS-only egress), Redis cache isolation, and Prometheus monitoring exceptions in the Enterprise tier.

Installation

kubectl:

kubectl apply -f 20_network_policy_complete.yaml

Helm:

helm install k8s-security ./charts/k8s-security -f values-prod.yaml

Kustomize:

kubectl apply -k kustomize/overlays/prod

Verification

# List all policies in the namespace
kubectl get networkpolicies -n app-production

# Verify default-deny is in place
kubectl describe networkpolicy default-deny-all -n app-production

# Test frontend can reach backend
kubectl exec -n app-production <frontend-pod> -- wget -q -O- --timeout=2 http://backend:8080/health

# Test frontend CANNOT reach database directly
kubectl exec -n app-production <frontend-pod> -- pg_isready -h database -p 5432 2>&1
# Expected: timeout or connection refused

# Test backend can reach database
kubectl exec -n app-production <backend-pod> -- pg_isready -h database -p 5432

# Test database cannot reach internet
kubectl exec -n app-production <database-pod> -- wget -q -O- --timeout=2 http://google.com 2>&1
# Expected: timeout

# Verify Prometheus can scrape metrics
kubectl exec -n monitoring <prometheus-pod> -- wget -q -O- --timeout=2 http://<frontend-pod>.app-production.svc:9090/metrics

CIS Benchmark References

  • 5.3.2 — Ensure that all Namespaces have NetworkPolicies defined. This template exceeds the baseline requirement with per-tier policies implementing full microsegmentation.
  • 5.3.1 — Ensure CNI supports NetworkPolicy and encryption. These policies require a compatible CNI (Calico, Cilium, Antrea).

MITRE ATT&CK References

  • T1046 — Network Service Discovery: Default deny-all prevents attackers from scanning services within the cluster. Only authorized traffic paths exist.
  • T1021 — Remote Services: Microsegmentation blocks lateral movement. Each tier can only communicate with its direct neighbors, not arbitrary services.

Further Reading

Get Full Access to This Template

This template is included in the Enterprise tier and above.

View Pricing Plans