Kubernetes Security Best Practices: Harden Your Cluster (2026)

Kubernetes powers the majority of modern cloud infrastructure, but its flexibility comes with a large attack surface. Misconfigured RBAC, overprivileged pods, exposed dashboards, and unscanned images are responsible for the majority of container security breaches. This guide covers every aspect of Kubernetes security with real configuration examples you can apply today.

Why Kubernetes Security Matters More Than Ever

Kubernetes adoption crossed 90% among organizations running containerized workloads in 2025, according to the CNCF Annual Survey. But the same survey revealed that 67% of respondents had delayed or slowed deployment due to security concerns. The gap between Kubernetes adoption and Kubernetes security maturity is where breaches happen.

In 2025, several high-profile breaches were traced to Kubernetes misconfigurations. Exposed Kubernetes dashboards, overprivileged service accounts, and secrets stored in plaintext ConfigMaps gave attackers access to production databases, customer data, and cloud provider credentials. The NSA and CISA have published joint guidance specifically for Kubernetes hardening, reflecting the seriousness of these risks.

The challenge is that Kubernetes is secure by design but insecure by default in many configurations. Out-of-the-box installations often lack network policies, run containers as root, and allow unrestricted pod-to-pod communication. Hardening requires deliberate configuration at every layer.

1. RBAC: Lock Down Who Can Do What

Role-Based Access Control (RBAC) is the foundation of Kubernetes security. It controls who can perform which actions on which resources. The most common RBAC mistakes are granting cluster-admin to service accounts that do not need it and using wildcard permissions.

Principle of Least Privilege RBAC

# Good: Specific permissions for a deployment service account
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: deployment-manager
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

# Bad: Overprivileged wildcard permissions
# rules:
# - apiGroups: ["*"]
#   resources: ["*"]
#   verbs: ["*"]

RBAC Audit Checklist

• Audit cluster-admin bindings. Run kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name=="cluster-admin")' to identify every entity with full cluster access. Remove any that are not strictly necessary.
• Avoid wildcard permissions. Specify exact API groups, resources, and verbs instead of using *.
• Use namespaced Roles over ClusterRoles. Limit permissions to specific namespaces whenever possible.
• Review service account tokens. Kubernetes 1.24+ no longer auto-creates long-lived tokens, but older clusters may still have them. Migrate to bound service account tokens.

2. Pod Security Standards

Pod Security Standards (PSS) replaced the deprecated PodSecurityPolicy in Kubernetes 1.25. They define three security levels: Privileged, Baseline, and Restricted. Every production namespace should enforce at least the Baseline level, and ideally the Restricted level.

# Enforce restricted pod security on a namespace
apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Essential Pod Security Settings

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    fsGroup: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    image: myapp:v1.2.3@sha256:abc123...
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]
    resources:
      limits:
        cpu: "500m"
        memory: "256Mi"
      requests:
        cpu: "100m"
        memory: "128Mi"

• Never run containers as root. Set runAsNonRoot: true and specify a non-root user.
• Drop all capabilities. Linux capabilities grant specific kernel privileges. Drop them all and add back only what is needed.
• Use read-only root filesystem. Prevents attackers from writing malicious files to the container filesystem.
• Set resource limits. Without limits, a compromised container can consume all node resources, affecting other workloads.
• Pin image digests. Use image@sha256:... instead of tags to prevent image substitution attacks.

3. Network Policies

By default, every pod in a Kubernetes cluster can communicate with every other pod. This means a compromised pod in a development namespace could potentially reach production databases. Network policies fix this by defining explicit allow rules for pod-to-pod traffic.

# Deny all traffic by default, then allow specific flows
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

---
# Allow frontend to talk to backend on port 8080
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 8080

Start with a default deny-all policy in every namespace, then add specific allow rules for legitimate traffic flows. This approach ensures that any new service added to the namespace is isolated by default until explicitly granted access.

4. Secrets Management

Kubernetes Secrets are base64-encoded, not encrypted. Anyone with API access to a namespace can read secrets in plaintext. This is one of the most commonly misunderstood aspects of Kubernetes security.

Securing Kubernetes Secrets

• Enable encryption at rest. Configure the API server with an EncryptionConfiguration that uses AES-CBC or AES-GCM to encrypt secrets in etcd.
• Use external secrets managers. Tools like External Secrets Operator, HashiCorp Vault, or AWS Secrets Manager provide proper encryption, access control, and audit logging. See our guide on Kubernetes secrets management.
• Limit secret access via RBAC. Only grant get and list on secrets to service accounts that genuinely need them.
• Rotate secrets regularly. Implement automated rotation through your secrets manager and ensure your applications can handle credential changes without downtime.
• Never store secrets in ConfigMaps. ConfigMaps have no additional access controls and are often treated more casually than Secrets.

5. Image Security

