Kubernetes Security Checklist: A Practical Guide for Cluster Hardening

Overview

Kubernetes security is distributed across the cluster control plane, worker nodes, workloads, supply chain, identity system, and surrounding cloud services. A secure configuration in one area does not compensate for an exposed service account, an unreviewed container image, or a missing audit trail elsewhere.

Use this Kubernetes security checklist as a baseline for cluster hardening. It is not a replacement for your cloud provider’s guidance, Kubernetes version documentation, threat model, or organizational controls. Instead, it provides a repeatable way to ask whether important protections are enabled, tested, and still appropriate as the platform changes.

Before each review, record the Kubernetes version, cluster type, enabled add-ons, ingress or Gateway API implementation, service mesh if present, container registries, identity providers, and security tools in use. Version and distribution differences matter: a configuration available in one managed service may be controlled by the provider in another, and feature behavior can change between Kubernetes releases. Confirm details against the documentation for the exact versions you operate.

What to track

1. Cluster access and Kubernetes RBAC

• Review human and workload identities with access to the cluster. Remove inactive users, obsolete groups, and temporary bindings.
• Prefer namespace-scoped Role and RoleBinding objects when cluster-wide access is not required.
• Inspect ClusterRoleBinding objects for broad permissions, especially bindings to administrative roles.
• Check for permissions that allow reading secrets, creating workloads, impersonating users, or modifying role bindings. These capabilities can have wider consequences than their names suggest.
• Use dedicated service accounts for applications instead of relying on the default service account.
• Confirm that applications receive only the API permissions they need, and disable service account token mounting for workloads that do not use the Kubernetes API.

Keep an inventory of privileged identities and assign an owner to each one. A useful review question is not simply “does this binding exist?” but “what business or operational task requires it, and when was that need last confirmed?”

2. Pod security and workload configuration

Apply an explicit pod security standard to every namespace, using the enforcement level that matches the workload and your risk tolerance. Where stricter controls would disrupt existing applications, begin with audit or warning modes where supported, remediate the workload, and then move toward enforcement. Check the behavior supported by your Kubernetes version and distribution.

For each workload, look for a non-root user, a read-only root filesystem where practical, dropped Linux capabilities, a suitable seccomp profile, and an explicit security context. Avoid privileged containers, host networking, host PID or IPC access, host path mounts, and unnecessary access to device files. These settings should be treated as exceptions requiring an owner and documented reason.

Also inspect resource requests and limits, health probes, and termination behavior. These are primarily reliability controls, but poor resource isolation can make security incidents easier to trigger or harder to contain. Separate workloads with materially different trust levels using namespaces, node placement controls, and admission policies where appropriate.

3. Network policies and exposed services

Document how traffic should move between namespaces, applications, ingress points, and external services. Then compare that intended flow with the policies actually installed.

• Confirm that every relevant namespace has a default-deny posture for ingress, egress, or both, where the application architecture permits it.
• Add explicit rules for required DNS, telemetry, database, API, and service-to-service traffic.
• Test policies from both allowed and denied paths; a policy that exists but is not enforced by the selected network plugin does not provide the expected control.
• Review externally reachable Services, Ingress objects, Gateway API resources, load balancers, and node ports.
• Validate TLS termination, certificate rotation, and administrative endpoints separately from public application traffic.

If your design includes a service mesh, keep the mesh’s identity and traffic controls aligned with Kubernetes network policies rather than assuming one replaces the other. For design context, see our service mesh comparison.

4. Secrets and encryption

List every place sensitive data can appear: Kubernetes Secrets, manifests, Helm values, CI/CD variables, container logs, crash dumps, annotations, and external configuration systems. Do not treat base64 encoding in a Kubernetes Secret as encryption by itself.

Confirm that data at rest is protected according to your cluster and provider configuration, and restrict which users and service accounts can read secrets. Prefer short-lived credentials and external secret-management workflows when they fit the application. Define rotation owners, test rotation without an outage, and record which workloads consume each credential. A comparison of common approaches is available in this secrets management tools guide.

