Kubernetes Security Audit: How to Review Cluster Configuration, Permissions and Governance

Consider a hypothetical situation. A fictional B2B platform is preparing to onboard a large enterprise customer. The product runs on several Kubernetes clusters: each customer gets its own namespace, deployment goes through GitOps, and some add-ons come from the managed-service provider. The customer's security questionnaire asks how its data is isolated from other tenants and who inside the company can change the configuration of its environment. The CTO is confident: "every customer has its own namespace, so everything is isolated." The head of platform is less sure, but cannot quickly show who has access to secrets and through which roles, which pods run with elevated privileges, or whether the network policies actually block anything.

The situation is invented, but the question is real. What answers it is not another scanner but a configuration and governance audit: a review of what exists in the cluster, who is allowed to do what, which restrictions are actually enforced on workloads, who owns them, and which artifacts can confirm a fix. What follows covers how to plan such an audit, where the limits of its conclusions lie, and what to accept at the end.

What a Kubernetes configuration and governance audit examines

In this sense, a Kubernetes security audit is an authorized, structured assessment of how a cluster estate is configured, who governs it and which restrictions actually take effect in it. A single-application test covers one layer. A cluster consists of several layers, and each fails in its own way: API access, identities and role bindings, workload configuration, networking, secrets, audit logs and the image supply chain.

How this audit differs from a technical cluster assessment

The two kinds of work should not be confused. A technical assessment, covered in a separate article on Kubernetes security assessment: scope, method and prioritization, focuses on finding and confirming attack paths. A configuration and governance audit answers a neighbouring but different question: does the actual state of the cluster match what the organization considers its controls, and does every control have an owner and evidence that it works? It relies more on reading manifests, policies and bindings than on active exploitation, and its main output is not a list of vulnerabilities but a map of permissions, restrictions and accountability with testable acceptance criteria.

Inventory as the first deliverable

The audit starts with the question "what is actually there". That includes clusters and their versions, namespaces and their purpose, nodes and node pools, installed operators, controllers and admission webhooks, the network plugin, how secrets are stored, image sources and connected external identity systems. Without this inventory it is impossible to say honestly what was in scope. It should be recorded with versions and a snapshot date: clusters are reconfigured often, and an undated snapshot quickly loses its value as evidence. This step alone often surfaces forgotten test namespaces, operators with no owner, or a cluster nobody considered production.

Four boundaries that must not be conflated

The most common mistake in discussing Kubernetes security is treating "isolation" as a single property. In practice an auditor checks at least four different boundaries, and each rests on its own mechanisms.

The first is control-plane permissions: who can read, create and modify objects through the API. The second is workload identity: which service account a pod runs as and what that account can do in the API and in external systems. The third is container-runtime and host isolation: how well a process in a container is separated from the host kernel and file system. The fourth is network enforcement: which connections between pods, services and the outside world are actually blocked.

Why a namespace is not hard isolation

A Kubernetes namespace is a mechanism for grouping and scoping API objects within a single cluster. It defines a naming scope and a convenient anchor for roles, quotas and policies. On its own it creates neither network nor kernel isolation. The Kubernetes multi-tenancy documentation states plainly that the namespace isolation model requires configuring several other resources and networking plugins, as well as following security best practices. By default, pods in a cluster can exchange traffic with each other, and containers remain processes on the node's shared kernel.

So "every customer gets its own namespace" describes an organizational boundary, not proven isolation. To turn it into a security boundary you need restrictive RBAC grants, no access to cluster-scoped resources, network policies with a plugin that enforces them, workload restrictions at admission and, for untrusted tenants, node separation or sandboxing.

RBAC: read the grants, not the role names

Identity and access are reviewed first, because the cluster API controls everything else. For each subject the auditor needs answers to three questions: which identities can authenticate, by what mechanism, and what each is permitted to do once authenticated. Names such as "readonly" or "developer" guarantee nothing: only the rules inside Role and ClusterRole objects, and whom they are bound to, matter.

Dangerous verbs and indirect escalation paths

Some permissions are dangerous not directly but through their consequences. The right to create pods in a namespace in practice allows launching a pod with any service account in that namespace and mounting any of its secrets; the Kubernetes documentation warns about this specifically in its section on secrets.

Grants on the escalate, bind and impersonate verbs need particular care: depending on their scope and target object, they can allow privilege escalation — for example, creating or binding a role broader than one's own, or acting as another subject. But this is not an automatic conclusion: a bind right limited to one narrow role in one namespace, or impersonate restricted to a specific service identity, has to be assessed by what actually becomes reachable.

Wildcards in resources or verbs grant more than intended and widen automatically when new resource types appear. Reading secrets through list and watch is as significant as through get.

