Kubernetes Security Checklist: Baseline Controls to Review Every Quarter

Overview

This article provides a reusable kubernetes security checklist for baseline reviews. It is not a compliance framework and it is not meant to replace threat modeling for sensitive workloads. Instead, it gives you a practical set of controls to verify every quarter so your cluster security posture does not slowly degrade through exceptions, legacy defaults, and one-off changes.

Quarterly reviews matter because Kubernetes environments change continuously. New namespaces appear. CI/CD permissions expand. Admission policies get added but not enforced. Teams migrate from one ingress setup to another. Images start pulling from new registries. Nodes get upgraded while old daemonsets keep broad privileges. Security issues in Kubernetes are often less about one catastrophic misconfiguration and more about accumulation: too much access, too little isolation, and not enough visibility.

A good baseline security review should answer five simple questions:

• Who can do what? Review identity, RBAC, service accounts, and administrative paths.
• What can run? Review admission policies, image controls, pod security settings, and workload privileges.
• Who can talk to whom? Review network segmentation, ingress paths, and egress assumptions.
• How are secrets and sensitive data handled? Review storage, access, rotation, and exposure patterns.
• Can you detect and respond to misuse? Review audit logs, runtime visibility, alerting, and incident readiness.

If you manage multiple clusters, apply this checklist consistently but do not force every environment into identical controls. A development cluster may allow broader outbound access than production. A multi-tenant platform cluster may need stricter namespace boundaries than a single-team cluster. The goal is a clear baseline, documented exceptions, and a review habit that survives staff and tooling changes.

Where possible, connect this checklist to your platform standards. If your platform team maintains approved deployment patterns, tie security defaults into those golden paths so teams inherit guardrails instead of manually reproducing them. For a broader platform approach, see Golden Paths for Platform Teams: Examples, Guardrails, and Rollout Strategy.

Checklist by scenario

Use the scenarios below to structure a quarterly review. You do not need to treat every item as equally urgent. Start by identifying internet-facing workloads, shared clusters, production namespaces, and sensitive data paths.

1. Cluster and control-plane baseline

Start with the cluster-level controls that shape everything else.

• Kubernetes version support: Confirm clusters are on supported versions and that your upgrade plan is current. Unsupported versions usually mean weaker defaults, missing fixes, and more operational risk. Keep this aligned with your release and upgrade calendar using Kubernetes Release Calendar and Support Timeline and Kubernetes Version Skew Policy Explained.
• API server exposure: Check how the API server is exposed, which networks can reach it, and whether administrative access is limited to trusted paths.
• Audit logging: Verify audit logging is enabled and retained long enough to support investigations. Logging without retention or review is only partial coverage.
• Encryption of secrets at rest: Confirm the cluster is configured to protect secret data in storage and that the key management approach is understood.
• Node registration and lifecycle controls: Review how nodes join the cluster, how old nodes are removed, and whether unmanaged nodes can persist longer than expected.
• Administrative break-glass process: Ensure emergency admin access exists, is documented, and is auditable rather than informal.

2. Identity, RBAC, and service account review

Identity sprawl is one of the most common weaknesses in a Kubernetes environment. Quarterly review is usually enough to catch risky growth.

• Cluster-admin assignments: List all users, groups, and automation identities with broad administrative rights. Validate each one still needs that scope.
• Namespace role drift: Review roles and role bindings in production namespaces, especially temporary access granted during incidents or migrations.
• Service account usage: Identify workloads using the default service account or highly privileged service accounts. Replace broad access with task-specific permissions.
• Human vs machine access: Separate human operator access from CI/CD and controller access so you can reason about each category clearly.
• Short-lived credentials: Prefer identity flows that avoid long-lived static credentials where possible.
• Cloud IAM integration: If Kubernetes identities map to cloud permissions, review both layers together. A modest Kubernetes role can still become risky if it unlocks broad cloud resources.

If your delivery model includes GitOps tooling, review repository permissions, controller credentials, and sync authorization along with RBAC. Teams comparing controller choices may also want ArgoCD vs Flux: Which GitOps Tool Fits Your Team in 2026?.

