Kubernetes Security Best Practices 2026: Hardening Your K8s Cluster

Why Kubernetes Security Matters

Kubernetes is the default runtime for containerized workloads at scale and consistently among the top sources of cloud security incidents. Most Kubernetes security problems are caused by misconfiguration, not novel attacks.

1. RBAC: Least Privilege at the API Level

Every API call to the cluster goes through RBAC authorization. The common mistake is giving service accounts cluster-admin or using wildcard permissions.

# Minimal role for an app that only reads ConfigMaps
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: configmap-reader
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "list"]
  resourceNames: ["app-config"]
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-configmaps
  namespace: production
subjects:
- kind: ServiceAccount
  name: my-app
  namespace: production
roleRef:
  kind: Role
  name: configmap-reader
  apiGroup: rbac.authorization.k8s.io

Key practices: Audit ClusterRoleBindings quarterly, never bind cluster-admin to service accounts.

2. Pod Security Standards

Since Kubernetes 1.25, Pod Security Admission replaces PodSecurityPolicy:

Apply at the namespace level:

kubectl label namespace production   pod-security.kubernetes.io/enforce=restricted   pod-security.kubernetes.io/warn=restricted

Set a compliant security context:

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

3. Network Policies: Default Deny

By default, all pods can communicate with all other pods. Fix this with a default deny policy and explicit allow rules for required traffic:

# Default deny all ingress and egress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
 - Ingress
 - Egress
# Allow app to reach its database
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-app-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
 - Egress
  egress:
 - to:
   - podSelector:
        matchLabels:
          app: postgres
    ports:
   - protocol: TCP
      port: 5432

Note: Requires a CNI plugin that supports Network Policies (Calico, Cilium).

4. Secrets Management

Kubernetes Secrets are base64-encoded, not encrypted, by default. Use External Secrets Operator:

This gives you centralized management, audit logging, and automatic rotation.

5. Image Security and Supply Chain

For the broader pipeline context these scans fit into, see [DevSecOps: integrating security into CI/CD pipelines](/blog/devsecops-integrating-security-into-cicd-pipelines-2026).

Scan in CI/CD with Trivy:

- name: Scan image for vulnerabilities
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: 'myapp:${{ github.sha }}'
    exit-code: '1'
    severity: 'CRITICAL,HIGH'
    ignore-unfixed: true

Block non-compliant images with Kyverno:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-approved-registry
spec:
  validationFailureAction: Enforce
  rules:
 - name: check-registry
    match:
      resources:
        kinds: [Pod]
    validate:
      message: "Images must be from mycompany.azurecr.io"
      pattern:
        spec:
          containers:
         - image: "mycompany.azurecr.io/*"

6. Runtime Threat Detection

Falco monitors system calls for suspicious behavior. For AKS, Microsoft Defender for Containers provides managed runtime protection; see [AKS container security with Defender for Containers](/blog/aks-container-security-defender-for-containers-2026) for the full setup.

Priority Order: Where to Start

1. RBAC audit - find and remove wildcard/cluster-admin bindings
2. Encryption at rest for Secrets or migrate to external secrets
3. Pod Security Standards at baseline level
4. Default-deny Network Policies in sensitive namespaces
5. Image scanning in CI/CD and admission control
6. Runtime detection (Falco or Defender for Containers)

Benchmark with kube-bench against the CIS Kubernetes Benchmark:

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

References

• [Kubernetes security documentation](https://kubernetes.io/docs/concepts/security/): Official Kubernetes security concepts and Pod Security Standards
• [NSA/CISA Kubernetes Hardening Guide](https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF): NSA hardening recommendations (August 2022)
• [CIS Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes): Industry-standard security benchmark for Kubernetes
• [OWASP Kubernetes Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html): OWASP hardening guidance

Frequently Asked Questions

What is the most critical Kubernetes security misconfiguration to fix first?

The single highest-impact Kubernetes security issue is over-permissive RBAC, specifically service accounts and users with wildcard permissions (verbs: ["*"]) or cluster-admin bindings that are not genuinely required. Wildcard RBAC means a compromised workload can read secrets from every namespace, modify deployments, or delete critical resources. Run kubectl get clusterrolebindings and kubectl get rolebindings --all-namespaces to identify all cluster-admin bindings, then audit whether each is justified. Remove any binding where the subject does not require cluster-wide admin access.

Why should Kubernetes Secrets not be trusted as a secret store without additional controls?

Kubernetes Secrets are base64-encoded by default, not encrypted. Base64 is encoding, not encryption: anyone with read access to the etcd database or sufficient RBAC permissions can read Secret values trivially. By default, Secrets are also mounted as files or environment variables in pods, making them accessible to any process running in the container. To actually secure Kubernetes Secrets: enable etcd encryption at rest, restrict Secret read permissions in RBAC to only the service accounts that need them, and for production workloads consider an external secrets manager (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager) with the External Secrets Operator to avoid storing sensitive values in Kubernetes at all.

What are Kubernetes Pod Security Standards and which level should you use?

Pod Security Standards (PSS) are a built-in Kubernetes admission control policy framework replacing the deprecated PodSecurityPolicy. Three levels are defined: Privileged (no restrictions, for system pods), Baseline (prevents known privilege escalation paths, suitable for most workloads), and Restricted (significantly hardened, requires non-root user, drops all capabilities, requires seccomp profile). For most production namespaces, enforce Baseline at minimum and target Restricted for namespaces running sensitive workloads. Apply PSS at the namespace level using the pod-security.kubernetes.io/enforce label. Audit mode (warn but allow) is useful during migration to understand what violations exist before enforcing.

How do Kubernetes Network Policies work and what is the most important one to implement?

Kubernetes Network Policies are namespace-scoped rules that control which pods can communicate with which other pods and external endpoints. They require a CNI plugin that supports Network Policy enforcement (Calico, Cilium, Weave, not Flannel alone). The single most important policy to implement is a default-deny policy in each production namespace: a NetworkPolicy that selects all pods with an empty podSelector and specifies no ingress or egress rules, which blocks all traffic to and from pods in that namespace by default. Additional policies then explicitly allow only the communication paths your application actually requires, limiting lateral movement if any pod is compromised.

What is container image supply chain security and how do you implement it in a Kubernetes cluster?

Container image supply chain security covers the full lifecycle from base image selection through build, registry storage, and deployment. Key controls are: use minimal base images (distroless or Alpine) to reduce the attack surface, scan images for CVEs in your CI/CD pipeline before pushing to the registry (Trivy, Grype, or Snyk), sign images at build time using Sigstore Cosign, and enforce signature verification at admission time using an admission controller (Kyverno, OPA Gatekeeper) that rejects unsigned or unverified images. The Kyverno ClusterPolicy shown in this article enforces that only images from your approved registry can run, preventing developers from deploying arbitrary public images directly to production."