Kubernetes clusters drift from their hardened baseline one exception at a time: a cluster-admin binding for an urgent fix, a privileged pod for a monitoring agent, a namespace created without a network policy, a minor version left behind after its end of life. This health check is a recurring, measurable review of Kubernetes clusters already in production, whether self-managed or a managed cloud service. It turns the questions a platform lead, auditor or CISO would ask into ten metrics with formulas and thresholds, covering cluster-admin bindings, service account token mounting, privileged pods, network policy, image signature enforcement, secrets in environment variables, API server exposure, audit logging, version support and admission policy violations. It suits teams searching for a "Kubernetes health check", a "Kubernetes security audit checklist" or "k8s security KPIs".
This page measures; it does not explain how to harden a cluster. For the hardening baseline itself, use the Kubernetes Security Checklist, and for architecture and threat context, the Kubernetes Security Guide. Go back to them, and to the deeper guides in the remediation map, for every finding this review raises.
What this health check covers
The review asks: if one workload or one credential in this cluster were compromised today, how far could an attacker go, and would anyone see it? It covers every production cluster and, separately, any non-production cluster that holds production data or credentials. In scope:
- Identity and authorisation: who and what holds cluster-admin or equivalent rights, and which pods carry an API token they do not need. Service accounts are non-human identities, and in most clusters they outnumber human users by a wide margin.
- Workload posture: privileged pods, Pod Security enforcement, network policy and secrets exposed through environment variables.
- Supply chain at admission: whether only signed images from approved registries are admitted, and how often admission policies reject or warn.
- Control plane: API server exposure, audit logging and whether each cluster runs a supported minor version.
Who runs it: the platform engineering or cluster operations lead collects the data; the cloud security lead reviews; the CISO signs off. What it is not: a full CIS Benchmark scan or a penetration test, though both make good inputs. The automated benchmark pass rate belongs to the hardening checklist; these ten metrics measure the controls an attacker tests first.
Key takeaways
- Count cluster-admin, not just admins. Bindings to cluster-admin, wildcard roles and the system:masters group all grant full control. The Kubernetes documentation notes that system:masters membership bypasses RBAC entirely and cannot be revoked by removing bindings.
- Most pods do not need an API token. A mounted service account token in a pod that never calls the API is free credential material for an attacker; measure how many pods carry one.
- Privileged pods are node access. The Baseline Pod Security Standard forbids privileged containers, host namespaces and hostPath volumes; every exception should be named and dated.
- Admission is where policy becomes real. Image signature checks and Pod Security only protect namespaces where they are enforced, not just audited or warned.
- Audit logging is off until configured. The API server logs no audit events without an audit policy file, so check every cluster, including managed ones where it is a setting.
How to use this template
Copy the metrics table and findings log into your own tracker, then run this Kubernetes platform health check per cluster at the cadence below. Score each metric against the thresholds, roll results up by environment, and record every amber or red result as a finding with an owner and a due date. Keep each quarter's extracts so the trend is visible as clusters, teams and versions change.
Cadence and sign-off
| Review | Frequency | Owner | Approver | Evidence kept |
|---|---|---|---|---|
| Cluster-admin and wildcard binding review | Monthly | Platform engineering lead | Cloud security lead | Binding export per cluster, approved list, removal tickets |
| Admission policy violation review | Monthly | Platform security engineer | Platform engineering lead | Deny, warn and audit events by namespace and policy |
| Full metrics review (this page) | Quarterly, per cluster | Platform engineering lead | CISO | Metrics table, raw extracts, findings log |
| Version support and upgrade plan check | Quarterly, and at each upstream minor release | Cluster operations | Platform engineering lead | Cluster version list with end of life dates, upgrade schedule |
| Exception register review | Quarterly | Platform security engineer | Cloud security lead | Privileged pod, network policy and admission exceptions with expiry |
Metrics
NHI Mgmt Group recommended thresholds; adjust to your risk appetite. "System namespaces" means those that run the control plane, networking, storage and security add-ons; report them separately from application namespaces so add-on exceptions do not hide application drift.
| ID | Metric | Formula | Data source type | Green | Amber | Red |
|---|---|---|---|---|---|---|
| K8S-01 | Cluster-admin bindings | Subjects (users, groups, service accounts) bound to cluster-admin, to a role with wildcard verbs and resources, or in system:masters, that are not on the approved break-glass list | ClusterRoleBinding and RoleBinding export, approved list, client certificate records | 0 | 1 to 2 with a dated change ticket | 3 or more, or any human user or system:masters member outside break-glass |
| K8S-02 | Unneeded service account token mounts | Pods with an automounted service account token whose service account made no API request in 30 days ÷ pods with an automounted token | Pod specs, API server audit log (requests by service account) | Below 10% | 10% to 30% | Above 30% |
| K8S-03 | Privileged pods | Running pods in application namespaces that are privileged, share host network, PID or IPC namespaces, or mount hostPath ÷ running pods in application namespaces | Pod spec export, exception register | 0%, system namespaces on an approved list | Above 0% to 1% with dated exceptions | Above 1%, or any without an exception |
| K8S-04 | Network policy coverage | Application namespaces with a default-deny ingress and egress policy plus explicit allow rules ÷ application namespaces | NetworkPolicy export, namespace list, CNI enforcement status | At least 95% | 80% to below 95% | Below 80%, or a CNI that does not enforce policy |
| K8S-05 | Image signature enforcement | Application namespaces where admission enforces signature verification and an approved registry list ÷ application namespaces | Admission controller policy export and mode, namespace list | 100% enforcing | At least 80% enforcing, rest in audit | Below 80% enforcing |
| K8S-06 | Secrets exposed as environment variables | Containers that load a Secret value into an environment variable ÷ containers that consume any Secret | Pod spec export (env and envFrom secret references, volume mounts) | Below 10% | 10% to 30% | Above 30% |
| K8S-07 | API server public exposure | Clusters whose API server endpoint is reachable from the internet without an IP allowlist or private-only endpoint ÷ clusters | Cloud provider cluster configuration, external attack surface scan, load balancer and firewall rules | 0% | Allowlisted public endpoint on non-production clusters only | Any production cluster open to the internet, or any non-production cluster open without an allowlist |
| K8S-08 | Audit log coverage | Clusters with an audit policy that records at least Metadata for all requests (Metadata only for Secrets, so values are never logged) and Request level for RBAC changes and pod exec, delivered to the central log store every day in the period ÷ clusters | API server audit configuration, SIEM or log store per-cluster reporting | 100% | Policy present, with gaps in delivery under 72 hours | Any cluster with no audit policy, or silent for 72 hours or more |
| K8S-09 | Version support status | Clusters on a Kubernetes minor version still within upstream (or managed service) patch support, and on a patch release less than 90 days old ÷ clusters | Cluster version list, upstream release and end of life calendar, managed service support calendar | 100% | Supported, but ending within 90 days with no scheduled upgrade, or patch over 90 days old | Any cluster past end of life |
| K8S-10 | Admission policy violations | Admission denials and audit or warn violations for Pod Security and custom policies, per 100 deployments, with the share of namespaces still only in audit or warn mode | Admission controller events, Pod Security Admission audit annotations, deployment count from CI/CD | Falling quarter on quarter and under 5 per 100 | Flat, or 5 to 15 per 100 | Rising, or above 15 per 100 |
Report every metric per cluster and roll up by environment. A single cluster with red K8S-01 or K8S-07 makes the environment red regardless of the average.
How to collect the data
Use read-only exports from the cluster API, the API server audit log and the cloud provider's cluster configuration. A dedicated read-only audit identity with a short-lived credential keeps the review itself from adding standing access.
- Build the cluster list. Pull it from every cloud account and subscription plus the self-managed estate, not from a spreadsheet. Unknown clusters are the first finding.
- Export RBAC. List ClusterRoleBindings and RoleBindings that reference cluster-admin, roles with wildcard verbs or resources, and roles granting escalate, bind, impersonate or nodes/proxy, which the Kubernetes RBAC good practices page treats as escalation paths (K8S-01). Check identity provider group mappings and any issued client certificates for system:masters. The How to audit Kubernetes cluster admin bindings guide walks through the review.
- Join token mounts to API usage. From pod specs, list pods where automountServiceAccountToken is not false at pod or service account level; from the audit log, list service accounts that made API requests in the last 30 days (K8S-02). The How to find unused Kubernetes service accounts guide helps here.
- Scan pod specs for privileged security contexts, host namespaces, hostPath volumes and Secret references through env or envFrom (K8S-03, K8S-06). Join exceptions to the exception register.
- Export network policies per namespace and confirm that the cluster network plugin actually enforces them (K8S-04).
- Export admission configuration: Pod Security Admission labels per namespace (enforce, audit, warn), policy engine rules and their mode, and image verification and registry rules (K8S-05, K8S-10). Count denials and warnings from admission events against deployment counts from CI/CD.
- Check API server exposure from the cloud provider configuration and an external scan of the endpoint, including authorised network ranges (K8S-07).
- Check audit logging: the presence of an audit policy and backend on each cluster, and daily delivery to the central store (K8S-08). The Kubernetes Audit Log Detection Guide covers what the policy should record.
- Compare versions with the upstream release calendar and any managed service calendar (K8S-09). As checked on 13 November 2026, upstream Kubernetes maintains the three most recent minor releases and gives each about a year of patch support; managed services publish their own windows.
Red flags that need action now
- A human user, CI system or third-party integration bound to cluster-admin, or any certificate issued with the system:masters group.
- A role granting escalate, bind, impersonate or nodes/proxy to anything outside the control plane.
- A production API server reachable from the internet with no allowlist.
- A production cluster with no audit policy, or audit events not leaving the cluster.
- Privileged or host-namespace pods in an application namespace with no exception record.
- Application namespaces still on Pod Security warn or audit only, a year after rollout.
- A cluster past its minor version end of life.
- Admission image verification switched to audit mode to unblock a release and never switched back.
- A service account token Secret of the legacy, non-expiring type still in use.
Findings log
Log each amber or red result and each red flag. Carry open items into the next quarter.
| ID | Finding | Metric | Severity | Owner | Due date | Status |
|---|---|---|---|---|---|---|
| HC-K8S-01 | [Description, e.g. CI deployment service account bound to cluster-admin on 3 production clusters] | K8S-01 | [Critical] | [Platform engineering lead] | [Date] | [Open] |
| HC-K8S-02 | [Description, e.g. 14 application namespaces with no default-deny policy] | K8S-04 | [High] | [Application platform team] | [Date] | [Open] |
| HC-K8S-03 | [Description] | [ID] | [Critical / High / Medium / Low] | [Role] | [Date] | [Open / In progress / Closed / Risk accepted] |
Suggested due dates: critical within 7 days, high within 30 days, medium within 90 days. Each risk acceptance needs a named approver and an expiry date.
Remediation map
| Finding type | Where to fix it |
|---|---|
| Cluster-admin, wildcard and escalation bindings | Kubernetes RBAC Guide |
| Unneeded token mounts, legacy tokens, workload identity | Kubernetes Service Account Token Guide, Kubernetes NHI Security Guide |
| Privileged pods, Pod Security, image signature enforcement, admission violations | Kubernetes Admission Control Guide, Container Image Security Guide |
| Missing network policy | Kubernetes Network Policy Guide |
| Secrets in environment variables | Kubernetes Secrets Security Guide, How to migrate Kubernetes secrets to an external Secrets Manager |
| API server exposure, unsupported versions | Kubernetes Security Checklist (control plane section) |
| Missing audit logging | Kubernetes Audit Log Detection Guide |
| Signs of active compromise | Kubernetes Cluster Compromise Playbook |
Framework mapping
| Area | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | CIS Controls v8.1 | MITRE ATT&CK |
|---|---|---|---|---|
| RBAC and token mounts (K8S-01, 02) | PR.AA-05 | AC-2, AC-6 | Control 5, Control 6 | Container API (T1552.007) |
| Privileged pods and admission (K8S-03, 05, 10) | PR.PS-01 | CM-6, CM-7, SR-11 | Control 4 | Deploy Container (T1610), Escape to Host (T1611) |
| Network policy and API exposure (K8S-04, 07) | PR.AA-05, DE.CM-01 | AC-6, CM-7 | Control 12, Control 13 | Container and Resource Discovery (T1613) |
| Secrets handling (K8S-06) | PR.DS-01 | IA-5, SC-28 | Control 3 | Container API (T1552.007) |
| Audit logging and versions (K8S-08, 09) | PR.PS-04, PR.PS-02 | AU-12, SA-22, SI-2 | Control 2, Control 7, Control 8 |
Related guides
- Kubernetes Security Checklist: the hardening baseline these metrics measure.
- Kubernetes Security Guide: architecture and threat context.
- Container Security Maturity Model: place the quarter's results on a maturity level.
- Kubernetes NHI Security Guide: service accounts and workload identity in depth.
- Kubernetes Cluster Compromise Playbook: when a red flag is an incident.
References
- Kubernetes: Role Based Access Control Good Practices
- Kubernetes: Pod Security Standards
- Kubernetes: Good practices for Kubernetes Secrets
- Kubernetes: Auditing
- Kubernetes: Releases
- NSA and CISA: Kubernetes Hardening Guide
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls
- CIS: Critical Security Controls v8.1
Related NHI Mgmt Group resources: Kubernetes Security Checklist, Kubernetes Security Guide, Kubernetes RBAC Guide, Kubernetes NHI Security Guide.