5. Images and the software supply chain

• Use approved registries and document who can publish to them.
• Prefer immutable image references, such as digests, for production releases when your delivery process supports them.
• Scan images and dependencies at a suitable stage, then define how findings are triaged and exceptions expire.
• Build minimal images, remove development tools and credentials, and use a repeatable build process.
• Verify that deployment automation cannot silently replace a reviewed image with an unreviewed tag.

Review registry permissions as carefully as cluster permissions. Your choice of registry affects authentication, retention, provenance workflows, and operational controls; use this container registry comparison as a starting point for that assessment.

6. Admission, runtime monitoring, and audit logs

Use admission controls to enforce rules that should not depend on individual developer judgment: approved registries, required labels, prohibited privileged settings, resource declarations, image signatures where supported, and allowed host access. Start new policies in a reporting mode when possible, measure violations, and define an owner for every exception.

At runtime, monitor for unexpected exec sessions, privilege changes, suspicious process activity, unusual network connections, access to sensitive paths, and workloads created outside the normal delivery path. Pair alerts with an investigation procedure; a stream of unowned alerts is not an effective control.

Enable and protect Kubernetes audit logging according to the needs of your environment. Track authentication failures, permission denials, secret access, workload creation, role changes, and changes to network or admission configuration. Send logs to a location with controlled access and a retention period that supports investigation. Combine audit events with cloud-provider, node, container, and application telemetry. The OpenTelemetry Collector configuration guide can help when designing the broader telemetry path.

Cadence and checkpoints

A practical cadence separates routine drift detection from deeper design reviews:

• Every deployment: validate image provenance or approval, namespace policy, service account choice, security context, exposed ports, secrets references, and admission results.
• Monthly: review privileged RBAC, new namespaces, external endpoints, failed authentication events, policy violations, image exceptions, and unowned service accounts.
• Quarterly: test network-deny behavior, credential rotation, backup restoration, incident access, audit-log availability, and recovery procedures. Revisit the threat model for newly introduced workloads.
• After a Kubernetes or platform upgrade: recheck Pod Security behavior, admission policies, API versions, network-plugin compatibility, audit configuration, and provider-managed control-plane settings.
• After an incident or major architecture change: update the checklist with the failed assumption, detection gap, containment action, and permanent owner.

Store the checklist with your infrastructure code or security review records. Each item should have a status, evidence link, owner, exception expiry, and next review date. This turns a static document into an operational control.

How to interpret changes

Not every change indicates a security failure. A new privileged binding may be justified by a controlled platform migration; a new egress rule may be required by a dependency change. The important distinction is whether the change was expected, authorized, narrowly scoped, and recorded.

Classify findings by exposure and reversibility. An internet-facing administrative endpoint, unrestricted secret access, or a privileged workload without a documented reason deserves prompt attention. A missing label or low-impact policy warning may be handled through the normal backlog, but it should still have an owner and deadline.

Look for trends instead of isolated counts. A growing number of RBAC exceptions, recurring policy bypasses, increasing privileged workloads, or repeated image findings may indicate a platform-design problem. In that situation, improve the developer path with safer defaults, reusable templates, admission feedback, and documented exceptions rather than relying only on more manual review.

When to revisit

Revisit this Kubernetes security checklist at least monthly for drift and quarterly for a structured review. Update it immediately when you upgrade Kubernetes, change the container runtime or network plugin, adopt a service mesh, move between ingress and Gateway API patterns, add a new identity provider, change registries, or introduce a workload with a different trust boundary.

To make the next review actionable, finish each session with three outputs: a short list of high-risk findings, evidence that key controls were tested, and named owners with dates for unresolved work. Recheck closed findings rather than marking them complete permanently. Kubernetes security is a moving configuration surface, so the goal is not to achieve a final state; it is to detect drift early and make secure operation repeatable.