Kubernetes Security Policies

What Is This

The "Kubernetes Security Policies" skill is a comprehensive guide for implementing production-grade security controls in Kubernetes clusters. It focuses on three critical security mechanisms: NetworkPolicy, PodSecurityPolicy, and Role-Based Access Control (RBAC), alongside the latest Pod Security Standards (PSS). This skill enables platform engineers and Kubernetes administrators to enforce defense-in-depth security, ensuring that clusters are resilient against a broad range of threats. Whether you are managing a single-tenant environment or a highly-segregated multi-tenant platform, these policies are foundational for compliance, workload isolation, and access control.

Why Use It

Kubernetes clusters are inherently dynamic and often shared by multiple teams or applications. Without robust security policies, clusters are susceptible to privilege escalation, lateral movement, and accidental or malicious misconfiguration. By deploying NetworkPolicy, PodSecurityPolicy (for legacy clusters), RBAC, and Pod Security Standards, you can:

• Enforce principle of least privilege for users, service accounts, and workloads.
• Prevent unauthorized network communication between pods and namespaces.
• Mitigate risks related to privilege escalation within pods.
• Support compliance requirements by enforcing security baselines.
• Enable safe multi-tenancy by isolating workloads and controlling access to resources.

Implementing these policies is essential for any production Kubernetes environment, especially those subject to regulatory compliance or operating in a zero-trust architecture.

How to Use It

1. Applying Pod Security

Standards

Pod Security Standards define three levels of policies: Privileged, Baseline, and Restricted. These are enforced at the namespace level using labels.

Privileged (Unrestricted): Allows all workloads, suitable only for trusted system namespaces.

apiVersion: v1
kind: Namespace
metadata:
  name: privileged-ns
  labels:
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/audit: privileged
    pod-security.kubernetes.io/warn: privileged

Baseline (Minimally Restrictive): Blocks known privilege escalations but permits common container patterns.

apiVersion: v1
kind: Namespace
metadata:
  name: baseline-ns
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/audit: baseline
    pod-security.kubernetes.io/warn: baseline

Restricted (Most Restrictive): Applies the strictest controls for production workloads.

apiVersion: v1
kind: Namespace
metadata:
  name: restricted-ns
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

2. NetworkPolicy for Network

Segmentation

Network policies control traffic flow at the IP address or port level within Kubernetes. For example, to only allow incoming traffic to pods with the label app=web from pods labeled app=api:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-to-web
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: web
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: api

3. RBAC for Access

Control

RBAC restricts what users and service accounts can do within the cluster. Here is an example of a ClusterRole and RoleBinding that grants read-only access to pods in a namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-read-only
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-only-binding
  namespace: default
subjects:
  - kind: User
    name: jane
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-read-only
  apiGroup: rbac.authorization.k8s.io

4. PodSecurityPolicy (Legacy Feature)

PodSecurityPolicy (PSP) is deprecated in Kubernetes 1.21+ and removed in 1.25. For legacy clusters, PSPs can restrict pod privileges, volumes, and host access.

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  allowPrivilegeEscalation: false
  runAsUser:
    rule: 'MustRunAsNonRoot'

When to Use It

• When securing Kubernetes clusters in production environments.
• To enforce network segmentation between different teams or application components.
• When implementing compliance controls (e.g., PCI-DSS, HIPAA, SOC2).
• For multi-tenant clusters requiring workload and access isolation.
• When onboarding new workloads and ensuring consistent security posture.
• During incident response or audit to verify security controls.

Important Notes

• PodSecurityPolicy is deprecated and should be replaced by Pod Security Standards in new deployments.
• Always test policies in a staging environment before applying to production.
• RBAC misconfigurations can lead to privilege escalation - review bindings regularly.
• Not all network plugins support NetworkPolicy. Verify compatibility with your CNI provider.
• Use namespace labels to enforce Pod Security Standards automatically.
• Regularly audit permissions and policy effectiveness as your cluster evolves.

By leveraging this skill, platform engineers can systematically secure Kubernetes clusters, ensuring both regulatory compliance and robust operational security.