Skip to main content
_d
devops/ness

Kubernetes Secret Generator & Base64 Encoder

Fill in keys and values and get a ready-to-apply kind: Secret manifest with the values base64-encoded, plus the equivalent kubectl create secret command. Below it is a plain base64 encoder and decoder for checking what a secret actually contains. Nothing you type leaves this page.

Free, no signup. Runs entirely in your browser; nothing you enter is sent anywhere.

Secret manifest

Keys and values
secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
  namespace: default
type: Opaque
data:
  username: YXBw
  password: Y2hhbmdlLW1l
kubectl (imperative equivalent)
kubectl create secret generic db-credentials -n default \
  --from-literal=username='app' \
  --from-literal=password='change-me'

Base64 is encoding, not encryption: anyone who can read this manifest can read the values. Don't commit it to Git; use Sealed Secrets, SOPS or External Secrets for anything that lives in a repo.

Base64 encode / decode

base64
bXktZGF0YWJhc2UtcGFzc3dvcmQ=

Same result as printf %s '…' | base64. Plain echo adds a trailing newline that ends up inside the secret.

data vs stringData

Under data: every value must be base64. Under stringData: you write plain text and the API server encodes it on write. They produce the same stored object; stringData is easier to read and review, while data is what kubectl get secret -o yaml shows back and is required for binary values.

The trailing-newline bug

echo 's3cret' | base64 encodes s3cret\n, and the app then fails to authenticate with a password that looks right. Use printf %s or echo -n, or let this tool encode it. Decoding an existing value here is a quick way to spot a stray newline.

Typed secrets

kubernetes.io/tls needs tls.crt and tls.key, kubernetes.io/basic-auth needs username and password, and kubernetes.io/dockerconfigjson needs a .dockerconfigjson key. Picking a type fills in the required keys. For anything that should live in Git, keep the values out of the manifest entirely with External Secrets Operator or Vault.

Questions people ask

Are Kubernetes Secrets encrypted?

Not by default. Values are base64-encoded, which anyone can reverse, and stored in etcd as-is unless the cluster enables encryption at rest. Restrict who can get or list Secrets with RBAC, and turn on etcd encryption or use your cloud's KMS integration.

How do I decode a Kubernetes Secret from the command line?

kubectl get secret NAME -o jsonpath='{.data.password}' | base64 -d. To see every key at once: kubectl get secret NAME -o go-template='{{range $k,$v := .data}}{{$k}}={{$v|base64decode}}{{"\n"}}{{end}}'.

Is this generator safe to use with real credentials?

The encoding runs in your browser and nothing is sent or stored. The bigger risk is what happens next: don't commit the generated manifest to Git or paste it into chat. Apply it directly, or store the values in a secrets manager.