Kubernetes Secret Decoder

Paste a Secret manifest and see every value in plain text, without the kubectl and base64 pipeline. It runs entirely in this browser tab, which is the only sane place to decode a credential.

Paste below, or drop a file anywhere on this panel

Or drop a file anywhere on this panel. Nothing is uploaded: the analysis runs in this tab.

The answer appears here

Paste on the left and press Decode. Nothing leaves this tab.

Examples

Real input you can load into the tool above. Each one shows a different thing going wrong, because that is what the tool is for.

An Opaque Secret

base64 is encoding, not encryption, and anyone with get on the namespace can read it

apiVersion: v1
kind: Secret
metadata:
  name: db
type: Opaque
data:
  password: aHVudGVyMg==

A TLS Secret

The two keys a kubernetes.io/tls Secret must have, and what happens if either is missing

apiVersion: v1
kind: Secret
metadata:
  name: web-tls
type: kubernetes.io/tls
data:
  tls.crt: LS0tLS1CRUdJTg==
  tls.key: LS0tLS1CRUdJTg==

Common mistakes

These are the ones that fail silently. The config is accepted, nothing raises an error, and the consequence arrives later.

  1. Treating a Secret as encrypted

    It is base64, which is encoding. Anyone with get on Secrets in the namespace reads the value, and by default it is stored unencrypted in etcd.

    Instead:Enable encryption at rest, restrict RBAC on Secrets specifically, and use an external secret store for anything high value.

  2. Committing a Secret manifest to Git

    base64 is not obfuscation. A repository scanner and a casual reader both recover the value.

    Instead:Use Sealed Secrets, SOPS or an external operator so what is committed is genuinely encrypted.

  3. Using stringData and data interchangeably

    stringData takes plain text and is write-only; data takes base64. Putting base64 in stringData double-encodes it, and the application receives the base64 string.

    Instead:Pick one. stringData is easier to get right by hand.

What it does

The decoding is the easy part. The useful part is what it notices while it is in there.

Every value, decoded

Paste a whole Secret manifest and get each key with its plain-text value, multi-line values included, so certificates and config files come out readable rather than as one long line. A bare base64 string on its own works too, which is what kubectl gives you with a jsonpath query.

Credentials it recognises

AWS access key ids, private keys, GitHub and Slack tokens, JWTs, and connection strings with the password embedded in the URL. Each says why that particular kind of leak matters, because a key in git history is a different problem from a password in a log line.

base64 that is not base64

A value pasted into data as plain text is invalid, and the API server rejects the whole manifest. It is an easy mistake because the field looks like it takes a string, and stringData (which does) is right next to it.

Type and key mismatches

A kubernetes.io/tls secret needs exactly tls.crt and tls.key; a docker-registry one needs .dockerconfigjson with the leading dot. Get the name wrong and nothing errors: the ingress controller quietly serves its default certificate, or the image pull falls back to anonymous.

You just decoded that with no credentials

No key, no password, no permission of any kind. A browser tab, offline if you like, turned the contents of a Kubernetes Secret into plain text in a few milliseconds.

That is worth sitting with for a moment, because it is exactly what anyone with your manifest can do: a contractor with repository access, anyone who has ever cloned it, a CI job that cached the checkout, and anyone who can read Secrets in the namespace. The encoding stops a value being printed by accident. It stops nothing else.

Our scanner checks the other side of this on a running cluster: whether etcd encryption is on, which roles can list Secrets, and which workloads mount a token they never use.

Why a Kubernetes Secret is not secret

A Secret and a ConfigMap are almost the same object. The difference is that a Secret's values are base64-encoded and Kubernetes treats the resource with slightly more care. Encoding is not protection, so the security has to come from somewhere else, and knowing where is the difference between a Secret that protects something and one that only looks like it does.

The base64 is for encoding, not for hiding

Secret values are base64 because a secret can contain arbitrary bytes: a TLS private key, a binary token, and YAML cannot carry those safely. That is the entire reason. Anyone who can read the Secret object can read the values, which is what this tool does and what kubectl does in one command.

kubectl get secret db -o jsonpath='{.data.password}' | base64 -d

that is the whole attack, and it needs no tooling

Where the actual protection comes from

Three things, none of which are the encoding. RBAC decides who can read Secrets in a namespace, and get on secrets is the permission that matters. Encryption at rest has to be turned on explicitly with an EncryptionConfiguration, because without it Secrets sit in etcd as plain base64. And a cloud secret manager pulled in through the Secrets Store CSI driver or External Secrets keeps the value out of the cluster's own storage entirely.

# without this in the API server config, etcd holds plain base64
resources:
  - resources: ["secrets"]
    providers:
      - aescbc: { keys: [...] }
      - identity: {}

Anyone who can create a Pod can read your Secrets

This is the part that surprises people. RBAC can deny a user get on secrets and it does not help if they can create a Pod in the same namespace: they simply mount the Secret as a volume and read it from inside the container. Namespace boundaries are the real security boundary for Secrets, not the RBAC verbs on the Secret itself.

Which is why this tool does not encode

Decoding a Secret you already have is a debugging step. Encoding a value so it can be pasted into a manifest is the workflow that puts credentials into Git, and it is worth breaking rather than smoothing. If a value has to live in a repository, it needs Sealed Secrets, SOPS or an external secret store: something that makes the committed form genuinely unreadable rather than merely inconvenient.

Related kubernetes tools

Kubernetes Secret Encoder base64 is not encryption Kubernetes TLS Certificate Decoder When it expires, and what it covers Kubernetes ServiceAccount Token Decoder Bound or legacy, and when it dies Kubernetes imagePullSecret Generator The registry URL nobody gets right Kubernetes Kubeconfig Viewer Read it without handing it to anyone Kubernetes YAML Generator Answer a few questions, get a manifest
All 55 kubernetes tools

Elsewhere on the site

Terraform Validator & Formatter AWS IAM Policy Validator & Analyzer Docker Container Image Reference Parser VPC Subnet & CIDR Calculator