It also matters which object grants a role. A ClusterRoleBinding grants a ClusterRole's permissions cluster-wide — across all namespaces and on cluster-scoped resources. A RoleBinding can reference a ClusterRole, but then the permissions apply only within the RoleBinding's own namespace: this is how one standard role is reused in different namespaces without widening its reach. Confusing the two cuts both ways: a cluster-wide grant can be missed, or a local one overrated. Groups coming from an external identity provider deserve the same attention.

Service accounts and workload identity

Every pod runs as some service account. If the token is mounted automatically and the workload does not need it, anyone who gains code execution in the container also gains that account's rights. The audit records which accounts are used, where automounting is disabled, what bindings the default accounts have and how workload identity links to cloud or external roles. That last link is often the widest path from the cluster outward, and it is easy to miss when looking only at RBAC.

Workload and admission controls

Pod configuration determines how tightly a container is coupled to its node. The auditor looks at privileged mode, added kernel capabilities, host path mounts, use of the host network, PID or IPC namespace, running as root, allowed privilege escalation, seccomp and AppArmor profiles and a read-only root file system.

A privileged pod is a finding, not proof of escape

A privileged pod or a mount of the host root is a serious finding: such a configuration removes most of the barriers between the container and the node. But it is not yet proof of an exploitable escape through a kernel vulnerability. A configuration finding says the boundary is weakened or absent; a claim of escape requires a separate authorized test, the conditions under which it reproduces, and evidence. The report must keep these levels apart: "node isolation is not enforced for workload X" and "breakout to the node was demonstrated" are different conclusions with different consequences. If the goal is specifically to confirm that breakout is possible, that is a separate type of engagement, described in the article on container escape penetration testing.

Admission policies as the enforcement point

Correct configuration of individual pods means little if nothing prevents an incorrect one from being deployed tomorrow. The audit therefore checks admission control: the built-in Pod Security Admission with its privileged, baseline and restricted levels, or an external policy engine. The key questions are which mode the policy runs in (enforce, audit or warn), which namespaces it covers, which exemptions have been granted, by whom and for how long, and what happens when the webhook is unavailable. Warn mode is a detective control: it surfaces violations but does not block deployment, so it is not a preventive control. The report should not present it as enforcement. Admission webhooks and operators are themselves code with broad rights, and their own bindings are also in scope.

Network, secrets and egress

NetworkPolicy works only if the plugin supports it

A NetworkPolicy object is a declaration of intent. The Kubernetes documentation states that network policies are implemented by the network plugin, and that creating a NetworkPolicy without a controller that implements it has no effect. The auditor therefore checks three things at once: whether the installed plugin supports policies, whether namespaces have a default-deny policy, and whether selectors match the pods' real labels. Without default deny, a pod not selected by any policy remains open to inbound connections. The check does not stop at reading YAML: a short, agreed connection test between two pods shows whether the rule actually applies.

Secrets: who can actually read them

By default, Kubernetes secrets are stored unencrypted in etcd, and anyone with API access and the right permissions, or with access to etcd, can read them. A secrets review therefore comes down to the question of actual access: is encryption at rest enabled, who can read secrets directly, who can create pods and thereby mount them, are values kept out of logs, images and repositories, how are secrets delivered to the workload — through volumes or environment variables — and is the chosen method justified by the threat model and potential exposure, is an external store used, and how does the workload authenticate to it. Any secret values found are documented by reference to the object, not copied, and passed to the owner through an agreed channel.

Egress as a separate scope boundary

Outbound traffic is often overlooked: rules are written for inbound connections, while everything outbound is allowed. For an audit this means two things. First, check whether egress is restricted for workloads that need no access to the internet or to the cloud node's metadata service. Second, egress is a question of engagement scope: if a tester checks whether a pod can reach outside, it must be agreed in advance which external addresses are acceptable as test targets and what to do if an unexpected route is found. Without that, even a harmless connection check can touch a third-party system.

Method: from authorization to staged testing

NIST SP 800-115 still sets good process discipline. Its formal assessment process is described as planning, execution and post-execution. For a cluster audit, an editorial adaptation of that scheme works well: planning, conducting examinations and tests, analyzing findings, and remediation with retest. This is a practical sequence, not an official NIST model. The guide predates mainstream container orchestration, so it supplies process discipline, while specific cluster settings come from current platform documentation and hardening guidance that the audit team obtains and verifies itself.

Written authorization and stop conditions

Work starts with written authorization from the system owner. It lists the clusters, namespaces, accounts and environments in scope, the permitted techniques, testing windows and stop conditions. No framework grants that authorization. For managed platforms, the team also checks what the provider's terms allow and records which control-plane components are by definition unavailable for review.

Read first, then targeted tests

SP 800-115 separates examinations — review of documentation, configuration and logs — from testing, which actively exercises a system. For clusters the distinction is fundamental. Read-only review of manifests, role bindings, admission policies and audit logs carries little operational risk. Active actions in production can affect the availability of shared infrastructure. A defensible sequence is examination first, then targeted tests on a staging replica or within agreed limits, and only where a test answers a question that reading cannot.

