.env to Kubernetes Secret Converter
Convert your .env file to a Kubernetes Secret manifest. Choose base64-encoded data or plain stringData format. Use the converter above, then follow this guide for production-grade secret management.
.env to Docker/K8s Converter
Convert .env files to Docker Compose environment blocks, Kubernetes ConfigMaps, Secrets, or docker run flags. Sensitive keys are detected automatically. Validate your .env first →
Output Format Reference
| Format | Use Case | Sensitive Data? |
|---|---|---|
| Docker Compose (inline) | Variables directly in docker-compose.yml | Not recommended — values visible in file |
| Docker Compose (env_file) | Reference .env file from compose | Better — .env excluded from VCS via .gitignore |
| K8s ConfigMap | Non-sensitive config in Kubernetes | Not for secrets — data is plain text |
| K8s Secret (base64) | Standard K8s secrets (base64 encoded) | Base64 is encoding, not encryption — use RBAC + encryption at rest |
| K8s Secret (stringData) | Human-readable secrets (auto-encoded by K8s) | Same security as data: — encoded on apply |
| docker run -e | One-off container runs with env vars | Visible in process list — avoid for secrets |
Secret data vs stringData
Kubernetes Secrets support two data fields. 'data' requires base64-encoded values — what Kubernetes stores internally. 'stringData' accepts plain text that Kubernetes auto-encodes on apply. Both produce identical Secrets at runtime. Use stringData during development for readability. Use data in CI/CD pipelines where values are pre-encoded. You can mix both in the same manifest — stringData values override data values for the same key.
# base64-encoded data
apiVersion: v1
kind: Secret
metadata:
name: app-secrets
type: Opaque
data:
DB_PASSWORD: c3VwZXItc2VjcmV0 # echo -n 'super-secret' | base64
# Plain stringData (auto-encoded on apply)
apiVersion: v1
kind: Secret
metadata:
name: app-secrets
type: Opaque
stringData:
DB_PASSWORD: "super-secret"Encryption at rest
By default, Kubernetes stores Secrets as base64 in etcd — this is encoding, not encryption. Anyone with etcd access can read them. Enable encryption at rest with an EncryptionConfiguration that uses aescbc, aesgcm, or a KMS provider (AWS KMS, GCP KMS, Azure Key Vault). Managed Kubernetes services (EKS, GKE, AKS) offer envelope encryption by default or with a checkbox.
External secret management
For production, consider external secret operators: External Secrets Operator (syncs from AWS SM, Vault, GCP SM, Azure KV), Sealed Secrets (encrypts secrets for Git storage), and SOPS (encrypts YAML files). These let you store encrypted secret manifests in Git while the operator decrypts them in-cluster. The converter output is a starting point — move to external management as you scale.
Frequently Asked Questions
Is base64 encoding in Kubernetes Secrets secure?
No. Base64 is encoding, not encryption — anyone can decode it. Kubernetes Secrets are only as secure as your etcd encryption and RBAC policies. Enable encryption at rest (EncryptionConfiguration or managed K8s encryption), restrict Secret access with RBAC, and avoid committing Secret manifests to Git.
Should I use data or stringData in Kubernetes Secrets?
Use stringData for human-written manifests (easier to read and edit). Use data for machine-generated manifests in CI/CD where values are already base64-encoded. Both produce identical Secrets when applied. stringData is a write-only convenience — kubectl get secret always shows base64-encoded data.
Related Convert Tools
CSV ↔ JSON Converter
Convert between CSV and JSON formats with custom delimiters
URL Encoder & Decoder
Encode and decode URLs with encodeURIComponent and encodeURI
JSON ↔ YAML Converter
Convert between JSON and YAML for Kubernetes, Docker, and CI/CD configs
HTML Entity Encoder
Encode and decode HTML entities, special characters, and symbols