Network Policies
Kubernetes security relies heavily on controlling network communication between microservices and enforcing strict container runtime policies. Network policies define how pods can communicate with each other and external services, while Pod Security Policies (PSP) and their modern replacement, Pod Security Admission (PSA), ensure containers are configured with minimal attack surfaces. These mechanisms are critical for isolating services, preventing privilege escalation, and meeting compliance requirements.
Network Policies for Microservices Communication¶
Network policies use label selectors to define rules for allowed traffic between pods. They operate at the namespace level by default, restricting communication unless explicitly permitted. Policies can enforce rules for ingress (incoming traffic) and egress (outgoing traffic).
Example: Restricting Communication Between Services¶
Suppose you have two services: frontend and database. You can create a policy that allows only the frontend pod to communicate with the database pod.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: frontend-db-policy
namespace: default
spec:
podSelector:
matchLabels:
app: frontend
policyTypes:
- Ingress
- Egress
ingress:
- from:
- podSelector:
matchLabels:
app: database
egress:
- to:
- podSelector:
matchLabels:
app: database
Commands to Apply and Verify:
Key Concepts¶
- Selector Matching: Policies apply to pods matching the
podSelectoror referenced byfrom/torules. - Namespace Scope: Policies are namespace-scoped unless explicitly configured to span namespaces.
- Traffic Control: Policies can block all traffic by default and explicitly allow specific connections.
Pod Security Policies (PSP) and Pod Security Admission (PSA)¶
Pod Security Policies (PSP)¶
PSPs enforce security settings on pods, such as requiring non-root users, disallowing privileged containers, or restricting capabilities. However, PSPs are deprecated in Kubernetes 1.25+ and replaced by Pod Security Admission (PSA).
Example: Enforcing Non-Root Users with PSP¶
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted-psp
spec:
privileged: false
seccompProfile:
type: RuntimeDefault
fsGroup:
rule: MustRunAs
ranges:
- min: 1
max: 65535
runAsUser:
rule: MustRunAs
ranges:
- min: 1000
max: 1000
Commands to Apply and Verify:
Pod Security Admission (PSA)¶
PSA is the modern replacement for PSP, integrated into Kubernetes as a built-in feature. It uses a set of predefined modes to enforce security levels:
| Mode | Description |
|---|---|
Privileged |
No restrictions (not recommended) |
Restricted |
Default mode; enforces non-root users and no privileged containers |
Baseline |
Similar to Restricted but allows some capabilities |
Audit |
Enforces policies but does not block pods |
Example: Enforcing Restricted Mode with PSA¶
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
name: pod-security-admission
webhooks:
- name: pod-security-admission.validators.k8s.io
rules:
- operations: ["CREATE", "UPDATE"]
apiGroups: ["", "policy"]
apiVersions: ["v1", "policy/v1beta1"]
resources: ["pods", "podsecuritypolicies"]
clientConfig:
service:
name: pod-security-admission
namespace: kube-system
path: /podsecurityadmission
port: 443
namespaceSelector:
matchExpressions:
- key: "pod-security.kubernetes.io/audit"
operator: "NotIn"
values: ["audit"]
Commands to Verify:
Key takeaways¶
- Use network policies to explicitly define allowed communication between microservices, ensuring isolation and controlled traffic.
- Pod Security Policies (PSP) enforce container hardening but are deprecated; use Pod Security Admission (PSA) for modern, integrated security enforcement.
- Always validate policies with
kubectlcommands and ensure labels match selectors for effective rule application.