"Can someone check if our cluster is actually okay?" is a question that comes up after a near-miss, before a compliance review, or when a new platform lead inherits infrastructure nobody's looked at critically in a year. The honest answer is almost always "probably not entirely" — not because the team is bad at their jobs, but because nobody audits their own work as rigorously as they'd audit someone else's, and Kubernetes accumulates configuration drift quietly enough that "it's been fine" and "it's actually fine" are different claims.
This is what auditing a Kubernetes cluster actually involves: what gets checked, why each area matters, how to prioritize what you find, and what separates a useful audit from a checkbox exercise.
Short answer
A real Kubernetes audit checks the cluster against the same production-readiness areas covered in the complete production readiness guide: security and RBAC, resource management, networking, availability, observability, and backup/recovery. What makes it an audit rather than a design review is that it's evidence-based — every finding is backed by something you can point at in the cluster (a specific ClusterRoleBinding, a specific Deployment with no resource limits), not a general impression.
Findings then get prioritized by three factors, not severity alone:
- Severity — what's the actual impact if this is exploited or fails?
- Blast radius — does this affect one workload or the whole cluster?
- Remediation effort — is this a five-minute label change or a project that needs its own scoping?
A cluster-admin binding on a compromised-adjacent service account is high severity, wide blast radius, and often low effort to fix (scope the role down) — that's a critical finding, first on the list. A missing PodDisruptionBudget on a low-traffic internal tool is low severity, narrow blast radius — real, worth fixing, but not what you drop everything for.
What actually gets checked
Security and access control. RBAC bindings — specifically, every ClusterRoleBinding and RoleBinding tied to cluster-admin or wildcard permissions, and whether they're justified. Pod-level security context (privileged containers, root execution, missing capability drops). Secrets handling — plaintext values in manifests versus an external secrets manager. Image provenance — mutable tags, unscanned images. Auditing Kubernetes RBAC covers the specific commands for the access-control portion of this in detail.
Networking. Whether NetworkPolicies exist at all, and if they do, whether they're actually default-deny or just present-but-permissive (a NetworkPolicy that exists but allows all traffic is worse than having none, because it creates false confidence). Ingress TLS configuration and certificate expiry. DNS health, since it's disproportionately fragile after security hardening work that forgot to account for it.
Resource management. Workloads with no requests or limits set — the single most common finding in nearly every audit, because it's easy to skip during initial setup and never revisited. Whether the numbers that are set reflect real usage or were guessed once and never updated.
Availability. Single-replica stateful workloads with no documented reason. Missing PodDisruptionBudgets. Whether replicas are actually spread across failure domains or coincidentally landed on the same node.
Observability. Whether alerting exists for the failure modes that matter (API server latency, node pressure, DNS error rates) or only for the obvious ones (pod crashes). Whether Kubernetes events and logs are retained anywhere beyond the default short window.
Backup and recovery. Whether backups exist, and — the part almost everyone skips — whether a restore has ever actually been tested. A backup that's never been restored from is an assumption, not a plan.
Operational readiness. Documented ownership, upgrade history versus the supported Kubernetes version window, and whether changes to the cluster are auditable (GitOps, or at minimum a change log).
None of this requires exotic tooling — most of it is kubectl get and kubectl describe output, cross-referenced against what the workloads on the cluster actually need. What it requires is doing it systematically and completely, which is exactly the part that's hard to do on your own infrastructure.
What access an audit actually needs
This is usually the first practical objection, and it's a reasonable one: handing a stranger cluster access sounds like it should require a lot of trust and a lot of setup.
In practice, almost everything above is checkable with read-only access — a scoped ClusterRole bound to a dedicated service account or user, granting get/list/watch on the resource types being reviewed (Pods, Deployments, RBAC objects, NetworkPolicies, and so on), nothing else. Nothing in the process above requires creating, modifying, or deleting anything in the cluster. If whoever's running the audit is asking for write access, cluster-admin, or a kubeconfig with no scoping at all, that's worth questioning — it's not what the work requires.
A few things genuinely can't be checked through the Kubernetes API at all, regardless of access level — control-plane internals (API server auth mode, admission controller configuration, etcd encryption), audit logging configuration, kubelet-level TLS settings, and cloud-provider IAM/KMS/network configuration. Those need to be verified separately, either through the cloud provider's own console/API or by a direct conversation about what's already in place — a credible audit says so explicitly rather than silently skipping them or guessing.
What a useful audit report actually looks like
A useful audit report is not a single number. "Security score: 72/100" tells you almost nothing actionable — not what's wrong, not how bad it is, not what to do about it.
A useful report has, per finding:
- What was found, specifically — the actual resource, not a category ("Service account
ci-deployin namespaceplatformis bound tocluster-adminviaClusterRoleBinding ci-deploy-admin," not "RBAC issues found"). - Severity, and why — what happens if this is exploited, or what breaks if this fails.
- Affected resources — so remediation has a concrete starting point, not a category to go search for.
- A specific recommendation — not "improve RBAC," but "replace the ClusterRoleBinding with a namespace-scoped Role granting only
get/list/createon Deployments in thecheckoutnamespace."
If you want to see this format rather than take it on description, the sample Kubernetes audit report shows exactly what a delivered report looks like, findings and all.
What teams commonly miss when auditing their own cluster
Three things, consistently:
Time. A genuinely thorough audit — checking every namespace's RBAC, every workload's resource configuration, every NetworkPolicy against what it's supposed to restrict — takes real, uninterrupted hours. It rarely happens as a dedicated task; it happens in the gaps between actual sprint work, which means it happens partially or not at all.
Objectivity about your own decisions. It's hard to flag your own architectural choice as a finding. A NetworkPolicy that was deliberately left permissive "temporarily" eight months ago reads differently to the person who made that call under deadline pressure than it does to someone looking at it cold.
A reference point for "normal." Is 40 RBAC bindings on a mid-size cluster reasonable, or high? Is a two-replica CoreDNS deployment adequate for your node count? Without having looked at a range of other clusters, it's genuinely hard to know whether what you're looking at is typical or a problem — everything looks normal when it's the only cluster you've configured.
When to self-audit vs. get an independent one
Self-auditing with the production readiness guide and the condensed checklist is the right call when you have the time to be thorough, the team includes someone with the Kubernetes depth to catch subtle issues (a NetworkPolicy that exists but doesn't actually restrict anything looks fine on a quick pass), and there's no external deadline forcing a faster turnaround.
An independent audit makes more sense when:
- You need it done this week, not whenever the team finds spare time between sprints.
- You want an outside perspective specifically because internal review keeps missing things — a second, less-invested set of eyes catches what familiarity misses.
- You're inheriting a cluster — a new platform lead or a team taking over infrastructure from a previous owner benefits from an objective baseline rather than trusting undocumented history.
- You're preparing for a compliance review or a fundraising technical diligence process and need a written assessment as evidence, not just "we checked and it's fine."
It's also worth being honest about the trade-off in plain terms: doing this thoroughly yourself costs engineer-hours pulled from other work, spread out over however long it takes to find the uninterrupted time — which is exactly the scenario that turns into "we'll get to it next sprint" indefinitely. A fixed-scope external audit trades that for a fixed price and a fixed turnaround. Neither is universally the right call; it depends on whether the constraint you're actually facing is expertise, objectivity, or just calendar time.
Conclusion
Auditing a Kubernetes cluster properly means working through the same production-readiness areas systematically, backing every finding with a specific resource rather than a general impression, and prioritizing by severity, blast radius, and remediation effort — not fixing whatever's easiest first. Most of it you can do yourself with enough time and the right checklist.
If you'd rather have that done this week, by someone whose only job during the engagement is finding what's wrong with your cluster rather than fitting it in around other work, that's exactly the Kubernetes Cluster Audit — a fixed $500 engagement, written report in 3-5 business days, no obligation beyond the audit itself.