In May 2023, security researchers scanning public container registries found thousands of images with Kubernetes Secret manifests baked directly into them — API keys, database passwords, and TLS private keys sitting in plaintext YAML, protected by nothing more than base64 encoding. That's not an edge case. Kubernetes secrets management remains one of the most commonly misconfigured areas of cloud-native infrastructure, because the platform's default behavior looks secure and isn't. Secrets stored in etcd are base64-encoded, not encrypted, unless a cluster operator explicitly turns on encryption at rest. RBAC policies that "seem" restrictive routinely leave get, list, and watch permissions on secrets wide open across namespaces. And CI/CD pipelines that build and push images continue to leak credentials into layers that live in registries indefinitely. Platforms like Prisma Cloud offer secrets-scanning as one module in a much larger CNAPP suite. This post breaks down where Kubernetes secrets actually fail, and what a supply-chain-first approach to fixing it looks like.
Why isn't base64 encoding enough to protect Kubernetes secrets?
Base64 is an encoding scheme, not encryption, and anyone with kubectl read access to a Secret object can reverse it in one command: echo <value> | base64 -d. By default, Kubernetes stores all Secret objects in etcd in this base64 form. Unless a cluster admin has configured an EncryptionConfiguration resource with a provider like aescbc, secretbox, or a KMS plugin, anyone who gains read access to etcd — including through an etcd backup sitting in an S3 bucket, a common finding in cloud misconfiguration audits — gets every secret in the cluster with zero additional effort. This was the underlying weakness exploited in numerous "etcd exposed to the internet" incidents documented by researchers between 2018 and 2022, where unauthenticated etcd clients running on default port 2379 leaked full secret stores to anyone who found the IP. Encryption at rest, combined with a proper KMS integration (AWS KMS, GCP Cloud KMS, HashiCorp Vault's transit engine), is table stakes, not an advanced control.
How do Kubernetes secrets actually get leaked in production?
Most leaks happen upstream of the cluster, in source code, CI logs, and container images, not through some sophisticated etcd attack. GitGuardian's annual State of Secrets Sprawl report has consistently found well over 10 million secrets exposed on public GitHub each year, and a meaningful share are Kubernetes-related: kubeconfig files, service account tokens, and hardcoded database credentials meant for use in a Secret object but committed instead. Inside the cluster, the second-most-common path is CI/CD: a Jenkins or GitHub Actions runner with a mounted service account token that gets printed to build logs during a failed kubectl apply, or an environment variable dump in a debug step. The 2021 Codecov breach is the canonical example of what happens next — attackers used a modified bash uploader script to exfiltrate CI environment variables, including credentials that gave them lateral access across hundreds of downstream customer environments. None of that required breaking Kubernetes' cryptography; it required finding secrets sitting in plaintext somewhere in the delivery pipeline.
Why do overly broad RBAC permissions make secrets management worse?
Because Kubernetes RBAC is additive and namespace-scoped by default, a single overly broad ClusterRole binding can expose every secret in every namespace to a workload that only needed one. It's extremely common to find a ClusterRoleBinding granting get/list/watch on secrets cluster-wide to a monitoring agent, a CI operator, or a "temporary" debugging role that never got revoked. In multi-tenant clusters, this is how a compromised low-privilege pod in one team's namespace pivots to reading a payments team's database credentials three namespaces over. Audits regularly find that the number of service accounts with standing access to secrets is 5-10x the number that actually consume them at runtime, because default RBAC templates in Helm charts and operators tend to request broad permissions to avoid maintenance overhead. Tightening this requires a subject-access-review process, not just a one-time RBAC lint at deploy time.
What does Prisma Cloud's approach to Kubernetes secrets miss?
Prisma Cloud (Palo Alto Networks' CNAPP) treats secrets detection as one scanning capability nested inside a much broader agentless posture-management platform, which means it's strong on breadth — cataloging exposed secrets across code repos, images, and IaC — but weaker on the software-supply-chain context that determines whether a given secret finding is actually exploitable. A CNAPP scan will tell you a Secret object exists and may be improperly encrypted; it's less equipped to tell you which upstream commit introduced the credential, whether that image was signed, whether the build pipeline that produced it is itself trustworthy, or whether the secret has already been exfiltrated through a dependency compromise. Teams running Prisma Cloud alongside separate SCA, SBOM, and pipeline-integrity tooling often end up stitching together secrets findings, provenance data, and build attestations manually across three or four consoles — exactly the kind of fragmented workflow that lets a leaked secret sit unrotated for weeks after it's technically "detected."
How should teams rotate and detect leaked Kubernetes secrets before attackers do?
Rotation needs to be automatic and time-boxed, not manual and reactive, because the median time between a secret leaking and an attacker using it is measured in minutes for scanned public repositories. Tools that continuously scan GitHub have shown that leaked cloud credentials are frequently used by opportunistic scanners within under an hour of exposure. Effective Kubernetes secrets management pairs three things: short-lived credentials wherever possible (OIDC federation for cloud provider access instead of long-lived service account keys, Vault dynamic secrets instead of static database passwords), automated rotation policies enforced through External Secrets Operator or a KMS-backed provider so no human has to remember to rotate on a schedule, and continuous scanning of both source repositories and running clusters so a leaked secret is flagged in minutes, not discovered during a quarterly audit. A secret with a 90-day static lifetime and no scanning in front of it is a standing liability regardless of how well it's encrypted at rest.
What should a Kubernetes secrets management checklist actually include?
At minimum, it should cover encryption at rest with an external KMS, least-privilege RBAC scoped per namespace and per service account, mandatory scanning at every stage of the pipeline (pre-commit, CI, image build, and running cluster), and provenance tracking so every credential change is traceable to a signed commit and build. Concretely: enable EncryptionConfiguration with a KMS provider on every cluster (not just production), replace any ClusterRoleBinding granting cluster-wide secret access with namespaced RoleBindings, adopt External Secrets Operator or Vault Agent Injector so secrets never live as static Kubernetes objects in the first place, and require signed commits plus SBOM generation on every image build so a rotated secret can be traced back to exactly which artifact carried the old one. Skipping any one of these turns the other three into partial mitigations.
How Safeguard Helps
Safeguard was built around the idea that a secret finding is only useful if it comes with full context about where the secret originated, what depends on it, and how urgently it needs to be rotated — which is where standalone CNAPP secrets modules fall short. Safeguard continuously scans source repositories, CI/CD pipelines, container images, and IaC manifests for exposed secrets and misconfigured Kubernetes Secret objects, and correlates every finding with the commit, build, and artifact that introduced it, so remediation teams aren't stitching together separate tools to answer "where did this come from and what does it touch." Safeguard flags clusters running without encryption at rest, surfaces overly broad RBAC bindings on secret resources before they're exploited, and integrates with signed-commit and SBOM workflows so credential rotation is tied to verifiable build provenance rather than a manual checklist. For teams evaluating a move away from a general-purpose CNAPP for the parts of their stack where supply-chain context matters most, Safeguard's Kubernetes secrets coverage is built to close the gap between detecting a leaked secret and actually knowing how fast, and how far, it needs to be rotated.