Container images are a major attack vector. Vulnerable base images, embedded malware, and supply chain attacks through compromised registries have all been used in real-world breaches.

• Scan images in CI/CD. Use tools like Trivy, Snyk Container, or Aqua to scan every image before it reaches your cluster. Block deployments of images with critical vulnerabilities.
• Use minimal base images. Distroless images, Alpine, or scratch-based images have fewer vulnerabilities because they contain fewer packages. A minimal image might have 5 vulnerabilities versus 200+ in a full Ubuntu image.
• Enforce image signing. Use Cosign or Notary to sign images and configure your admission controller to reject unsigned images.
• Restrict image sources. Use admission controllers (OPA Gatekeeper or Kyverno) to ensure only images from trusted registries can be deployed.

# Kyverno policy: only allow images from your private registry
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: Enforce
  rules:
  - name: validate-registries
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "Images must come from our private registry."
      pattern:
        spec:
          containers:
          - image: "123456789.dkr.ecr.us-east-1.amazonaws.com/*"

6. API Server Security

• Disable anonymous authentication. Set --anonymous-auth=false on the API server.
• Enable audit logging. Configure the Kubernetes audit policy to log all authentication attempts, secret access, and resource modifications.
• Restrict API server access. Use firewall rules or security groups to limit which networks can reach the API server endpoint.
• Enable admission controllers. At minimum, enable NodeRestriction, PodSecurity, and a policy engine like OPA Gatekeeper or Kyverno.

7. Runtime Security

Prevention is essential, but you also need detection for when prevention fails. Runtime security tools monitor container behavior and alert on anomalies.

• Deploy Falco for runtime monitoring. Falco detects suspicious activities like shell access in containers, unexpected network connections, sensitive file reads, and privilege escalation attempts.
• Monitor for cryptomining. Compromised Kubernetes clusters are frequently used for cryptocurrency mining. Monitor for unusual CPU usage patterns and outbound connections to mining pools.
• Use service mesh for mTLS. Istio, Linkerd, or Cilium service mesh encrypts all pod-to-pod communication with mutual TLS, preventing network sniffing within the cluster.

Step-by-Step: Hardening a New Cluster

1. Enable RBAC and audit logging from day one. Review and remove any default cluster-admin bindings.
2. Apply pod security standards to all namespaces. Start with Baseline and work toward Restricted.
3. Create default deny network policies in every namespace. Add specific allow rules as needed.
4. Configure secrets encryption at rest and deploy External Secrets Operator for secrets management.
5. Set up image scanning in CI/CD and admission control to block vulnerable or unsigned images.
6. Deploy Falco or a similar runtime security tool for real-time threat detection.
7. Scan your ingress endpoints with the SecureBin Exposure Checker to verify that internal services are not accidentally exposed to the internet.
8. Validate your SSL/TLS configuration on all ingress endpoints using the SecureBin SSL Checker.

Frequently Asked Questions

Is managed Kubernetes (EKS, GKE, AKS) secure by default?

Managed Kubernetes services handle control plane security (API server patching, etcd encryption, high availability), but they do not secure your workloads. You are still responsible for RBAC configuration, pod security, network policies, image scanning, and secrets management. Managed services provide a more secure starting point, but they are not secure out of the box for production workloads.

Should I use PodSecurityPolicy or Pod Security Standards?

PodSecurityPolicy was removed in Kubernetes 1.25. Use Pod Security Standards (PSS) with Pod Security Admission, which is the built-in replacement. For more granular control, use a policy engine like OPA Gatekeeper or Kyverno alongside PSS. These tools allow custom policies that PSS alone cannot express.

How do I handle secrets rotation in Kubernetes?

The recommended approach is to use an external secrets manager (AWS Secrets Manager, HashiCorp Vault, or Google Secret Manager) with the External Secrets Operator. Configure automatic rotation in your secrets manager, and the operator will sync updated secrets to your cluster. Your applications should be designed to handle credential changes, either by watching for secret updates or by using short-lived credentials that are refreshed automatically.

What is the biggest Kubernetes security mistake teams make?

Running containers as root with no resource limits and no network policies. This combination means a single compromised container can escalate privileges, consume all node resources, and communicate freely with every other pod in the cluster, including production databases. Fixing these three issues alone eliminates the majority of Kubernetes attack surface.

The Bottom Line

Kubernetes security is not a single tool or setting. It is a layered approach that spans RBAC, pod security, network policies, image scanning, secrets management, and runtime monitoring. Start with the highest-impact items: enforce pod security standards, create default deny network policies, and audit your RBAC bindings. Then progressively add image signing, runtime detection, and policy enforcement. Use the SecureBin Exposure Checker to verify that your public-facing services are not leaking internal data.

Related reading: Kubernetes Secrets Management, DevSecOps Guide, Docker Cheat Sheet 2026.