kube-state-metrics is a Kubernetes add-on that exports cluster object state as Prometheus metrics. It watches the Kubernetes API for resources such as pods, deployments, nodes and persistent volumes, then exposes their current status for monitoring and alerting.
What kube-state-metrics does in a Kubernetes environment
kube-state-metrics turns Kubernetes API object state into metrics that monitoring systems can read. That makes cluster state visible in a Prometheus-friendly form, so teams can alert on desired versus actual state, track workload health, and spot resource drift without polling each object manually.
Its value is not in collecting application performance data, but in exposing orchestration state that already exists inside the control plane. In practice, it helps translate Kubernetes objects into operational signals about deployment status, node readiness, replica counts, and volume conditions.
Why cluster state metrics matter for monitoring and alerting
Many Kubernetes failures do not start as obvious outages. A deployment can remain technically present while replicas fail to come up, a node can become unhealthy, or a persistent volume can move into a degraded state. kube-state-metrics makes those conditions observable in a form that alerting rules can use.
Because the exporter reflects the current API state, it is useful for detecting divergence between what operators intended and what the cluster is actually running. That distinction is important in incident response, where the question is often not just “is the service up?” but “has the platform stopped converging on the declared state?”
How kube-state-metrics fits into the Kubernetes observability stack
kube-state-metrics is usually paired with Prometheus and a dashboarding or alerting layer. Prometheus scrapes the exporter, stores time series, and evaluates rules, while kube-state-metrics supplies the underlying object status that those rules depend on. The exporter therefore sits between the Kubernetes API and the monitoring system, not on the application request path.
That placement matters because it makes the component broadly useful across clusters, namespaces, and workloads. A single stream of state metrics can support capacity analysis, deployment health checks, scheduling visibility, and inventory-style reporting without embedding custom instrumentation into every service.
Common limitations and security implications
kube-state-metrics reports what Kubernetes knows, not whether the underlying workload is healthy in a deeper sense. A pod can appear scheduled while the application inside it is misbehaving, and a clean-looking object graph can still hide problems in images, configs, or dependencies. Operators should treat its output as control-plane truth, not complete service truth.
The exporter also inherits the trust boundaries of the Kubernetes API. If API access is overbroad or poorly governed, the metrics stream can expose operational detail about the cluster and its objects. That makes the component more valuable when paired with tight access control, minimal permissions, and monitoring rules that distinguish normal churn from real drift.
Risk and Threat Considerations
Because kube-state-metrics exposes object state from the Kubernetes control plane, it can increase the visibility of cluster internals to anyone who can reach the metrics endpoint. The main risk is not that the exporter changes cluster behaviour, but that weak exposure controls or overly permissive scraping make sensitive operational detail easier to enumerate.
Failure mechanism: If the exporter is reachable beyond the intended monitoring plane, an attacker or unauthorised insider can infer deployments, node status, volume usage, and other state signals that help map the environment and time later actions.
Impact: That visibility can support reconnaissance, reduce defender uncertainty, and make it easier to target weakly protected workloads, noisy maintenance windows, or degraded components during an incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | State metrics support review and analysis of cluster events and conditions. |
| AC-6 — Least Privilege | The exporter depends on narrowly scoped access to Kubernetes object state and telemetry paths. | |
| SI-4 — System Monitoring | The term is directly about monitoring cluster object state for detection and alerting. | |
| Recommendation — Correlate kube-state-metrics signals with audit and monitoring data to surface abnormal control-plane state changes. Restrict scrape and API permissions to the minimum needed for monitoring. Use kube-state-metrics as part of continuous system monitoring for drift and unhealthy Kubernetes resources. | ||
| NIST CSF 2.0 | DE.CM-01 — Networks and systems are monitored to detect potential cybersecurity events | The exporter feeds monitoring of Kubernetes object-state conditions. |
| Recommendation — Feed kube-state-metrics into monitoring pipelines that detect unexpected cluster-state changes. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | kube-state-metrics complements monitoring by turning platform state into observable signals. |
| Recommendation — Centralise and review cluster-state signals alongside logs to improve detection and investigation. | ||
Practitioner Guidance
What to watch for: Treat kube-state-metrics as a state-visibility component, not a source of absolute health. Alerting should focus on material drift, failed reconciliation, and persistent unhealthy objects rather than every transient Kubernetes event.
Governance implication: Keep the exporter’s audience narrow, review who can scrape it, and align its metric exposure with the same access assumptions you apply to other control-plane telemetry. If the metric stream is broadly available, it should be because the organisation has explicitly accepted that observability trade-off.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org