Kubernetes Security Best Practices

Securing a Kubernetes cluster is a continuous, multi-layered process essential for protecting your applications and data in production. A breach can lead to data loss, service disruption, and compliance violations. This guide moves beyond basic configuration to harden your cluster at every layer—from the control plane to the container runtime—by implementing industry-standard practices and enforceable policies.

The Foundation: Securing the Control Plane

The control plane is the brain of your Kubernetes cluster, and its compromise is catastrophic. The API server is the primary entry point. To secure it, you must enforce strict network access controls, ensuring it is not publicly exposed on the internet. All communication must use Transport Layer Security (TLS), with client certificate authentication and regularly rotated certificates. Disable anonymous requests and leverage strong authentication methods like client certs or integration with an OIDC provider.

Authorization is where Role-Based Access Control (RBAC) becomes critical. RBAC is a security model for defining permissions—who can do what—within a cluster. The principle of least privilege is paramount. Instead of granting broad cluster-admin roles, create specific Roles (namespaced) and ClusterRoles (cluster-wide) with only the necessary permissions. Then, bind these roles to users, groups, or service accounts using RoleBindings and ClusterRoleBindings. For example, a deployment service account should only have get, list, and create permissions for pods in its specific namespace, not delete or access secrets.

Hardening Workloads and Runtime

Your pods and containers represent the largest attack surface. Start by ensuring you run only trusted container images. Configure your pods to use an image pull policy of Always for tags like latest, or better yet, use immutable image digests. Pull images from private, secured registries that require authentication, which you can manage via Kubernetes imagePullSecrets. This prevents the accidental deployment of malicious or outdated public images.

Once a pod is running, you must restrict its capabilities. This is where Pod Security Standards (PSS) are applied. PSS define three policy levels—Privileged, Baseline, and Restricted—that progressively harden pod specifications. In modern clusters, you enforce these standards using the built-in Pod Security Admission (PSA) controller. For example, the Restricted profile prevents running as the root user, disables privilege escalation, and drops all Linux capabilities. You apply these by labeling namespaces: pod-security.kubernetes.io/enforce: restricted.

For real-time threat detection, implement runtime security with a tool like Falco. Falco acts as a security camera for your cluster, monitoring system calls and Kubernetes audit logs for anomalous behavior, such as a shell running in a container, unexpected outbound network connections, or sensitive files being read. When a rule is triggered, Falco can send alerts to your SIEM or even initiate a response, providing a critical layer of defense against active threats.

Governing Traffic and Secrets

In a flat network, a compromised pod can talk to any other pod or service. Network policies are Kubernetes resources that act as a firewall for your pods, allowing you to control traffic flow. By default, all pods are non-isolated. Creating a NetworkPolicy allows you to define ingress (incoming) and egress (outgoing) rules based on pod selectors, namespaces, or IP blocks. For instance, a policy can ensure your backend database pods only accept connections from your application pods on port 5432, blocking all other traffic. A network plugin like Calico or Cilium is required to enforce these policies.

Sensitive data like passwords, API keys, and TLS certificates must be handled with care. Never bake them into container images. Instead, use Kubernetes Secrets (or an external secret manager like HashiCorp Vault). While Secrets are an improvement, they are only base64-encoded by default, not encrypted. For true security, enable and configure the EncryptionConfiguration for the Kubernetes API server, which ensures your Secrets are encrypted at rest in etcd. Furthermore, limit which pods and service accounts can access specific Secrets using RBAC.

Enforcing Policies with Admission Controllers

While RBAC controls who can do something, admission controllers intercept requests to the API server to control what can be done. They are powerful policy enforcement points. The PodSecurity admission controller is one example. For more complex governance, you deploy custom admission controllers. The most common is the Open Policy Agent (OPA) Gatekeeper or Kyverno, which allow you to define policies as code.

These tools can validate and mutate resource requests against custom rules. For example, you can create a policy that rejects any pod that doesn't have a team label, automatically adds resource limits to all deployments, or ensures all imagePullPolicies are set to Always. Admission controllers shift security left, preventing non-compliant workloads from ever being scheduled, which is far more effective than detecting them later.

Common Pitfalls

1. Over-Permissive RBAC Bindings: A common mistake is binding a powerful ClusterRole like edit to the system:authenticated group, effectively granting all logged-in users wide-ranging privileges. Correction: Always audit your RBAC bindings with kubectl get clusterrolebindings -o wide and kubectl get rolebindings --all-namespaces. Use tools like kubeaudit or kubectl-who-can to check for over-permissive rules. Create specific roles for each use case.

1. Running Containers as Root: Default container configurations often run as the root user (UID 0). If this container is compromised, the attacker has root privileges on the node. Correction: In your pod spec, set securityContext.runAsUser to a non-zero UID and runAsNonRoot: true. This is a core tenet of the Pod Security Restricted profile.

1. Leaving Service Account Tokens Mounted by Default: Kubernetes automatically mounts a service account token in each pod. If an application doesn't need to talk to the API server, this token is an unnecessary credential that could be stolen. Correction: Disable automatic mounting at the pod level with automountServiceAccountToken: false.

1. Ignoring Cluster Node Security: Focus on pods while neglecting the underlying worker nodes is a critical oversight. Correction: Harden the node OS (e.g., using CIS benchmarks), minimize the kubelet's permissions, and use a Container Runtime Interface (CRI) like containerd that has a smaller attack surface than Docker. Regularly patch nodes and the Kubernetes version itself.

Summary

• Principle of Least Privilege is Paramount: Enforce it rigorously through fine-grained RBAC, Pod Security Standards, and network policies to minimize your cluster's attack surface.
• Encrypt and Protect Sensitive Data: Use Kubernetes Secrets with etcd encryption at rest, tightly control access via RBAC, and consider external secret managers for robust lifecycle management.
• Shift Security Left with Policy-as-Code: Use admission controllers like OPA Gatekeeper or Kyverno to enforce security, labeling, and resource standards before workloads are deployed.
• Assume Defense-in-Depth: No single layer is sufficient. Combine cluster hardening (API security), workload security (PSS, images), runtime security (Falco), and network security (policies) for comprehensive protection.
• Manage the Entire Stack: Security extends to the container images, node operating systems, and Kubernetes version itself. Implement automated image scanning, node hardening, and a regular patching cadence.