Kubernetes security is a system of layers, not a single scanner or configuration flag. A hardened cluster combines strong identities, minimal authorization, safe workload settings, network isolation, protected secrets, trusted images, useful audit records and disciplined patching.

This production checklist prioritizes controls that reduce real attack paths. It separates cluster responsibilities from workload responsibilities and turns broad advice such as least privilege into settings teams can review in code and verify at runtime.

What you will learn

  • Minimize API server exposure and grant namespace-scoped permissions wherever possible.
  • Enforce the Restricted Pod Security Standard or an equivalent policy for ordinary workloads.
  • Combine network isolation, encrypted secrets, image controls and runtime visibility; no single layer is sufficient.
  • Treat upgrades, audit logs, backups and incident response as security controls.

Protect the API and human access

The Kubernetes API is the highest-value control surface. Restrict reachable sources, require strong external identity, disable anonymous access, rotate credentials and avoid sharing kubeconfig files. Administrative access should be rare, attributable and time-bound.

Use separate identities for humans, automation and workloads. Centralized identity simplifies removal, while short-lived credentials reduce the value of leaked files. Audit role binding, Secret reads, exec sessions and admission changes.

Apply least privilege with RBAC

Prefer Role and RoleBinding inside a namespace over broad ClusterRoleBinding. Avoid wildcard verbs and resources. Scrutinize Pod creation because a Pod may use service-account tokens or namespace Secrets.

Set automountServiceAccountToken to false when a workload never calls the API. Otherwise create a dedicated ServiceAccount and grant only the required API groups, resources and verbs.

Harden Pods and containers

The Restricted Pod Security Standard is a strong baseline. Run as non-root, disallow privilege escalation, drop Linux capabilities, apply RuntimeDefault seccomp and use a read-only root filesystem where compatible.

Enforce the configuration at admission instead of relying on documentation. Keep narrowly controlled exceptions for system components, with an owner, reason and review date.

securityContext:
  runAsNonRoot: true
  seccompProfile:
    type: RuntimeDefault
containers:
  - name: api
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]

Reduce lateral movement

Namespaces are not firewalls. Use default-deny ingress and egress policies, then permit only specific labels, namespaces, ports and infrastructure dependencies such as DNS.

Separate public applications, CI runners and management tools by trust level. Restrict access to cloud metadata and prefer workload identity instead of long-lived cloud keys in Pods.

Protect secrets and the supply chain

Enable encryption at rest for API data, restrict Secret access and avoid committing values to Git. Remember that permission to create Pods can indirectly expose credentials in the namespace.

Build minimal images, scan dependencies, produce an SBOM, pin sensitive deployments by digest and verify provenance according to the threat model. Admission policy can reject untrusted registries and unsafe manifests.

Detection, recovery and maintenance

Export API audit logs and alert on cluster-admin bindings, privileged Pods, unusual Secret access, unexpected exec sessions and unknown registries. Tune detections against normal automation.

Track supported Kubernetes versions and security releases. Practice restoring cluster state and application data. Document how to isolate namespaces, revoke credentials, preserve evidence and rebuild from trusted sources.

Production checklist

  • Restrict API reachability and use short-lived centralized identity.
  • Remove wildcard RBAC and minimize ClusterRoleBindings.
  • Enforce Pod Security Admission for ordinary namespaces.
  • Use default-deny NetworkPolicies around sensitive workloads.
  • Encrypt Secret data at rest and rotate credentials.
  • Scan, sign and pin production images.
  • Export audit logs and alert on privilege escalation.
  • Patch supported versions and test restoration plus incident procedures.

Frequently asked questions

Are Kubernetes Secrets encrypted by default?

Do not assume so. Configure encryption at rest, restrict API access and protect the delivery path.

Is a namespace a security boundary?

It scopes names and policies but does not automatically isolate traffic or shared-kernel risk. Combine it with RBAC, NetworkPolicy and admission controls.

What should be hardened first?

Start with API exposure, admin access, excessive RBAC, privileged workloads and unprotected secrets because they enable high-impact attack paths.

Continue learning Kubernetes

Official Kubernetes references