A Kubernetes security checklist is most useful when it becomes a repeatable operating habit rather than a one-time launch task. This guide organizes cluster hardening into practical phases, covering identity, access control, secrets, workload isolation, image supply chains, admission controls, monitoring, and review workflows. Use it during initial setup, after material changes, and on a monthly or quarterly schedule to identify drift before it becomes an incident.
Overview
Kubernetes security spans more than the control plane. A defensible cluster depends on how people authenticate, how workloads receive permissions, how images are built and deployed, how traffic moves between namespaces, and how the team detects unusual behavior. The goal is not to apply every available control indiscriminately. The goal is to make access intentional, reduce unnecessary exposure, and create enough evidence to investigate failures.
Start by documenting the scope of the review. Record the cluster environments, business-critical namespaces, externally reachable services, managed services, identity providers, container registries, and teams responsible for each area. A checklist without ownership tends to become a collection of unchecked assumptions.
For deployment-related controls, pair this article with the Kubernetes Deployment Checklist. Security decisions should be part of the path from image creation to rollout and rollback, not a separate approval step that happens after deployment.
What to track
1. Cluster access and workload identity
- List human and machine identities that can access each cluster, and remove accounts that no longer have a current operational purpose.
- Prefer short-lived, federated, or otherwise centrally managed authentication where your platform supports it. Avoid shared administrator credentials.
- Separate identities used by people, CI/CD systems, controllers, and applications. A deployment pipeline should not automatically inherit broad interactive administrator access.
- Review cloud workload identity bindings and service-account mappings. Confirm that each workload can access only the cloud resources it needs.
- Check for service-account tokens mounted into pods that do not require Kubernetes API access. Disable automatic mounting where it is unnecessary.
Identity drift is easy to miss because access often accumulates during migrations and incident response. Keep an owner and purpose beside each privileged identity so reviewers can distinguish deliberate access from historical residue.
2. RBAC and administrative permissions
- Inventory cluster-admin bindings and verify every one has a documented reason.
- Prefer namespace-scoped Roles and RoleBindings when a team or service does not need cluster-wide access.
- Separate read, deploy, operate, and administer permissions instead of assigning one role to every engineering group.
- Review permissions granted to groups, automation accounts, Helm operators, GitOps controllers, and troubleshooting tools.
- Test representative workflows with the minimum intended role. A role that works only because it is over-privileged is a security and maintenance risk.
Record both the binding and the business or operational task it supports. RBAC reviews are more effective when they ask “what does this identity need to do?” rather than only “does this YAML look familiar?”
3. Secrets and sensitive configuration
- Keep credentials out of container images, source repositories, build logs, and plain-text configuration files.
- Identify where Kubernetes Secrets are stored, who can read them, and whether the underlying datastore and backups receive appropriate protection.
- Use an external secrets or cloud key-management integration when it fits the team’s operating model, and define how rotation reaches workloads.
- Review secret access in RBAC separately from ordinary configuration access.
- Test revocation and rotation. A secret-management design is incomplete if applications cannot safely reload or replace credentials.
Do not treat base64 encoding as encryption. Also check rendered manifests and deployment logs: secrets can leak through templating, debugging output, or overly verbose error messages.
4. Pod security and workload configuration
Establish a baseline for workloads before they reach production. Review whether pods run as non-root users, whether privilege escalation is disabled, and whether Linux capabilities, host namespaces, host paths, and privileged containers are genuinely required. Apply read-only root filesystems where the application supports them, and define resource requests and limits to reduce the impact of runaway processes.
Use namespace-level pod security controls or an equivalent policy mechanism, with an explicit exception process for workloads that cannot meet the baseline. Exceptions should name an owner, explain the requirement, and include an expiry or review date. Without that last step, temporary exceptions tend to become permanent.
5. Network policies and exposed services
- Map ingress and egress paths for important namespaces, including traffic to cloud services, databases, registries, and monitoring systems.
- Start with policies that express known application flows, then validate them in a non-production environment before tightening enforcement.
- Use default-deny behavior where practical, followed by narrowly scoped exceptions for required communication.
- Review LoadBalancer, NodePort, Ingress, gateway, and service-mesh exposure. Confirm that each public endpoint is intentional.
- Include DNS, observability, identity, and update dependencies in policy tests; blocking them can create confusing operational failures.
Network policy behavior depends on the networking implementation and its configuration. Treat policy tests as part of the cluster’s deployment validation rather than assuming that a manifest alone proves isolation.
6. Image supply chain and admission controls
Define how images are built, scanned, signed or otherwise verified, promoted, and pulled. Prefer immutable references such as digests for release artifacts when your workflow can support them. Restrict which registries and repositories workloads may use, and remove unused pull credentials.
Admission controls can enforce requirements such as approved registries, non-root execution, required labels, resource settings, or image verification. Begin with policies that address clear risk and provide useful rejection messages. A policy that fails deployments without explaining the correction will encourage unsafe workarounds.
Connect these checks to the delivery workflow. The GitHub Actions CI/CD Pipeline Templates guide can help structure testing and security stages before deployment. Registry ownership and retention should also be documented; compare operational requirements with the options in the container registry comparison.
7. Runtime monitoring, audit logs, and recovery
Collect the signals needed to answer basic incident questions: who changed a resource, what changed, when it changed, which workload made an unusual request, and whether the behavior spread. Review Kubernetes audit logging, control-plane events, authentication records, image activity, network flows, and application logs according to the cluster’s architecture.
Monitoring should cover both security and reliability. Unexpected restarts, privilege changes, denied network connections, unusual API activity, and new externally exposed services deserve clear ownership. Use the cloud observability tools comparison and OpenTelemetry Collector configuration patterns as references when shaping collection and retention decisions.
Finally, verify that backups include the information required to restore workloads and their configuration. Run restoration exercises rather than relying on successful backup jobs alone. The Kubernetes backup tools comparison provides a starting point for evaluating recovery approaches.
Cadence and checkpoints
Use different review depths for different cadences:
Per change or deployment
Check image provenance, manifest policy results, RBAC changes, new secrets, service exposure, network-policy effects, and rollback readiness. Require review when a change adds a privileged container, host access, a cluster-wide permission, or a public endpoint.
Monthly
Review privileged identities, cluster-admin bindings, unused service accounts, secret rotation status, admission-policy exceptions, externally reachable services, failed authentication events, and notable audit-log findings. Confirm that alerts still reach an accountable team.
Quarterly
Run a broader control review. Revisit the threat model, restore a representative backup, test incident escalation, examine namespace boundaries, validate network policies, review supported platform and add-on versions, and remove controls that no longer match the architecture. If infrastructure is managed as code, compare the running cluster with its declared configuration and investigate unexplained differences. The Terraform project structure guide offers useful patterns for keeping environment changes reviewable.
How to interpret changes
A growing count of denied requests is not automatically evidence of a successful security program. It may indicate an effective new control, a broken dependency, or a deployment that was never tested against policy. Classify each change as expected, unexplained, or accepted exception, then assign a follow-up.
Pay particular attention to changes in privilege and exposure. A new cluster-wide binding, a newly public service, a pod gaining host access, or a workload receiving broader cloud permissions should trigger a documented review. Likewise, a sudden reduction in audit events may indicate a logging failure rather than improved behavior.
Track the time needed to remediate findings, the number of overdue exceptions, restoration test results, and repeated policy violations. These measures help distinguish a checklist that is being completed from a security process that is actually reducing operational risk. When an event becomes an incident, use a consistent SRE incident response template to preserve decisions, communications, and postmortem actions.
When to revisit
Revisit this Kubernetes security checklist at least monthly for access and exposure checks and quarterly for a full control review. Update it sooner after a cluster upgrade, networking or identity-provider change, migration to a new registry, adoption of a service mesh, major namespace redesign, new external integration, or security incident.
Make the review actionable: assign an owner, record the date, link evidence, mark exceptions with expiry dates, and create tickets for unresolved gaps. Finish by selecting the next review date and the few controls that need the most attention. A small checklist that is consistently revisited is more valuable than a comprehensive document that no team owns.
