Are Kubernetes Secrets encrypted?

By default, no. Secret data is base64-encoded — which is encoding, not encryption — and stored in etcd in plaintext unless you enable encryption at rest. Anyone with API or etcd access can read the values, so treat Secrets as merely obfuscated, not secure.

What is the difference between data and stringData?

The data field requires base64-encoded values, while stringData accepts plaintext and the API server base64-encodes it for you on apply. stringData is more convenient to author; values appear in data after creation.

Should I commit Secret YAML to git?

Never commit plaintext or base64 Secrets to a repository — base64 is trivially reversible. Use Sealed Secrets, SOPS-encrypted files, or the External Secrets Operator pulling from Vault or a cloud secret manager.

What Secret types exist?

Common types include Opaque (arbitrary data), kubernetes.io/tls (cert and key), kubernetes.io/dockerconfigjson (registry pull credentials), kubernetes.io/basic-auth, and kubernetes.io/ssh-auth. Typed Secrets enforce expected keys.

How do pods consume a Secret?

Mount it as a volume so each key becomes a file, or expose keys as environment variables via env valueFrom secretKeyRef or envFrom secretRef. Image pull secrets are referenced under imagePullSecrets.

What is the Kubernetes Secret YAML Builder?

Create a Kubernetes Secret YAML with type, metadata, and base64-encoded data — or plaintext stringData. Includes guidance on Sealed Secrets and external secret stores for production safety. It runs free in your browser on Gera Tools, with nothing uploaded.

Kubernetes Secret YAML Builder

Name: Kubernetes Secret YAML Builder
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Get one useful tool a week

Like this tool? Enter your email and we'll send you one genuinely useful Gera tool a week — plus a link to come back to this one. No spam, one-click unsubscribe any time.

Generate Kubernetes Secret manifests safely

A Secret holds small amounts of sensitive data — passwords, tokens, TLS certificates, registry credentials — and makes it available to pods without baking it into images. This builder assembles a valid v1 Secret manifest, base64-encoding your values for the data field or leaving them plaintext under stringData.

How it works

The Kubernetes data field stores every value base64-encoded. The builder encodes your input using a UTF-8-safe routine so multi-byte characters survive correctly, which a naive btoa call would corrupt. If you prefer to author in plaintext, switch to stringData and the API server performs the base64 encoding when you kubectl apply.

The Secret type field tells Kubernetes what shape to expect. Opaque is the generic catch-all; typed Secrets such as kubernetes.io/tls validate that the required keys (tls.crt, tls.key) are present.

Common Secret types

Type	Required keys	Typical use
`Opaque`	Any	Generic API tokens, passwords, config
`kubernetes.io/tls`	`tls.crt`, `tls.key`	TLS certificates for Ingress
`kubernetes.io/dockerconfigjson`	`.dockerconfigjson`	Private registry pull credentials
`kubernetes.io/basic-auth`	`username`, `password`	Basic auth credentials
`kubernetes.io/ssh-auth`	`ssh-privatekey`	SSH private keys

How pods consume Secrets

As environment variables:

env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password

As mounted files (preferred for TLS and large values):

volumes:
  - name: tls
    secret:
      secretName: app-tls
containers:
  - volumeMounts:
      - name: tls
        mountPath: /etc/tls
        readOnly: true

Mounted Secrets are automatically updated when the Secret changes (with a short kubelet sync delay). Env var Secrets are baked in at pod startup and require a pod restart to pick up new values — this is a common operational gotcha.

Production security checklist

Enable etcd encryption at rest — without it, every Secret in the cluster is readable by anyone with etcd access.
Seal for GitOps — use Sealed Secrets or SOPS to encrypt manifests before committing; plain base64 in git is equivalent to plaintext.
Prefer External Secrets Operator for cloud deployments — syncs from AWS Secrets Manager, GCP Secret Manager, or HashiCorp Vault, so the source of truth lives outside the cluster.
RBAC least-privilege — grant get/list on specific Secrets only to the ServiceAccount that needs them, never broad * on the secrets resource.
Rotation — updating a Secret does not restart pods consuming it as env vars; you must roll the pods or use a sidecar agent (like Vault Agent) to reload credentials in place.