TL;DR: Kubernetes etcd can be pushed into a read-only failure state when Trivy Operator vulnerability reporting leaves report volume, object size, and MVCC history unchecked, according to Aqua Security. The lesson is that visibility tooling must be governed as infrastructure pressure, not just security telemetry.
At a glance
What this is: This is an Aqua Security analysis of how Trivy Operator reporting can exhaust etcd and force a Kubernetes cluster into read-only mode.
Why it matters: It matters because IAM and platform teams need to govern security visibility as a workload with capacity limits, retention rules, and storage design, not as harmless telemetry.
Context
In Kubernetes, etcd is the control plane database that stores cluster state, so excessive object volume or oversized objects can affect basic write operations. This article focuses on the governance gap created when vulnerability reporting is allowed to accumulate without limits, especially in environments using Trivy Operator.
The issue is not that vulnerability visibility is inherently dangerous. The issue is that report generation, revision churn, and retained history can turn security scanning into a control plane load problem, which makes availability a governance concern for platform, security, and workload teams alike.
Key questions
Q: What breaks when vulnerability reports are stored as Kubernetes objects at scale?
A: The failure is not just clutter. When vulnerability reports are persisted as cluster state, large objects and frequent updates increase etcd load until the control plane can no longer accept writes. At that point, operations like scaling, deleting pods, and updating workloads can fail because they all depend on the same write path.
Q: When should Kubernetes teams prioritise alternate storage over etcd for scan results?
A: They should prioritise alternate storage when scan volume, object size, or revision churn makes report persistence a control plane risk. If vulnerability data is needed for analysis but does not need to live inside etcd, storing it externally protects availability without eliminating security visibility.
Q: How do you know Trivy reporting is creating etcd pressure?
A: Watch for rising database usage, growing object counts, and repeated report updates that increase revision history faster than compaction can reclaim space. If space consumption trends upward even when the visible number of reports looks stable, the retention model is creating storage debt.
Q: What should teams do when scan data threatens Kubernetes availability?
A: Contain the pressure before it becomes a write outage by reducing report payload size, limiting retained severities, and moving vulnerability data off etcd when necessary. The goal is to preserve enough visibility for response while preventing security telemetry from blocking cluster operations.
Technical breakdown
Why vulnerability reports can overwhelm etcd
Trivy Operator stores vulnerability findings as Custom Resources, which means each report becomes cluster state rather than an external log entry. When optional fields such as links, CVSS, and descriptions are included, a single report can grow large enough to hit Kubernetes API object limits. At scale, the problem is not just count but size: more vulnerabilities per image means larger objects, more writes, and more storage pressure inside etcd.
Practical implication: Cap report payload size before treating security findings as persisted cluster state.
How MVCC turns report churn into storage exhaustion
Etcd uses Multi-Version Concurrency Control, so updates do not overwrite an object in place. Each scan update creates a new revision, which means repeated vulnerability reporting accumulates historical versions even when the current number of visible objects looks small. Compaction reduces internal bloat, but defragmentation is what releases physical disk space back to the operating system. Without both, a modest quota can disappear quickly under routine scan churn.
Practical implication: Pair report retention with compaction and defragmentation, not just object deletion.
Why alternate storage changes the failure mode
The alternate report storage option moves vulnerability reports off etcd and onto a Persistent Volume, removing the database from the report retention path. That design avoids the API object size ceiling and the etcd quota, but it also changes how operators retrieve findings because kubectl no longer queries report objects in the same way. The architectural trade-off is between direct cluster visibility and control plane stability.
Practical implication: Decide whether report visibility belongs in cluster state or in external storage before rollout.
Threat narrative
Attacker objective: The outcome is not attacker theft but operational denial of service through storage exhaustion that prevents the cluster from accepting writes.
- Entry occurs through normal vulnerability scanning and report creation, not through attacker compromise, when Trivy Operator writes findings into Kubernetes objects.
- Escalation happens as repeated updates, optional fields, and retained history increase object size and revision churn inside etcd.
- Impact is a read-only control plane where Kubernetes rejects writes, including actions needed to delete resources or scale workloads.
Breaches seen in the wild
- Secrets in Docker Hub images (RWTH Aachen study): A 2023 RWTH Aachen study found secrets in 8.5% of container images, and 275,269 internet hosts still using the leaked private keys.
- Kubeflow cryptomining attacks 2020: Exposed Kubeflow dashboards and a notebook's mounted Kubernetes service account let attackers run cryptominers on tens of ML clusters.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Security visibility becomes a control plane governance problem once reports are persisted as cluster state. The article shows that vulnerability telemetry is not neutral when it shares the same database as core Kubernetes operations. Once reporting volume, object size, and revision churn are unmanaged, visibility starts competing with availability. The practitioner lesson is to treat every persisted security finding as a workload with lifecycle and capacity impact.
Report retention without history control creates a storage debt pattern. The article’s MVCC explanation is the key point: deleting or updating a report does not erase the past, it creates more database history. That means teams can meet their “keep the data” objective while still exhausting the system. The implication is that lifecycle governance for security reports must include expiry, compaction, and physical space reclamation as one policy chain.
High-fidelity visibility is not the same as unrestricted visibility. Optional fields such as links, CVSS, and descriptions improve context, but they also increase object size and can push reports over protocol limits. The governance mistake is assuming more detail is always safer. In practice, the right question is which findings need to live in etcd at all, and which should be stored elsewhere. The practitioner implication is to distinguish security evidence from control plane state.
Offloading report storage is a structural response, not merely a tuning choice. Moving reports to a Persistent Volume changes the trust boundary and removes etcd from the retention path, which is the only durable way to prevent visibility data from becoming control plane pressure at scale. This does not solve reporting governance by itself, but it changes where the risk sits. Practitioners should align storage architecture with the expected scan volume before the database becomes the bottleneck.
From our research library:
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
What this signals
Control plane pressure is now a visibility-design issue, not just a storage issue. Security teams that persist scan outputs inside Kubernetes state need to decide whether the data belongs in etcd at all. If the answer is yes, then retention, object size, and maintenance windows become part of the security design, not afterthoughts.
Report lifecycle is the real boundary condition. The key failure mode is not a single scan result but the accumulation of revisions over time. That means teams should model vulnerability reporting as a governed identity-adjacent data lifecycle, with explicit ownership for retention, compaction, and off-cluster storage decisions.
For practitioners
- Limit report fields before persistence Disable optional report fields such as links, CVSS, and long descriptions when they are not needed for operational response, because those fields can push individual vulnerability reports toward API size limits.
- Set a strict report TTL Use the Trivy Operator report TTL setting so stale vulnerability reports are removed on a defined schedule instead of accumulating indefinitely in etcd.
- Run compaction and defragmentation together Treat compaction as only half of the maintenance task and schedule defragmentation as the step that actually releases disk space back to the host.
- Move reports off etcd when scale demands it Enable alternate report storage on a Persistent Volume when report volume or size makes etcd an unreliable home for vulnerability data.
- Alert before quota pressure becomes outage Track apiserver_storage_size_bytes or etcd_db_total_size_in_bytes and investigate when usage trends toward the upper bound rather than waiting for a NOSPACE failure.
Key takeaways
- Persisted vulnerability reports can overload etcd and force a Kubernetes cluster into read-only mode.
- The storage problem grows through report size, revision churn, and retained history, not just raw report count.
- Teams should manage scan data with TTL, maintenance, and alternate storage choices before visibility becomes an availability incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The article is about operational impact from persistent report churn and control plane exhaustion. |
| Recommendation — Map database exhaustion to TA0040 and monitor storage pressure as an availability threat. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The topic is about governing what data is persisted into cluster state and how it affects operational access. |
| Recommendation — Apply PR.AA-05 to limit which security reports are retained as Kubernetes state. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article centres on lifecycle control of persistent security objects and their accumulation. |
| Recommendation — Use CIS-5 to govern report lifecycle rules and remove stale persisted security objects. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential-style lifecycle discipline is relevant where persisted security artefacts and their rotation-like cleanup affect availability. |
| Recommendation — Apply IA-5 discipline to expire and retire stale reporting artefacts before they accumulate. | ||
| OWASP Non-Human Identity Top 10 | NHI-07 — Long-Lived Secrets | The article’s core pattern is long-lived retained state that continues to consume resources over time. |
| Recommendation — Limit long-lived retained security artefacts and move them off etcd when they outlive their useful window. | ||
Key terms
- Etcd: Etcd is the distributed key-value store used by Kubernetes as part of its control plane. When Secrets are persisted there without encryption at rest, anyone with sufficiently broad control-plane or backend access may recover the underlying values, which makes etcd a critical governance boundary.
- Multi-Version Concurrency Control: Multi-Version Concurrency Control is a database model that preserves each update as a new revision instead of overwriting old state in place. For Kubernetes operators, that means repeated report updates create historical copies that must be compacted and defragmented if you want to reclaim real disk space.
- VulnerabilityReport Custom Resource: A VulnerabilityReport Custom Resource is a Kubernetes object used to store vulnerability findings in cluster state. When these reports are large or updated frequently, they stop being simple telemetry and start behaving like persistent control plane data with availability consequences.
- Control-plane pressure: Control-plane pressure is the operational strain created when too many writes, large objects, or frequent updates burden Kubernetes control components. For identity and security teams, it is the point where visibility tooling stops being passive and starts competing with workload operations.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on July 1, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org