Kubernetes Secrets: Why Your Credentials Are Exposed

📅 September 21, 2026  |  🏷 General  |  Cyber Security, Information Security, Threat Management

A penetration tester at a Fortune 500 financial firm discovered something alarming during a routine red team engagement in early 2026: over 340 Kubernetes Secrets stored in plain Base64 encoding, accessible to any authenticated cluster user with default RBAC permissions. Among them were database connection strings, third-party API keys, and an OAuth2 client secret tied to their core banking platform. No breach had occurred — yet. But the exposure window had been open for 14 months.

This is not an edge case. A 2025 study by Aqua Security found that 67% of Kubernetes environments audited had at least one critical secret misconfiguration, ranging from unencrypted etcd storage to overly permissive service account bindings. As container orchestration has become the backbone of enterprise infrastructure — running everything from microservices to ML pipelines — Kubernetes Secrets have emerged as one of the most consistently misunderstood and dangerously misconfigured components in modern cloud-native architecture.

Understanding why requires pulling apart a deeply embedded misconception: that Base64 encoding means encryption. It does not. And that single misunderstanding is the foundation on which thousands of exposed credential sets currently rest.

What Kubernetes Secrets Actually Are (And What They Are Not)

Kubernetes Secrets are API objects designed to store and manage sensitive information — passwords, TLS certificates, SSH keys, API tokens — separately from application code and pod specifications. The intent is sound: decoupling configuration from secrets prevents credentials from being baked directly into container images or version-controlled manifests.

The execution, however, has a critical flaw baked into its defaults. By default, Kubernetes stores Secrets in etcd as Base64-encoded strings, not encrypted values. Base64 is an encoding scheme, not a cryptographic operation. Any actor who gains read access to etcd — either through a misconfigured API server, a compromised node, or an RBAC policy error — can decode every secret in your cluster with a single command:

echo “c3VwZXJzZWNyZXQ=” | base64 –decode

That outputs “supersecret” in under a second. No key material. No algorithmic complexity. No defense.

The etcd Exposure Vector

The etcd datastore is the brain of every Kubernetes cluster. It holds the entire cluster state, including all Secret objects. In misconfigured environments — particularly self-managed clusters on bare metal or older cloud deployments — etcd is exposed without TLS, without authentication, or both. Shodan and similar reconnaissance tools regularly surface publicly accessible etcd endpoints. A 2024 analysis by Wiz Research identified over 2,100 publicly reachable etcd instances, a significant portion of which returned Secret data without requiring credentials.

Even in properly TLS-secured environments, the threat model doesn’t end at the network perimeter. A compromised control plane node, a misconfigured etcd backup pipeline writing to an unencrypted S3 bucket, or a snapshot restore procedure that bypasses access controls can all expose the entire etcd dataset — and every secret within it.

RBAC Misconfigurations and the Principle of Least Privilege

Even when etcd itself is secured, Kubernetes Secrets remain accessible through the Kubernetes API. The access control layer — Role-Based Access Control (RBAC) — is where environments most frequently fail. The default service account in many clusters has broader permissions than intended, and developers frequently grant get, list, and watch verbs on the Secrets resource at a namespace or cluster level without appreciating the cumulative risk.

Notably, the list verb on Secrets is particularly dangerous because it allows enumeration of all secret names and their metadata — an attacker’s reconnaissance goldmine before targeted extraction. Red Hat’s 2025 State of Kubernetes Security report noted that 55% of respondents had experienced a security incident stemming from misconfigured RBAC policies, with secret exposure being the most cited consequence.

Encryption at Rest: The Gap Between Documentation and Reality

Kubernetes does support encryption at rest for Secret objects. The mechanism — defined via an EncryptionConfiguration resource applied to the API server — can wrap secret data using AES-CBC, AES-GCM, or the secretbox algorithm before writing to etcd. In managed Kubernetes offerings like GKE, EKS, and AKS, envelope encryption using cloud KMS (AWS KMS, Google Cloud KMS, Azure Key Vault) provides an additional cryptographic layer.

The problem is adoption. A 2025 Cloud Native Computing Foundation (CNCF) survey found that only 38% of Kubernetes operators had enabled encryption at rest for Secrets. The remaining 62% were relying on Base64 encoding as their primary protection mechanism — a non-protection by any meaningful security definition.

