Secret (Kubernetes)

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. Every Secret of type kubernetes.io/service-account-token is skipped entirely during listing, hand-made ones included; most are Kubernetes plumbing, and inventorying them would add noise while touching the most sensitive class of object. As a result, the Legacy Service-Account-Token Secret rule has nothing to match and raises no findings today.

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 -40

Rotation is the review that matters

Because values are never stored in the inventory, 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 the inventory ever holding the credential itself. Values are still reachable live, though: org admins can view Secret values in the manifest viewer (other roles see them redacted), and the Helm values view decodes a release’s user-supplied values, which often include passwords.