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.
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
- Kubernetes Network Policies: The Complete Guide to Zero Trust Networking — Full walkthrough of this 3-tier architecture with traffic flow diagrams, testing procedures, and troubleshooting tips.
Get Full Access to This Template
This template is included in the Enterprise tier and above.
View Pricing Plans