Secret (Kubernetes)
Does ZopNight manage Secret (Kubernetes)?
Kubernetes Secrets are base64-encoded, not encrypted, so anyone with API read access decodes them instantly unless encryption at rest is configured for etcd. ZopNight lists Secrets keys-only, recording type, dataCount, and sorted key names, never payloads, and skips auto-managed service-account tokens. Helm stores full release manifests as Secrets of type helm.sh/release.v1.
Rules that fire on Secret (Kubernetes)
No active rule family targets Secret (Kubernetes) today. Rules that used to are retired, and retired rules publish no pages and fire no findings. Scheduling and permissions coverage are unaffected.
A Kubernetes Secret holds credentials, tokens, and keys for workloads. The name promises more than the default delivers: Secret values are base64-encoded, and base64 is an encoding, not encryption. Anyone with read access to the object decodes it in one command.
Encoding is not encryption
Out of the box, Secrets differ from ConfigMaps mainly in intent and in how tools handle them. Actual confidentiality requires configuration someone has to do: encryption at rest for etcd (managed offerings increasingly wire this to a cloud KMS), plus RBAC that treats Secret read access as the sensitive permission it is. A cluster without encryption at rest is storing its credentials in a database that backs up in plaintext, which is worth verifying rather than assuming.
Keys only: what discovery refuses to read
The inventory records each Secret’s type, its dataCount, and the sorted key names, never a value. The Secret’s type string is kept as the resource’s instance type, which makes the population legible at a glance: Opaque for generic credentials, kubernetes.io/tls for certificate pairs, kubernetes.io/dockerconfigjson for registry pulls. Auto-managed service-account token Secrets are skipped entirely during listing; they are Kubernetes plumbing, and inventorying them would add noise while touching the most sensitive class of object.
Helm hides releases in here too
One Secret population surprises people in audits: Helm stores complete release manifests as Secrets of type helm.sh/release.v1, 1 per revision, identified by release-name annotations. They are why a namespace can show dozens of Secrets with only a handful of applications, and they are also how discovery reads Helm release topology without running Helm itself.
kubectl get secrets -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,TYPE:.type,KEYS:.data --no-headers | head -40Rotation is the review that matters
Because values are never collected, staleness has to be judged from metadata: creation timestamps on credential Secrets are effectively their age since rotation in most shops. Key-name inventory plus age answers the practical audit question (which credentials in this cluster are years old and still mounted) without anyone’s platform ever holding the credential itself.