Kubernetes Secret Encoder/Decoder & Manifest Sanitizer
Free, zero-ingress tool to encode, decode, and sanitize Kubernetes Secret manifests. Convert Base64 data blocks to readable plain text, encode stringData fields, or scrub secrets for safe Git commits — all processed locally in your browser.
Transparency: How It Works
// Native Browser APIs (no external libraries)
window.btoa(str) // Encode to Base64
window.atob(str) // Decode from Base64
// Regex-based YAML parsing
/^[ \t]*data:[ \t]*\r?\n/m // data: block
/^[ \t]*stringData:[ \t]*\r?\n/m // stringData: block
/^[ \t]+([a-zA-Z0-9._-]+):\s*(.+)$/ // key: value pairs
Transformed YAML will appear here as you type...
Verifiable Security — Zero Network Overhead · Open DevTools Network Tab to Confirm
How to Safely Encode, Decode, and Sanitize Kubernetes Secrets
- Paste Your Kubernetes Secret YAML: Copy your raw manifest (either with Base64-encoded 'data:' blocks or plain-text 'stringData:' blocks) into the left editor pane, or drag-and-drop your .yaml/.yml file directly.
- Select Your Transformation Mode: Choose Decode to view Base64 values as readable plain text for inspection, Encode to convert stringData into Base64-encoded data format, or Sanitize to replace all secret values with safe
<REDACTED_SECRET>placeholders. - Copy or Download the Result: The transformed YAML renders instantly in the right pane. Use the Copy button to grab it for your terminal or kubectl apply, or Download to save it as a .yaml file ready for commit or deployment.
Why You Should Never Paste K8s Manifests into Third-Party Web Converters
Most online Base64 encoders and YAML processors operate on a backend server: you submit your data via an HTTP POST, the server processes it, and returns the result. This architectural model creates a fundamental security vulnerability for production Kubernetes infrastructure.
When you paste a Kubernetes Secret manifest into a third-party converter, you're transmitting your database connection strings, API keys, TLS private keys, OAuth client secrets, and service account tokens over the network to a server you don't control. Even if the connection uses HTTPS, the destination server operator has full access to your plaintext secrets during processing. These values may be logged for debugging, cached for performance, or stored in databases for analytics — exposing your infrastructure to breach, compliance violations, and supply-chain attacks.
ConfigDev eliminates this attack surface entirely. The encoder/decoder runs 100% in your browser's JavaScript engine using the native window.btoa() and window.atob() APIs. Your YAML never leaves your device — you can verify this by opening Chrome DevTools Network tab and confirming zero outbound HTTP requests while the tool operates. This is data sovereignty by architecture: the only way to guarantee secrets aren't collected is to never send them in the first place.
Comparison: Native kubectl CLI vs. Web-Based Sanitization
| Method | Speed | Security Risk | Batch Handling | Git Hygiene |
|---|---|---|---|---|
| echo | base64 | Fast (CLI) | Zero (local) | Manual loops | Manual scrub |
| kubectl create secret | Fast (CLI) | Zero (local) | One-by-one | Not supported |
| ConfigDev Sanitizer | Instant (browser) | Zero (local) | Multi-doc YAML | One-click sanitize |
| Third-party converter | Instant (web) | High (server-side) | Varies | Manual scrub |
Before/After: Sanitize for Git Example
apiVersion: v1 kind: Secret metadata: name: db-credentials type: Opaque data: username: YWRtaW4= password: UEBzc3cwcmQxMjMh database-url: cG9zdGdyZXNxbDovL2FkbWluOlBAc3N3MHJkMTIzIUBkYi5leGFtcGxlLmNvbTo1NDMyL215ZGI=
apiVersion: v1 kind: Secret metadata: name: db-credentials type: Opaque data: username: <REDACTED_SECRET> password: <REDACTED_SECRET> database-url: <REDACTED_SECRET>
Kubernetes Secret Types: A Complete Reference
Kubernetes defines several built-in Secret types via the type: field. Each type enforces different data key constraints and is consumed differently by the kubelet or admission controllers.
| type: value | Use Case | Required Keys |
|---|---|---|
| Opaque | Arbitrary user-defined secrets | None |
| kubernetes.io/service-account-token | Service account JWT tokens | token, ca.crt, namespace |
| kubernetes.io/dockerconfigjson | Docker registry pull credentials | .dockerconfigjson |
| kubernetes.io/basic-auth | HTTP Basic authentication | username, password |
| kubernetes.io/ssh-auth | SSH private key credentials | ssh-privatekey |
| kubernetes.io/tls | TLS certificates and private keys | tls.crt, tls.key |
| bootstrap.kubernetes.io/token | Node bootstrap tokens | token-id, token-secret |
This sanitizer handles all types uniformly — it targets the data: and stringData: blocks regardless of the type: value, so TLS Secrets, Docker registry credentials, and Opaque application secrets are all processed correctly.
Managing Kubernetes Secrets Safely in CI/CD Pipelines
One of the most common sources of secret leakage in Kubernetes deployments is the CI/CD pipeline itself. Teams frequently commit Secret manifests directly to Git repositories — either accidentally or because they lack a reliable sanitization step — where they persist in version history indefinitely, even after the values rotate.
A practical GitOps workflow for handling Secrets safely has three stages:
Stage 1 — Sanitized Templates in Git
Commit only a secret.example.yaml file with all values replaced by <REDACTED_SECRET>. This gives your team a structural reference without exposing live credentials. Use this tool's Sanitize mode to generate that file in one click.
Stage 2 — Secret Injection at Deploy Time
Inject real values at runtime from a trusted secrets manager — AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, or Azure Key Vault — using a Kubernetes operator like the External Secrets Operator (ESO) or Vault Agent Injector. These tools sync secrets from your vault into Kubernetes Secrets automatically, with rotation support and audit trails.
Stage 3 — Seal Secrets for GitOps Workflows
If you need actual encrypted secrets in Git (for fully declarative ArgoCD or Flux deployments), use Bitnami Sealed Secrets or SOPS (Secrets OPerationS). These tools encrypt secret values with a cluster-specific key so only your cluster can decrypt them — the ciphertext is safe to commit.
Quick CLI Reference: Common Secret Operations
# Create a generic Opaque secret from literal values
kubectl create secret generic db-creds \
--from-literal=username=admin \
--from-literal=password='P@ssw0rd123!'
# Decode a specific key from an existing secret
kubectl get secret db-creds -o jsonpath='{.data.password}' | base64 -d
# Export and sanitize an existing secret for documentation
kubectl get secret db-creds -o yaml | \
sed 's/: .*/: <REDACTED_SECRET>/g' > secret.example.yaml
# Apply a secret manifest
kubectl apply -f secret.yaml --namespace=productionKubernetes Secret Security Hardening Best Practices
Base64 encoding is not a security mechanism. Kubernetes Secrets are stored unencrypted in etcd by default, which means anyone with direct etcd access or broad RBAC permissions can read every secret in the cluster. The following hardening layers are essential for any production deployment.
Enable etcd Encryption at Rest
Configure the Kubernetes API server with an EncryptionConfiguration manifest using AES-CBC or AES-GCM providers. This encrypts Secret objects before they are written to etcd, preventing raw reads from etcd backups or direct disk access.
Apply Least-Privilege RBAC
Restrict get, list, and watch verbs on Secret resources to only the service accounts and users that explicitly require them. Avoid cluster-wide wildcard bindings. Audit with kubectl auth can-i --list.
Mount Secrets as Files, Not Env Vars
Environment variables are exposed to all child processes and appear in /proc/<pid>/environ. Mounting secrets as volume files and reading them at runtime reduces the attack surface and prevents accidental leaks through debug dumps or logging frameworks.
Rotate Secrets Regularly
Treat all Kubernetes Secrets as potentially compromised after any security incident, cluster credential rotation, or team member departure. Automate rotation using your external secrets manager's rotation policy and the External Secrets Operator to propagate updates to the cluster automatically.
Enable Audit Logging on Secrets
Configure Kubernetes audit policy to log all get and list requests on Secret resources at the RequestResponse level. Forward audit logs to a SIEM for anomaly detection on unusual secret access patterns.
Use an External Secrets Operator
Tools like the External Secrets Operator sync secrets from AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, and Azure Key Vault into Kubernetes Secrets. This keeps the source of truth outside the cluster and enables centralized rotation, versioning, and access auditing.
Programmatic Base64 Encode/Decode for Kubernetes Secrets
If you need to automate encoding or decoding at scale — in shell scripts, Helm chart pipelines, or CI jobs — these are the idiomatic commands across common environments.
Linux / macOS Shell
# Encode (the -n flag suppresses newline)
echo -n "my-secret-value" | base64
# Decode
echo -n "bXktc2VjcmV0LXZhbHVl" | base64 -d
# Decode directly from a live secret
kubectl get secret my-secret \
-o jsonpath='{.data.password}' | base64 -dPowerShell (Windows)
# Encode
[Convert]::ToBase64String(
[System.Text.Encoding]::UTF8.GetBytes(
"my-secret-value"))
# Decode
[System.Text.Encoding]::UTF8.GetString(
[Convert]::FromBase64String(
"bXktc2VjcmV0LXZhbHVl"))Python
import base64
# Encode
encoded = base64.b64encode(
b"my-secret-value").decode("utf-8")
# Decode
decoded = base64.b64decode(
"bXktc2VjcmV0LXZhbHVl").decode("utf-8")Go
import "encoding/base64"
// Encode
enc := base64.StdEncoding.EncodeToString(
[]byte("my-secret-value"))
// Decode
dec, err := base64.StdEncoding.DecodeString(
"bXktc2VjcmV0LXZhbHVl")Common Kubernetes Secret Mistakes (and How to Fix Them)
Mistake 1: Encoding with a trailing newline
Running echo "value" | base64 (without -n) encodes the newline character too, producing a different Base64 string. When Kubernetes decodes it, your application receives the value with a trailing \n, which breaks connection string parsers and authentication headers silently.
Fix: Always use echo -n or this browser tool, which handles the encoding correctly without adding newlines.
Mistake 2: Committing live Secret manifests to Git
Even a single commit of a live Secret file persists in Git history permanently. Rotating the secret value does not remove it — anyone who clones the repository can check out that commit and recover the original value. This is a critical compliance violation under SOC 2, PCI-DSS, and HIPAA.
Fix: Use the Sanitize mode here to generate a secret.example.yaml for Git, and add *secret*.yaml to your .gitignore.
Mistake 3: Using the default Opaque type for TLS certificates
TLS certificates stored as Opaque Secrets with arbitrary key names won't be recognized by Ingress controllers or cert-manager, which expect the standard kubernetes.io/tls type with keys tls.crt and tls.key.
Fix: Set type: kubernetes.io/tls and use the standard key names so Ingress and cert-manager can consume the Secret correctly.
Mistake 4: Mixing stringData and data in the same manifest
While Kubernetes allows both stringData and data in the same Secret, if the same key appears in both blocks, stringData takes precedence. This creates confusing precedence bugs that are hard to debug in multi-team environments.
Fix: Use the Encode mode here to convert all stringData fields to Base64 data fields, keeping your manifest consistent.
Frequently Asked Questions
How does Base64 encoding differ from encryption in Kubernetes?
Base64 is a text encoding scheme, not encryption. It simply transforms binary data into a printable ASCII string so YAML can carry it safely. Anyone with the Base64 string can decode it instantly using 'echo <value> | base64 -d'. Kubernetes Secrets stored as Base64 in etcd are only as secure as the RBAC policies and etcd encryption-at-rest configuration protecting the cluster — the Base64 layer itself provides zero confidentiality.
How do I convert stringData to data in a Kubernetes Secret manifest?
Kubernetes accepts both fields. Under 'stringData', values are plain-text strings that the API server automatically Base64-encodes before storing. Under 'data', values must already be Base64-encoded. To convert: take each plain-text value from stringData, run 'echo -n "value" | base64' (the -n flag omits the trailing newline), and place the result under 'data'. This tool's Encode mode does this automatically for every key in your manifest.
Is my production secret or API key sent to any server while using this tool?
No. Every operation — Base64 encoding, decoding, and manifest sanitization — runs entirely inside your browser's local JavaScript engine using the native window.btoa() and window.atob() functions. You can verify this by opening your browser DevTools Network tab while using the tool: zero outbound requests will be made. Your secrets never leave your machine.
What does the Sanitize for Git action actually replace?
The sanitizer targets all values under 'data:' and 'stringData:' keys inside Kubernetes Secret documents. It replaces each raw value (whether Base64-encoded or plain-text) with the placeholder '<REDACTED_SECRET>', preserving the full YAML structure, indentation, and all other fields (metadata, labels, annotations, type). The result is a safe template you can commit to a public or shared repository as a .example.yaml reference.
Can I use this tool on multi-document YAML files?
Yes. The tool processes manifests separated by the standard YAML document separator '---', sanitizing Secret documents while leaving non-Secret documents (Deployments, ConfigMaps, Services, etc.) completely untouched.
Why should I never use online converters that process YAML server-side?
Server-side converters receive your raw YAML payload over HTTPS, process it on a backend, and return the result. This means your production database URLs, TLS private keys, API tokens, and service account credentials transit a third-party network and are processed by infrastructure you don't control. Even with TLS in transit, the server operator has full access to your plaintext secrets during processing and in any logs. ConfigDev processes everything in the browser — the server only delivers the static HTML/JS bundle.
Are Kubernetes Secrets secure by default?
No. By default, Kubernetes stores Secret objects in etcd as plain Base64-encoded data without any additional encryption layer. Anyone with direct etcd access — or sufficient RBAC permissions to read Secrets in the cluster — can retrieve all values. Production clusters should enable etcd encryption at rest using an EncryptionConfiguration, apply strict least-privilege RBAC, and consider using an external secrets manager like HashiCorp Vault or AWS Secrets Manager.
What is the difference between a Kubernetes Secret and a ConfigMap?
Both store key-value configuration data, but they serve different purposes and carry different access controls. ConfigMaps are designed for non-sensitive configuration like feature flags, environment names, or application settings. Secrets are designed for sensitive data — passwords, tokens, certificates — and benefit from additional access controls, audit logging, and optional encryption at rest. In practice, the key distinction is intent and policy: cluster administrators can restrict Secret access more granularly than ConfigMap access.
How do I prevent Kubernetes Secrets from appearing in application logs?
Mount Secrets as volume files rather than environment variables, and configure your logging framework to redact known sensitive patterns. Avoid logging request headers or environment dumps in application code. Use structured logging with field-level filtering, and run log outputs through a PII scrubber before shipping to external log aggregators. Never log the full contents of a Secret or any value retrieved from one.
What is the External Secrets Operator and when should I use it?
The External Secrets Operator (ESO) is a Kubernetes operator that synchronizes secrets from external secret management systems (AWS Secrets Manager, GCP Secret Manager, Azure Key Vault, HashiCorp Vault, 1Password) into native Kubernetes Secrets. Use it when you need centralized secret management, automatic rotation propagation, audit trails, and cross-cluster secret sharing. It removes the need to manually manage Secret manifests while keeping the cluster's native Secret consumption model intact.
What is the difference between Sealed Secrets and SOPS for GitOps?
Sealed Secrets (Bitnami) encrypts Secret manifests using a public key tied to a specific cluster controller — only that cluster can decrypt them. This works well for single-cluster GitOps but requires key management if the cluster is recreated. SOPS (Mozilla/Getsops) is a more flexible tool that encrypts individual values inside YAML, JSON, or ENV files using KMS keys (AWS, GCP, Azure) or age keys, supporting multi-cluster and multi-environment workflows. Both are appropriate for committing encrypted secrets to Git; the choice depends on your key management preferences.
Can I decode a Kubernetes Secret without kubectl?
Yes. If you have the raw YAML manifest (e.g., exported from a cluster backup or CI artifact), you can decode the Base64 values using any Base64 decoder — including this tool, the command 'echo -n <value> | base64 -d' on Linux/macOS, or Python's base64 module. This tool's Decode mode processes the full manifest and renders all secret values as readable plain text in one pass, without requiring cluster access.