How do I create a Kubernetes Secret from a .env file using kubectl?

Run kubectl create secret generic my-secret --from-env-file=.env. This reads every KEY=VALUE line in the .env file (skipping blank lines and comments) and creates a Secret named my-secret with each key base64 encoded automatically — you never have to encode values by hand. Add --namespace=your-namespace to target a specific namespace. Use the Encode tab on this page to preview the exact YAML that command would generate before you apply it.

OpsBash.com ⚡ Free Tools

Buy me a Koffee

Free Kubernetes Secret Decoder

Kubernetes Secret Decoder

Q: Is base64 encoding the same as encryption?

No. Base64 is a reversible encoding scheme, not encryption. Anyone with the encoded string can decode it back to plaintext instantly with no key or password required, using a single command like `echo '...' | base64 -d` or this tool. Kubernetes Secrets store values as base64 purely so the YAML/JSON manifest can safely hold binary or multi-line data as plain text — it is not intended as a security boundary. Real protection comes from encryption at rest (etcd encryption), RBAC restricting who can read Secret objects, and tools like Sealed Secrets or the External Secrets Operator.

Q: How do I decode all values in a Kubernetes Secret at once?

Run kubectl get secret my-secret -o json | jq -r '.data | map_values(@base64d)' to decode every key in one shot with jq. Without jq, kubectl get secret my-secret -o jsonpath='{.data}' prints the raw base64 map, which you then pipe per-key through base64 --decode. Paste the same YAML into the Decode tab on this page to see every key and value listed side by side without running any command.

Q: What is the difference between Opaque and kubernetes.io/dockerconfigjson secret types?

Opaque is the generic, freeform Secret type used for arbitrary key-value data such as database credentials, API keys, and tokens — Kubernetes places no structure requirements on the data. kubernetes.io/dockerconfigjson is a specialized type built for container registry authentication: it must contain a single key named .dockerconfigjson holding a base64 encoded Docker config JSON blob, and Kubernetes uses it specifically for imagePullSecrets when pulling private container images. Other built-in types include kubernetes.io/tls for certificate/key pairs and kubernetes.io/basic-auth for username/password pairs.

Q: How do I rotate a Kubernetes Secret without downtime?

Update the Secret's data in place with kubectl apply or kubectl create secret ... --dry-run=client -o yaml | kubectl apply -f -, then trigger a rolling restart of the workloads that mount it with kubectl rollout restart deployment/your-app. Because a rolling restart replaces pods gradually while old pods keep serving traffic, there is no downtime as long as your readiness probes are configured correctly. If a Secret is mounted as a volume rather than an environment variable, the kubelet updates the mounted file automatically within about a minute, though your application still needs to reload the file or restart to pick up the new value — environment variables never update without a pod restart.

Paste a Kubernetes Secret manifest and instantly decode every base64 value to plaintext. It runs entirely in your browser, and nothing is uploaded anywhere.

Paste Kubernetes Secret YAML

Everything runs in your browser. Your secrets never leave your device.

What Are Kubernetes Secrets, and What Does Base64 Actually Do?

A Kubernetes Secret is an API object used to store small amounts of sensitive data, such as database passwords, API tokens, TLS keys, and OAuth credentials, separately from the application code and Pod specs that consume them. Structurally a Secret looks almost identical to a ConfigMap: it has a data field mapping keys to values. The one difference is that every value in that data field is base64 encoded rather than stored as raw text.

Base64 is an encoding scheme, not a cipher. It takes arbitrary binary or text data and re-represents it using 64 printable ASCII characters (A–Z, a–z, 0–9, +, /) so it can safely live inside a YAML or JSON document without breaking on newlines, special characters, or non-printable bytes. The transformation is entirely mechanical and requires no key: echo -n 'password' | base64 produces cGFzc3dvcmQ=, and echo 'cGFzc3dvcmQ=' | base64 -d reverses it instantly. This is precisely why base64 is not encryption, since encryption requires a secret key to reverse, while base64 requires nothing but the string itself. Kubernetes uses it purely so the API server and etcd can store and transmit values as plain text-safe strings, not to hide the data from anyone.

Why Developers Decode Secrets Constantly During Debugging

In practice, engineers decode Secret values dozens of times a week. A Pod is CrashLoopBackOff-ing because a database connection string is wrong; a teammate asks "what value is actually in the API_KEY key on staging"; a migration script needs the real password to run locally against a mirrored database. Each of these means running kubectl get secret ... -o yaml, copying a base64 blob, and piping it through base64 -d in a terminal, one key at a time, by hand, over and over. Multiply that by every Secret with five or ten keys and it becomes real, repetitive toil that this tool exists to remove: paste the whole manifest once and see every key decoded side by side.

The Security Risk of Treating Base64 as Protection

