Kubernetes Hardening Guide: How Do You Secure a Cluster?

What are the Kubernetes hardening priorities and threat model?

A hardened cluster limits what an attacker can reach, what an identity can do, and how long a compromise can remain undetected. The National Security Agency (NSA) and Cybersecurity and Infrastructure Security Agency (CISA) identify data theft, stolen computing capacity, and denial of service as major Kubernetes attack goals in their guidance published on March 15, 2022.

• Reduce the attack surface by removing unused API endpoints, privileged containers, public node services, and unnecessary add-ons.
• Assume that an application container may be compromised, then prevent it from becoming a node, cluster, or cloud-account compromise.
• Separate development, production, and sensitive workloads with namespaces, identities, policies, and infrastructure boundaries.
• Prepare evidence for investigation by collecting API, node, container, and application logs in a separate system.

CISA describes its Kubernetes Hardening Guide as a configuration and mitigation resource, but its page is marked archived. Use the CISA Kubernetes hardening guidance as a baseline and re-check settings against the current Kubernetes release and your provider’s documentation.

How does pod security with Pod Security Standards work?

Pod Security Standards (PSS) define three security profiles for pods: Privileged, Baseline, and Restricted. The Restricted profile applies the strongest general controls, including non-root execution and reduced Linux privileges, so it should be your target for workloads that do not require exceptions.

How do I enforce the Restricted standard by namespace?

Apply Pod Security Admission labels to each namespace instead of relying on a cluster-wide assumption. Use enforce=restricted for namespaces that must reject non-compliant pods, and use warn or audit during migration to identify incompatible manifests without immediately blocking deployments.

Keep enforcement labels under version control and review them with the namespace definition. A namespace label is not a substitute for a complete admission policy, because it does not describe business exceptions, image provenance, resource limits, or custom organisational rules.

How do I run non-root, non-privileged workloads?

Set runAsNonRoot: true and specify a non-zero user with runAsUser where the image supports it. Set privileged: false, disable privilege escalation, and avoid host namespaces such as hostNetwork, hostPID, and hostIPC unless the workload has a documented operating requirement.

Test the image as the selected user before enforcing the policy. A workload that writes to a root-owned directory or expects to bind a low network port may need an image change rather than a security-policy exception.

How do I use read-only filesystems and drop Linux capabilities?

Set readOnlyRootFilesystem: true and mount a narrowly scoped temporary filesystem for applications that need scratch space. Drop all Linux capabilities first, then add only a named capability that the application demonstrably requires.

Do not compensate for a writable root filesystem by granting broad host access. Capabilities, writable mounts, device access, and hostPath volumes should each be reviewed as separate privilege paths.

How do I build and scan minimal, signed container images?

Use small, maintained base images, pin dependencies, remove package managers and debugging tools from runtime images, and generate a software bill of materials (SBOM). Scan images before deployment and again when vulnerability data changes, because a previously clean image can acquire a newly disclosed vulnerability.

Verify image signatures and restrict approved registries through admission controls. NSA and CISA specifically recommend scanning containers and pods for vulnerabilities or misconfigurations, alongside least-privilege execution and logging.

How should identity, authentication, and RBAC be hardened?

Identity controls determine whether a stolen credential can read one namespace or administer the entire cluster. Kubernetes role-based access control (RBAC) hardening therefore starts with strong human authentication, narrowly scoped permissions, and regular review of every binding.

Which secure authentication mechanisms should I choose?

Use your identity provider for human access and integrate it with Kubernetes through OpenID Connect (OIDC) where supported. Require phishing-resistant multifactor authentication for administrator identities, protect the identity provider itself, and avoid shared accounts because they destroy attribution.

Restrict the API server to private networks or approved administrative paths. Public exposure may be unavoidable for some architectures, but it should then be combined with identity-provider controls, network filtering, rate limits, and monitoring.

Why should I prefer short-lived tokens and OIDC?

Short-lived credentials reduce the useful lifetime of a stolen token. OIDC lets the identity provider handle authentication and group membership while Kubernetes evaluates the resulting identity against RBAC rules.

Do not place long-lived bearer tokens in source repositories, shell history, container images, or CI logs. Rotate signing keys and provider credentials according to your incident-response and identity policies, and test revocation before you need it.

How do I apply least-privilege RoleBindings and ClusterRoleBindings?

Use a Role and RoleBinding for namespace-scoped access whenever possible. Reserve ClusterRole and ClusterRoleBinding for permissions that genuinely span namespaces, and avoid wildcard verbs, resources, and API groups.