3. Admission, policy, and workload guardrails

This is where many kubernetes security controls become enforceable rather than advisory.

• Pod security standards or equivalent guardrails: Confirm restricted defaults for production workloads where feasible, and document namespaces that are exempt.
• Privileged containers: Review workloads requesting privileged mode, hostPID, hostNetwork, hostIPC, or broad Linux capabilities.
• Host path mounts: Identify pods mounting sensitive host paths. These deserve explicit review because they reduce isolation quickly.
• Run as non-root: Check whether workloads are configured to avoid root by default, with exceptions tracked.
• Read-only root filesystem: Validate where this can be enabled and where teams still depend on mutable container filesystems.
• Allowed registries and image provenance: Review which registries are trusted and whether policy restricts unknown or public image sources for production namespaces.
• Signature and verification strategy: If you verify signed images or attestations, confirm the policy is enforced consistently rather than only in selected clusters.
• Resource guardrails: Security and reliability often intersect. Missing requests and limits can increase blast radius during abuse or runaway workloads. Review your baseline using Kubernetes Resource Requests and Limits: Best Practices by Workload Type.

4. Network segmentation and exposure

Many clusters still rely too heavily on trust inside the network. A quarterly review should assume internal traffic deserves controls too.

• Default deny posture: Check whether sensitive namespaces use default-deny network policies for ingress, egress, or both.
• Namespace isolation: Review whether application namespaces can reach each other unnecessarily.
• Ingress exposure: Inventory public endpoints, wildcard routes, old test hosts, and forgotten ingress objects.
• Egress destinations: Review which workloads can reach the internet, package mirrors, external APIs, and internal control systems.
• Administrative interfaces: Confirm dashboards, metrics UIs, and internal services are not exposed more broadly than intended.
• Service mesh or network overlay assumptions: If you use additional networking layers, verify policy intent matches actual traffic paths.

5. Secrets, configuration, and data handling

Secret handling deserves its own pass because teams often confuse “stored in Kubernetes” with “securely managed.”

• Secret sprawl: List namespaces with unusually high secret counts or duplicate credentials.
• Static credentials in manifests: Check repositories and deployment templates for embedded credentials or tokens.
• External secret systems: If you sync secrets from an external manager, review the operator permissions, refresh behavior, and failure modes.
• Rotation practice: Confirm high-value credentials are rotated on a schedule and after role changes or incidents.
• ConfigMap misuse: Ensure sensitive data is not stored in ConfigMaps out of convenience.
• Volume and log exposure: Check whether secrets are being written to logs, temp files, or shared volumes during startup scripts.

6. Runtime detection, observability, and response

Prevention helps, but baseline security also requires enough runtime visibility to investigate suspicious behavior.

• Container and node telemetry: Confirm you can see restarts, exec activity, unexpected outbound traffic, and unusual privilege use.
• Audit and security event routing: Review where security-relevant events go and who actually sees them.
• Alert quality: Check whether alerts distinguish noisy policy violations from real response triggers.
• Incident runbooks: Ensure Kubernetes-specific response steps exist for credential exposure, suspicious pods, compromised images, and lateral movement.
• Severity model: Tie cluster and workload incidents to a clear severity framework using Incident Severity Matrix: How to Define Sev Levels That Actually Work.
• SLO and reliability overlap: Some security issues first appear as reliability anomalies, so align incident review with service objectives where useful. See SLO Examples by Service Type.

7. Software supply chain and deployment workflow

A strong kubernetes hardening checklist should include the systems that build and deploy workloads, not just the cluster that runs them.

• Build pipeline permissions: Review what CI/CD identities can push, deploy, or change in-cluster resources.
• Environment separation: Confirm production deployment paths are distinct from lower environments and not controlled by overly broad credentials.
• Artifact immutability: Prefer immutable references and predictable promotion workflows over mutable tags alone.
• Dependency and image scanning: Check whether scanning exists, but also whether exceptions are tracked and revisited.
• Infrastructure as Code review: Compare intended security settings in IaC with actual cluster state to catch drift. If your team is revisiting IaC tooling, see Terraform vs Pulumi vs OpenTofu: A Practical IaC Comparison.