Envelope Encryption and KMS Integration

Envelope encryption is the gold standard for Kubernetes Secret protection at the storage layer. The model works as follows: a data encryption key (DEK) is generated per-secret, the DEK encrypts the secret value, and the DEK itself is encrypted by a key encryption key (KEK) stored in an external KMS. The KEK never touches etcd. Even if an attacker exfiltrates the entire etcd dataset, they cannot decrypt the secrets without access to the KMS — and KMS access is governed by IAM policies, audit logs, and hardware security modules.

AWS EKS with KMS envelope encryption, for example, can be configured so that every kubectl get secret call triggers a KMS Decrypt API call that appears in CloudTrail. This creates a full audit trail of secret access — something that flat Base64 storage never provides. Configuring this on EKS requires specifying the KMS key ARN in the cluster configuration and enabling Secrets encryption during cluster creation or via an in-place update, a procedure that many teams defer indefinitely due to operational friction.

Secret Sprawl: The Pipeline Problem Nobody Talks About

Kubernetes Secrets don’t exist only inside the cluster. They travel. CI/CD pipelines that deploy to Kubernetes must somehow authenticate to the cluster and often inject secrets into manifests before applying them. This creates multiple points of exposure that extend far beyond the cluster boundary itself.

The most dangerous pattern is the committed YAML manifest: a developer generates a Secret manifest using kubectl create secret generic --dry-run=client -o yaml, pastes the Base64-encoded output into a GitOps repository, and commits it. If that repository is public — or if it becomes public through a misconfigured repository permission setting — the secret is now exposed. GitHub’s secret scanning service reported detecting over 39 million exposed secrets in public repositories during 2024, with Kubernetes kubeconfig files and service account tokens among the most frequently discovered types.

Sealed Secrets, External Secrets Operator, and Vault Integration

The GitOps-compatible solutions to secret sprawl are now mature and production-proven. Three dominant patterns have emerged:

• Bitnami Sealed Secrets: Encrypts Kubernetes Secrets using asymmetric cryptography before they touch version control. The private key lives inside the cluster; only the cluster can decrypt. Sealed Secrets are safe to commit to Git. The limitation is operational — key rotation and backup of the sealing key require careful procedures.
• External Secrets Operator (ESO): Synchronizes secrets from external providers (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, GCP Secret Manager) into Kubernetes Secret objects at runtime. The source of truth never lives in the cluster or in Git. ESO has become the de facto standard for enterprise GitOps workflows, with adoption exceeding 45 million downloads as of early 2026.
• HashiCorp Vault with the Agent Injector or Vault Secrets Operator: Injects secrets directly into pod filesystems or environment variables at runtime using Vault’s dynamic secrets capabilities. For database credentials specifically, Vault’s dynamic secrets generate short-lived, unique credentials per pod instantiation — eliminating the concept of a static credential that can be stolen and reused.

Each of these approaches shifts the security boundary from the cluster interior to a hardened external system with dedicated secret lifecycle management, audit logging, and access controls that Kubernetes native Secrets simply cannot match.

Runtime Exposure: When Secrets Leave the API and Enter Your Pods

Even perfectly encrypted secrets at rest become vulnerable the moment they are consumed. Kubernetes can deliver secrets to pods in two ways: as environment variables or as mounted volumes. Both have distinct risk profiles that security architects must understand before designing workload deployments.

Environment Variables vs. Volume Mounts

Environment variables are convenient but dangerous. Any process running in the container can read the entire environment — and so can any adjacent process if container isolation breaks down. Environment variables are also frequently logged inadvertently: application frameworks, crash reporters, and debugging tools routinely dump the process environment in error output. A misconfigured logging pipeline that ships pod logs to an insufficiently access-controlled SIEM can expose every credential injected as an environment variable.

Volume-mounted secrets are marginally better from a runtime exposure perspective. The secret material is written to an in-memory tmpfs filesystem inside the pod, not to disk. Access can be constrained by UNIX file permissions within the container. Critically, if the Secret object is updated, the mounted file reflects the new value automatically — enabling credential rotation without pod restarts in many configurations.

