Kubernetes Secret Decoder

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.