Because base64 offers zero confidentiality, the real risks with Kubernetes Secrets are: committing raw manifests (with base64 values) into a public or shared Git repository, where anyone can decode them in seconds; storing Secrets unencrypted in etcd without encryption-at-rest enabled, meaning anyone with etcd access, or a snapshot backup, can read every value in plaintext; over-permissive RBAC that lets any Pod's ServiceAccount or any developer with get/list on secrets read data far beyond what they need; and logging or CI output that accidentally prints decoded Secret values into build logs anyone on the team can view. None of these are hypothetical. Leaked cloud credentials from Secrets checked into Git are one of the most common root causes of production breaches.

Best Practices for Managing Kubernetes Secrets in Production

Treat every raw Secret manifest as sensitive and never commit it to version control. Enable encryption at rest for etcd so Secret data isn't stored as plaintext-equivalent base64 on disk. Scope RBAC tightly with Role and RoleBinding objects so only the ServiceAccounts and users that need a specific Secret can read it, rather than granting cluster-wide get secrets access.

For GitOps workflows where manifests must live in Git, use Sealed Secrets (Bitnami) or SOPS to encrypt values so only your cluster's controller can decrypt them, since the encrypted form is safe to commit even in a public repo. For teams already using a dedicated secrets manager, the External Secrets Operator syncs values from AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, or Azure Key Vault directly into Kubernetes Secret objects at runtime, so the source of truth never lives in the cluster's manifests at all. Rotate credentials regularly, and prefer short-lived tokens over long-lived static passwords wherever your upstream service supports it.

Frequently Asked Questions

No. Base64 is a reversible encoding, not encryption. Anyone can decode it instantly with no key. Kubernetes uses it so manifests can safely hold binary or multi-line data as plain text, not to hide it.

No. Base64 is a reversible encoding scheme, not encryption. Anyone with the encoded string can decode it back to plaintext instantly with no key or password required, using a command like echo '...' | base64 -d or this tool. Kubernetes Secrets store values as base64 purely so the YAML/JSON manifest can safely hold binary or multi-line data as plain text. It is not intended as a security boundary. Real protection comes from encryption at rest (etcd encryption), RBAC restricting who can read Secret objects, and tools like Sealed Secrets or the External Secrets Operator.

Run kubectl create secret generic my-secret --from-env-file=.env. It reads every KEY=VALUE line and base64 encodes each value automatically.

Run kubectl create secret generic my-secret --from-env-file=.env. This reads every KEY=VALUE line in the .env file (skipping blank lines and comments) and creates a Secret named my-secret with each key base64 encoded automatically, so you never have to encode values by hand. Add --namespace=your-namespace to target a specific namespace. Use the Encode tab on this page to preview the exact YAML that command would generate before you apply it.

Run kubectl get secret my-secret -o json | jq -r '.data | map_values(@base64d)' to decode every key in one shot with jq, or paste the YAML into the Decode tab on this page.

Run kubectl get secret my-secret -o json | jq -r '.data | map_values(@base64d)' to decode every key in one shot with jq. Without jq, kubectl get secret my-secret -o jsonpath='{.data}' prints the raw base64 map, which you then pipe per-key through base64 --decode. Paste the same YAML into the Decode tab on this page to see every key and value listed side by side without running any command.

Opaque is generic freeform data (passwords, tokens). kubernetes.io/dockerconfigjson is a specialized type for container registry auth, used specifically for imagePullSecrets.

Opaque is the generic, freeform Secret type used for arbitrary key-value data such as database credentials, API keys, and tokens, and Kubernetes places no structure requirements on the data. kubernetes.io/dockerconfigjson is a specialized type built for container registry authentication: it must contain a single key named .dockerconfigjson holding a base64 encoded Docker config JSON blob, and Kubernetes uses it specifically for imagePullSecrets when pulling private container images. Other built-in types include kubernetes.io/tls for certificate/key pairs and kubernetes.io/basic-auth for username/password pairs.

Update the Secret then run kubectl rollout restart deployment/your-app. A rolling restart replaces pods gradually so traffic keeps flowing, with no downtime as long as readiness probes are configured.

Update the Secret's data in place with kubectl apply or kubectl create secret ... --dry-run=client -o yaml | kubectl apply -f -, then trigger a rolling restart of the workloads that mount it with kubectl rollout restart deployment/your-app. Because a rolling restart replaces pods gradually while old pods keep serving traffic, there is no downtime as long as your readiness probes are configured correctly. If a Secret is mounted as a volume rather than an environment variable, the kubelet updates the mounted file automatically within about a minute, though your application still needs to reload the file or restart to pick up the new value. Environment variables never update without a pod restart.

Kubernetes Secret Decoder

Paste Kubernetes Secret YAML

Decoded Values

Encode .env to Kubernetes Secret

Paste .env file contents

Generated Secret YAML

What Are Kubernetes Secrets, and What Does Base64 Actually Do?

Why Developers Decode Secrets Constantly During Debugging

The Security Risk of Treating Base64 as Protection

Best Practices for Managing Kubernetes Secrets in Production

Frequently Asked Questions

Further reading