What to double-check

If your review time is limited, prioritize the places where teams often assume security exists because a tool was installed once. These are the controls worth double-checking manually.

• Policy exists but is not enforced: Admission rules may be in audit or warn mode indefinitely. Confirm what is blocking enforcement and whether exceptions are time-bound.
• Default service account usage: This remains a quiet source of unnecessary privilege in many namespaces.
• Temporary access that became permanent: Incident-related RBAC changes, emergency ingress exceptions, and migration allowances should all have expiry dates.
• Internet exposure through indirect paths: Review load balancers, ingress controllers, DNS records, and cloud firewall rules together rather than in isolation.
• Secrets copied across environments: Shared credentials between staging and production reduce isolation and complicate incident response.
• Exceptions for system namespaces: Platform components sometimes carry broad privileges indefinitely. Some of that may be required, but it should still be explicit and reviewed.
• Logging without ownership: Audit data is only useful if a team knows where it goes, how long it stays, and how to search it under pressure.
• Upgrades without security review: Cluster version changes can alter defaults, deprecate admission behavior, or leave old policies ineffective. Build a quick security validation into upgrade work.

Common mistakes

The most common Kubernetes security mistakes are operational, not theoretical. They come from uneven rollout, ownership gaps, and friction between platform standards and application delivery.

• Treating hardening as a one-time project: Kubernetes security drifts quickly. A baseline review only works if it repeats.
• Focusing only on production: Development and staging clusters often have weaker controls but wide access. Attack paths and accidental exposure can start there.
• Writing policies with no adoption path: If teams cannot meet the standard through normal deployment workflows, they will route around it. Build guardrails into templates and platform defaults.
• Confusing visibility with protection: Dashboards and scanners do not replace enforcement, segmentation, or least privilege.
• Ignoring egress: Ingress gets attention because it is visible. Egress often stays open and under-reviewed.
• Skipping ownership for exceptions: Every privileged workload and every policy exemption should have a named owner and review date.
• Separating security from platform engineering: The strongest controls are usually the ones developers get by default. If you are shaping internal platforms, integrate security controls early. Teams evaluating portal-driven standards may also find Backstage Adoption Guide: When an Internal Developer Platform Actually Needs It useful.

When to revisit

Use this checklist every quarter, but do not wait for the calendar if the environment changes materially. Revisit your kubernetes baseline security whenever one of these events occurs:

• Before seasonal planning cycles: This is the best time to convert recurring exceptions into platform work and backlog items.
• When workflows or tools change: New CI/CD systems, GitOps controllers, ingress layers, or secret managers usually introduce fresh permissions and trust assumptions.
• Before and after cluster upgrades: Version changes can affect admission behavior, deprecated APIs, and default security settings.
• After incidents or near misses: Any credential leak, exposed service, suspicious workload, or privilege escalation attempt should trigger a targeted review.
• During organizational changes: Team mergers, platform centralization, and ownership shifts often leave stale access behind.
• When moving to a shared platform model: Multi-tenant clusters increase the need for clear namespace boundaries, service account discipline, and policy enforcement.

To make this practical, turn the checklist into a 60-minute quarterly review with clear outputs:

1. Export a current list of clusters, namespaces, admins, privileged workloads, and public endpoints.
2. Mark each checklist item as meets baseline, exception with owner, or needs remediation.
3. Create a short remediation list with deadlines, not a large aspirational roadmap.
4. Attach evidence to each exception so the next review starts with context.
5. Fold repeated fixes into platform defaults, templates, or policy enforcement.

If you want this checklist to stay useful, keep it boring, specific, and repeatable. A quarterly review should not require a task force. It should give your team a stable way to catch drift, tighten access, and verify that your cluster security best practices still match how your platform actually operates.