1. AuthorizationThe owner records in writing the clusters, namespaces, accounts, techniques, windows and stop conditions.
2. InventoryThe team describes clusters, versions, operators, webhooks, network plugin and secret storage with a snapshot date.
3. Configuration reviewRBAC, service accounts, pod security contexts, admission policies and network policies are analyzed read-only.
4. Targeted testsActive checks run only for questions that reading cannot answer, and within agreed limits.
5. Acceptance and retestEach finding gets an owner, a closure criterion and a repeat check of the fix.

Evidence handling

For reproducibility, record cluster and component versions, the identity used for each action and timestamps. Conclusions about permissions should be backed not only by a role export but by an access check performed as a specific subject: this quickly shows the gap between how a role was intended and what it actually allows.

Ownership and governance: every finding needs an owner

A configuration audit is only as useful as the extent to which its results reach people who can change something. So an owner is recorded for every cluster, namespace, operator and policy. A finding without an owner is almost certain to stay open.

Findings as gaps against outcomes, not checklist failures

Benchmark-style checks give a clear pass or fail, but not every failed check matters equally to the business. NIST CSF 2.0 lets results be expressed as gaps against the organization's target outcomes: leadership sees which ones affect the risk profile, while engineers still receive precise, testable items. A recurring misconfiguration should lead to a change in templates, policies or pipelines, not to a manual edit of one manifest. If clusters are defined as code, a fix in the template is the root-cause fix; how to review such templates is covered in the article on infrastructure as code security assessment.

Managed platforms and suppliers

Many clusters run on managed platforms and use third-party add-ons, so part of governance sits with suppliers. CISA's Secure by Design principles hold that products should be secure by default, with multi-factor authentication, logging and single sign-on available at no extra cost. The Secure by Demand guidance encourages customers to ask matching questions during procurement, and the audit team can apply the same logic: what is enabled by default, are control-plane audit logs available without additional licensing, how does the supplier deal with vulnerability classes. The answers go into the audit record with documentary support, not on someone's word.

Prioritizing findings

A cluster produces a long list of findings, and prioritization decides whether the audit changes anything.

Paths to privilege matter more than hygiene

At the top are findings that add up to a path: the right to create pods plus a privileged context plus no admission policy; a broadly scoped token plus open egress. An isolated hygiene issue such as a missing label or a suboptimal resource limit ranks lower, even if there are many such items. For the platform's own code — controllers, operators, admission webhooks — the CWE Top 25 view of weakness classes is useful: defects in that code map to CWE classes, and MITRE notes that weaknesses such as command injection attract adversarial attention.

Where the cluster audit ends

Applications running in the cluster are part of the overall picture, but reviewing them is a separate layer. If an application relies on network policies, ingress TLS or a secrets store, those platform controls fall within an OWASP ASVS-based verification; requirements should be cited with a version tag, such as v5.0.0-1.2.5, because identifiers change between versions. The OWASP Top 10 is suitable for discussing risk with development teams, but it does not replace a verification standard.

Acceptance: which artifacts close the audit

The audit is complete not when the report is sent, but when, for each significant finding, it is clear who closes it and which evidence confirms that.

Retesting and turning checks into controls

A fix counts as confirmed after a repeat check using the same method that found the problem, with version and date recorded. How to prove that a fix really works is covered in detail in the article on penetration test remediation validation. Because clusters are reconfigured often, a single snapshot ages quickly: SP 800-115 speaks of designing, implementing and maintaining test and examination processes. The most valuable audit checks are worth turning into repeatable rules — in admission policies, in the pipeline or in a regular permissions reconciliation.

What an audit and a pentest are not

A configuration audit and a pentest provide evidence about the state of the system at the time of the check and within the agreed scope. They are not an attestation, a certification or an auditor's opinion on the adequacy of controls. The report can become material for a regulator or customer, but the conclusion on compliance is made by whoever is entitled to make it.

Decisions for the buyer

Internal teams are well able to run continuous configuration checks. An independent assessment is especially useful when the scope is large, evidence is needed for a customer or regulator, or the internal team built the platform it would be reviewing. Either way, audit quality depends less on tools than on authorization, evidence discipline and prioritization that leadership can act on.

What to prepare before kickoff

Back to the hypothetical platform from the opening. Before answering the customer, it should decide what exactly it claims: organizational separation by namespace, or isolation of untrusted tenants. Scope, the acceptability of active tests and the set of acceptance artifacts all depend on that. It helps to gather in advance a list of clusters and owners, a description of the tenant model, an export of roles and bindings, a list of admission and network policies with the plugin named, and the managed platform provider's terms. With that set it is easier to start a conversation with any provider; the pentest scope preparation section on Pentest.red helps put it together.