Inspect permissions with commands such as kubectl auth can-i using the target identity. Review access to secrets, pods, exec, impersonation, persistent volumes, nodes, and admission configuration because these permissions can enable lateral movement or privilege escalation.

How do I protect service accounts and avoid automounting credentials?

Set automountServiceAccountToken: false on pods that do not call the Kubernetes API. Create separate service accounts for separate applications, and grant each only the API actions it requires.

Where an application needs cloud access, prefer the provider’s workload-identity mechanism over a static cloud key stored in a Kubernetes Secret. Treat a service account with broad permissions as a high-value identity and alert when it is used outside its expected namespace or workload.

How do I isolate network traffic and workload communication?

Network isolation prevents a compromised pod from freely discovering and contacting other workloads, nodes, control-plane services, or cloud metadata endpoints. A securing Kubernetes cluster plan should define allowed flows before writing NetworkPolicies.

How do I use default-deny ingress and egress with NetworkPolicies?

Begin each application namespace with default-deny ingress and egress policies, then add explicit rules for DNS, ingress controllers, databases, queues, and required external services. Confirm that your Container Network Interface (CNI) plugin enforces both directions, because Kubernetes policy support depends on the installed networking implementation.

Test policies from the workload’s actual service account and namespace. A policy that allows traffic by namespace alone may still permit every pod in that namespace, so use pod labels and ports to narrow the path where practical.

How do I restrict control-plane, node, and cloud metadata access?

Keep the API server, kubelet ports, container runtime sockets, and etcd endpoints off the public internet. Firewall node management interfaces so only approved administration networks can reach them, and block pod access to cloud instance-metadata services unless a documented workload requires it.

Use cloud-provider controls in addition to Kubernetes policies. A pod-level policy cannot repair an overly permissive cloud instance role or an exposed node security group.

When should I separate sensitive workloads with namespaces and network segments?

Use namespaces for administrative and policy boundaries, not as a complete substitute for separate infrastructure. Workloads handling sensitive data may need dedicated node pools, cloud accounts or projects, network segments, encryption keys, and stricter admission rules.

Document permitted communication between segments. If the boundary must withstand a node compromise, schedule the workloads on separate nodes and apply provider-level isolation in addition to namespace policies.

How should I harden the control plane, nodes, and etcd?

Protect the control plane and node operating systems as separate security layers. Kubernetes settings cannot compensate for an exposed kubelet, an unpatched node kernel, or unencrypted etcd backups.

How do I restrict API server and kubelet exposure?

Expose the API server only through private endpoints or tightly filtered administrative access. Disable anonymous access, require authentication and authorization for kubelet requests, and prevent unauthorised users from reaching kubelet read-only or debugging interfaces.

Review cloud load balancers, firewall rules, and security groups after every infrastructure change. A private cluster can become publicly reachable through an overlooked load balancer or management rule.

How do I secure kubeconfig files and administrator access?

Protect kubeconfig files as credentials because they may contain bearer tokens, client certificates, or access to powerful identities. Store them with restrictive filesystem permissions, keep them out of shared home directories and repositories, and remove obsolete contexts.

Use separate administrator and day-to-day identities. Record privileged actions through API audit logs, and use just-in-time elevation where your identity platform supports it.

How do I encrypt etcd traffic and Kubernetes Secrets at rest?

Encrypt traffic between etcd members and between the API server and etcd with mutually authenticated Transport Layer Security (TLS). Enable encryption at rest for Kubernetes Secrets and protect the encryption key separately from the data store.

Remember that Kubernetes Secrets are not automatically secret from every authorised cluster reader. Limit get, list, and watch access, secure backups, and consider an external secret manager when its operational controls are stronger than storing sensitive values in the cluster.

How do I harden nodes and the container runtime?

Patch the node operating system, kernel, container runtime, and Kubernetes components through a tested maintenance process. Remove unused packages and services, restrict SSH, use disk encryption where appropriate, and prevent workloads from mounting the container runtime socket.

Node hardening belongs alongside container hardening. See the Docker host hardening guide for host-level controls that also apply to many Kubernetes worker nodes.

How do secrets, admission controls, and resource protection work?

Secrets management, admission policy, and resource controls prevent unsafe objects from entering the cluster and stop one workload from consuming all available capacity. These controls are complementary: none replaces identity or network isolation.

How should I manage secrets outside manifests where appropriate?

Do not commit passwords, private keys, or cloud credentials to Git, Helm values, or container images. Use an external secret manager with workload identity when you need central rotation, access logs, separation of duties, or recovery controls that Kubernetes alone does not provide.

