Why you need a Kubernetes secret generator
Creating secrets manually in Kubernetes introduces risks: your bash history stores credentials in plain text, system logs can expose them, and manual base64 encoding is error-prone. This generator produces secure values you can inject directly into manifests without touching the terminal.
Secrets generated here are cryptographically random using OS-level sources, not predictable pseudo-random. Each execution produces unique values suitable for production environments, from database passwords to third-party API tokens.
Real use cases: configuring PostgreSQL in a StatefulSet, integrating external services via ConfigMaps, authenticating private Docker registries, or rotating credentials after a security incident.
How to apply secrets in your manifests
Once generated, create a YAML file like my-secret.yaml with basic structure: apiVersion: v1, kind: Secret, metadata.name, and the data field with your base64-encoded keys. Apply with kubectl apply -f my-secret.yaml.
To consume from a Pod, mount it as a volume (volumes.secret.secretName) or inject as environment variable (valueFrom.secretKeyRef). The second option is more direct for simple credentials; the first works better for TLS certificates or complex config files.
Common mistake: forgetting that base64 isn't encryption. If your cluster doesn't have encryption-at-rest enabled (EncryptionConfiguration), secrets are stored plain text in etcd. Always enable encryption in production.
Secret types and when to use each
Kubernetes recognizes Opaque (generic), kubernetes.io/tls (certificates), kubernetes.io/dockerconfigjson (registry), and kubernetes.io/service-account-token. 90% of your secrets will be Opaque: passwords, API keys, custom tokens.
For private registries, use docker-registry type with kubectl create secret docker-registry or generate the .dockerconfigjson JSON manually. TLS secrets expect tls.crt and tls.key as mandatory keys.
Practical tip: separate secrets by scope. One per database, another for external APIs. This way you rotate credentials without affecting unrelated services. Use labels and namespaces to isolate critical secrets from the rest of the cluster.
Secret rotation and production management
A secret without rotation policy is a ticking time bomb. Establish rotation windows by criticality: every 30 days for admin passwords, every 90 for read-only tokens. Automate with CronJobs calling external APIs (Vault, AWS Secrets Manager) and updating secrets via kubectl patch.
Tools like Sealed Secrets or External Secrets Operator let you store encrypted secrets in Git and sync them to the cluster. This way you audit changes without exposing real values. Never commit unencrypted secrets, not even in private repos.
Security checklist:
- Strict RBAC (only necessary ServiceAccounts read secrets)
- Encryption-at-rest enabled in etcd
- API server logs don't print secret values
- Secrets with TTL where possible (cert-manager for TLS)