Kubernetes secrets enumeration is listing and reading Secret objects to harvest credentials. Secrets are base64-encoded, not encrypted by default, so read access, gained through a stolen token or node identity, exposes database passwords, VPN keys, and cloud credentials that fuel lateral movement. Defend with least-privilege RBAC on secrets, encryption at rest, and external secret stores.
What Kubernetes secrets enumeration is
Kubernetes stores sensitive values as Secret objects. By default they are only base64-encoded, which is encoding, not encryption, so anyone who can read the object reads the value. Broad or default RBAC that grants get and list on secrets turns any compromised identity into a credential harvester.
How it works and example
With a stolen service-account token or an impersonated node identity, the attacker lists secrets across namespaces and reads them, collecting database passwords, mesh VPN auth keys, registry credentials, and cloud keys. Each harvested secret opens another system, which is how a single foothold becomes cluster-wide and then network-wide access, as seen in recent intrusions.
How to defend against it
Apply least-privilege RBAC so few identities can read secrets, and never grant cluster-wide secret read casually. Enable encryption at rest with a KMS provider, move sensitive credentials to an external secrets manager, avoid mounting every secret into pods, rotate on suspicion, and alert on unusual list-secrets activity.
References
- [1]MITRE ATT&CK Cloud Matrix(MITRE ATT&CK)
- [2]HuggingFace, Agent intrusion technical timeline(HuggingFace)
- [3]Kubernetes: encrypting secret data at rest(Kubernetes)
Base64 is not protection. Talk to a security expert about who can read secrets in your cluster and what those secrets unlock.