Scan repositories and CI artefacts for leaked credentials, then revoke exposed values rather than merely deleting the file. Treat rendered manifests and backup archives as sensitive copies.

How do I use admission policies to enforce security guardrails?

Admission controls can reject privileged pods, hostPath mounts, unapproved registries, mutable image tags, missing resource limits, and unsafe capabilities before scheduling. Use Pod Security Admission for the standard baseline, then add policy tooling for organisation-specific requirements.

Start in audit or warning mode, measure false positives, and document exceptions with an owner and expiry date. A permanent exception is usually an unreviewed policy gap.

How do I set resource requests, limits, and quotas?

Set realistic CPU and memory requests so the scheduler can place workloads predictably, then set limits where an application can safely tolerate them. Apply namespace-level ResourceQuota and LimitRange objects to control aggregate consumption and prevent accidental resource monopolisation.

Test limits under normal and peak load. An incorrectly low memory limit can create repeated out-of-memory kills, while no quota allows a faulty deployment to exhaust a node pool.

How should I audit, monitor, and detect incidents?

Monitoring tells you that something changed; audit data helps explain who changed it and through which API action. Send security-relevant events to a separate, access-controlled system so an attacker cannot erase the only record from the cluster.

How do I configure Kubernetes API audit logging?

Define an audit policy that records authentication failures, permission denials, changes to RBAC, Secrets, workloads, admission configuration, and cluster-wide objects. Avoid logging sensitive request bodies unnecessarily, because audit records can themselves contain secret values.

Set retention according to your incident-response and legal requirements, and verify that logs survive cluster failure. NSA and CISA added detail on logging and threat detection in their March 15, 2022 update, but the correct policy still depends on your Kubernetes version and operating environment.

How do I centralize control-plane, node, and application logs?

Forward API audit events, control-plane logs, kubelet and runtime logs, node security events, and application logs to centralized storage. Keep timestamps synchronized, preserve namespace and pod identity, and protect the destination from ordinary cluster administrators where separation of duties is required.

Monitor failed image pulls, unusual exec sessions, unexpected service-account use, repeated admission denials, and sudden outbound traffic. Tune alerts against normal deployment activity so operators can investigate meaningful deviations.

How do I alert on privilege escalation and suspicious activity?

Alert when a workload requests privileged mode, host namespaces, dangerous capabilities, hostPath access, or a new cluster-wide binding. Also alert on disabled NetworkPolicies, changes to admission controls, creation of external load balancers, and access to sensitive Secrets.

Connect alerts to a response procedure that identifies the affected identity, pod, node, image digest, and recent changes. Isolate a compromised workload without destroying evidence, then rotate credentials that may have been exposed.

How do I patch, validate, and maintain a hardened cluster?

Hardening is a maintenance process, not a one-time configuration task. Kubernetes releases, container images, cloud integrations, and security policies change, so schedule reviews and re-test controls after upgrades.

• Track releases: subscribe to Kubernetes and image-security advisories, record the version currently deployed, and define a tested patch window.
• Validate manifests: run policy checks and vulnerability scans in CI, then test the rendered manifests against a non-production cluster.
• Review access: inspect RoleBindings, ClusterRoleBindings, service accounts, cloud identities, and unused namespaces on a recurring schedule.
• Test recovery: restore etcd or provider backups in an isolated environment and verify that encryption keys, audit records, and application secrets are recoverable.

How do I track Kubernetes and image security releases?

Maintain an inventory of Kubernetes versions, node images, container digests, add-ons, admission controllers, and CNI components. A patch is not complete until the new version is deployed across every relevant control-plane and worker node and the old image is no longer schedulable.

Record the date each release was assessed because advisories and vendor support policies change. Re-check current release requirements before planning production maintenance.

How do I test controls with manifests and security scanners?

Use representative manifests to test non-root execution, dropped capabilities, read-only filesystems, NetworkPolicies, quotas, admission rules, and RBAC permissions. Run scanners in CI and against running workloads, but investigate findings manually because a scanner cannot understand every application dependency or accepted exception.

Include failure testing for DNS, service-to-service traffic, token expiry, node replacement, and secret rotation. Security controls that work only during normal operation are not fully validated.

How often should I review permissions, policies, and exceptions?

Review high-privilege access after staff or workload changes and perform a broader permissions review at least once during each operational review cycle. Expire temporary policy exceptions automatically where possible, and require an owner, reason, compensating control, and removal date for every exception.

For transport encryption between cluster components and external services, align certificate issuance, rotation, and trust-store management with the practices in this guide to TLS and SSL hardening in production. Re-test after certificate or ingress changes because secure defaults can break older clients.