However, volume mounts don’t eliminate runtime risk. A container with a shell and a compromised application process can trivially read mounted secret files. The defense is not in the delivery mechanism — it’s in workload isolation, runtime security tooling (Falco, Tetragon), and minimizing the blast radius of any single container compromise through network policies and service mesh mTLS.

A 2026 Sysdig threat report documented real-world attacks in which compromised containers used mounted service account tokens — which Kubernetes auto-mounts by default — to perform lateral movement within the cluster, accessing secrets in adjacent namespaces. Disabling automatic service account token mounting (automountServiceAccountToken: false) in pod specifications where it isn’t needed is one of the highest-ROI hardening steps available.

Detection, Auditing, and Incident Response for Secret Exposure

Many organizations discover secret exposure months after the fact — if they discover it at all. The 14-month exposure window in the opening example is depressingly representative. Building detection capability around Kubernetes secret access requires intentional instrumentation across multiple layers.

Kubernetes Audit Logs as a Detection Source

The Kubernetes API server generates audit logs for every API call, including reads of Secret objects. These logs, when properly configured and shipped to a SIEM, provide the foundation for detecting anomalous secret access patterns. Effective detection rules include:

• Any list or get operation on Secrets from a service account that has no business reading them
• Secret reads from outside normal business hours or from unusual source IP ranges
• Bulk secret enumeration — a pattern consistent with credential harvesting prior to exfiltration
• Access to Secrets in production namespaces from development-tier service accounts
• Any kubectl exec or debug pod creation immediately followed by Secret reads

The challenge is log volume and noise. A busy cluster generates millions of audit events daily. Tuned detection logic and ML-assisted anomaly detection — available in platforms like Datadog Cloud Security Management, Elastic Security, and Falco with Falcosidekick — are necessary to make this signal actionable at scale.

For incident response, the immediate priorities when a Kubernetes secret exposure is confirmed are: rotate all exposed credentials regardless of whether evidence of exploitation exists, audit RBAC to close the access vector, review etcd backup pipelines for secondary exposure, and examine audit logs for the full exposure window to determine whether the credentials were accessed or exfiltrated.

Key Takeaways

• Base64 is not encryption. Default Kubernetes Secret storage provides zero cryptographic protection. Any actor with etcd read access or appropriate RBAC permissions can recover all stored credentials trivially.
• Enable encryption at rest with KMS integration immediately. Envelope encryption using your cloud provider’s KMS is the minimum viable cryptographic baseline for production Kubernetes clusters storing sensitive credentials.
• Never commit Secret manifests to version control. Use Sealed Secrets for GitOps workflows or, preferably, adopt External Secrets Operator to synchronize from a dedicated secrets management platform, keeping the source of truth entirely outside your cluster and your repositories.
• Audit and restrict RBAC permissions on the Secrets resource. Apply least-privilege rigorously. Remove list and watch verbs from any role that doesn’t require them. Disable automatic service account token mounting on pods that don’t perform Kubernetes API calls.
• Instrument your cluster for secret access anomalies. Kubernetes audit logs are your primary detection surface. Configure log shipping to your SIEM and build detection rules for bulk enumeration, off-hours access, and cross-namespace secret reads. Pair this with runtime security tooling for defense in depth.

Conclusion: The Credential Exposure Window Is Open Right Now

The financial firm’s penetration test had a clean ending — the findings were remediated before a threat actor reached them. That outcome depends entirely on finding the problem first. In environments where Kubernetes audit logging isn’t enabled, where etcd backups flow to unencrypted storage, and where RBAC policies haven’t been reviewed since cluster inception, that discovery may never come from the inside.

The architectural remediation path is clear and the tooling is mature. Enabling KMS envelope encryption, deploying External Secrets Operator or Vault integration, hardening RBAC to genuine least privilege, and instrumenting audit log-based detection can be executed incrementally — without cluster downtime and without waiting for a security incident to justify the investment.

Start this week with a targeted audit: run kubectl get secrets --all-namespaces and map every returned secret against your RBAC policies to determine who can read each one. Cross-reference against your etcd encryption configuration status. If either produces results you cannot immediately justify, your remediation backlog has its top priority. The credential exposure window is only open until someone decides to close it — or until someone else walks through it.