Kyverno Network Security Templates¶
Network policies control traffic between pods, namespaces, and external endpoints. These templates enforce network segmentation and prevent unauthorized communication.
Network Policies Require CNI Support
NetworkPolicy resources only function when your CNI plugin supports them. Verify your cluster's CNI (Calico, Cilium, Weave Net) before deploying network policies.
Why Network Policy Enforcement Matters¶
Default Kubernetes behavior allows all pod-to-pod communication. This creates a flat network where any compromised pod can reach any other pod.
Network policies provide:
- Namespace isolation (prevent cross-namespace traffic)
- Service-level segmentation (databases only accessible to specific apps)
- Egress controls (block unauthorized external connections)
- Zero-trust networking (explicit allow-lists only)
Available Templates¶
NetworkPolicy Requirements¶
Require NetworkPolicy resources in every namespace:
- Mandate default-deny policies for new namespaces
- Enforce ingress and egress rules for production workloads
- Block namespaces without network segmentation
Apply a policy:
Ingress Class Validation¶
Enforce approved IngressClass usage:
- Restrict Ingress resources to approved IngressClass values
- Prevent direct exposure through unapproved ingress controllers
- Validate ingress annotations for security requirements
Apply a policy:
Ingress TLS Requirements¶
Mandate TLS termination for all Ingress resources:
- Require TLS configuration on all Ingress objects
- Validate TLS secret references exist
- Enforce HTTPS-only traffic for external services
Apply a policy:
Service Type Restrictions¶
Control Service exposure and external access:
- Restrict LoadBalancer and NodePort Service types
- Require annotations for external-facing services
- Validate service selectors and port configurations
Apply a policy:
Network Security Patterns¶
Defense in Depth¶
Layer network controls across multiple boundaries:
- Namespace NetworkPolicies - Default deny all traffic
- Service Restrictions - Limit LoadBalancer/NodePort usage
- Ingress Controls - Require TLS and approved ingress classes
- Egress Filtering - Block unauthorized external connections
Zero-Trust Networking¶
Never assume trust based on network location:
- Require explicit NetworkPolicy allow rules (no implicit trust)
- Mandate mTLS for service-to-service communication (use service mesh if needed)
- Validate identity at every network boundary (authentication, not IP allowlisting)
Production vs Non-Production¶
Use different enforcement levels based on environment:
- Production - Strict NetworkPolicy requirements, TLS mandatory, LoadBalancer restricted
- Development - Relaxed policies, allow broader access for testing
- Staging - Production-like policies to catch configuration issues early
Common Enforcement Scenarios¶
Scenario 1: Prevent Unapproved External Exposure¶
Block LoadBalancer services except for approved namespaces:
# Enforced by: services.yaml
# Result: Only ingress-nginx namespace can create LoadBalancer services
# Impact: Prevents accidental exposure of internal services to the internet
Scenario 2: Mandate TLS for Public Services¶
Require TLS configuration on all Ingress resources:
# Enforced by: ingress-tls.yaml
# Result: All Ingress objects must define spec.tls with valid secrets
# Impact: Eliminates plaintext HTTP exposure for external services
Scenario 3: Enforce Namespace Isolation¶
Require NetworkPolicy in every namespace before pod creation:
# Enforced by: security.yaml
# Result: Namespaces must have NetworkPolicy resources before accepting workloads
# Impact: Prevents pods from communicating across namespace boundaries by default
Testing Network Policies¶
Validate NetworkPolicy enforcement without disrupting traffic:
# Test NetworkPolicy requirement (should fail without policy)
kubectl create namespace test-ns
kubectl run test-pod --image=nginx -n test-ns
# Expected: Blocked by policy requiring NetworkPolicy in namespace
# Test Ingress TLS requirement (should fail without TLS)
cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: test-ingress
namespace: test-ns
spec:
rules:
- host: test.example.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: test-service
port:
number: 80
EOF
# Expected: Blocked by policy requiring spec.tls
# Test Service type restriction (should fail for LoadBalancer)
kubectl expose deployment test-app --type=LoadBalancer --port=80 -n test-ns
# Expected: Blocked by policy restricting LoadBalancer type