Secret
An API object for storing sensitive data such as passwords, tokens, and TLS certificates, base64-encoded in etcd.
What is Secret?
Kubernetes Secrets store sensitive configuration data — database passwords, API keys, TLS certificates, SSH keys, OAuth tokens — separately from Pod specs and container images. Secrets are base64-encoded (not encrypted) in etcd by default, though etcd encryption at rest can and should be enabled in production via the EncryptionConfiguration API. Secrets are namespace-scoped and are only sent to nodes that schedule Pods referencing them, reducing exposure.
Secrets can be consumed by Pods in three ways: as environment variables (envFrom or individual env entries), as mounted volumes (each key becomes a file in a directory), or as image pull secrets for private registry authentication (imagePullSecrets). The recommended consumption method is volume mounts — environment variables are visible in /proc/[pid]/environ and in process listings, making them easier to accidentally expose.
Excessive or orphaned Secrets represent a significant security risk beyond their storage cost. A Secret not referenced by any running Pod may hold valid credentials for production systems, databases, or cloud provider APIs. These credentials remain valid and usable by anyone with Kubernetes API access until the Secret is deleted and the credentials are rotated.
Example
# Create a generic secret from literal values
kubectl create secret generic db-credentials \
--from-literal=username=admin \
--from-literal=password='S3cr3t!' \
-n production
# List secrets without showing values
kubectl get secrets -n production
# Find secrets not referenced by any pod
kubectl get secrets -n production -o json | jq '.items[].metadata.name'Cost & Waste Implications
Orphaned Secrets are low direct cost (a few bytes in etcd) but extremely high security risk. Valid credentials stored in unreferenced Secrets remain exploitable indefinitely. A compromised etcd backup — a real attack vector — exposes all Secrets cluster-wide. Eliminating orphaned Secrets and rotating their credentials is both a security and compliance obligation.
How KorPro Helps
KorPro identifies Secrets with no Pod references, no imagePullSecrets binding, and no Ingress TLS reference, classifying them by type (Opaque, kubernetes.io/tls, etc.) to help security teams prioritize credential rotation.
Scan Your Cluster FreeRelated Terms
ConfigMap
ConfigurationAn API object that stores non-sensitive configuration data as key-value pairs, injected into Pods as env vars or mounted files.
Read definitionRBAC(RBAC)
SecurityRole-Based Access Control — Kubernetes's authorization mechanism that grants permissions through role bindings.
Read definitionPod Security
SecurityKubernetes controls that restrict what Pods can do at the OS level — capabilities, root access, host namespaces, and file system permissions.
Read definitionNamespace
Core ConceptsA virtual partition within a cluster that isolates resources, access control, and networking between teams or environments.
Read definitionStop Wasting Money on Orphaned Kubernetes Resources
KorPro connects to your clusters across GCP, AWS, and Azure — no agents, no installation — and surfaces every orphaned resource with its monthly cost estimate.