# 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.

Source: https://zop.dev/integrations/kubernetes/secret
Updated: 2026-08-19

---

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.

```bash
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 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.