ConfigMap vs Secret: What's the Actual Difference
Both a kubernetes configmap yaml generator and a kubernetes secret yaml generator produce the same basic shape, a Kubernetes object holding key-value pairs that pods can mount as files or inject as environment variables, but they exist for different intents. A ConfigMap is meant for non-sensitive configuration, feature flags, hostnames, log levels. A Secret is meant for sensitive values, passwords, API keys, tokens, and Kubernetes stores its data base64-encoded rather than as plain text. That distinction matters for a reason people frequently get wrong: base64 encoding is not encryption, it's a reversible text-safe encoding, anyone with API or etcd read access to a Secret can trivially decode it back to plaintext. Real secret protection requires RBAC restricting who can read Secret objects, and ideally etcd encryption at rest configured on the cluster.
How to Use This Kubernetes ConfigMap Generator
This k8s configmap generator online starts with the resource name and namespace, then a Kind picker: ConfigMap, Secret, or Both to generate both objects from a single form. Enter your ConfigMap data as KEY=value pairs, one per line, in the ConfigMap field, and your Secret data the same way in the separate Secret field, they're intentionally independent so you're not forced to put the same values in both. Leave "Base64-encode Secret values" on to generate kubernetes secret yaml using the standard data field (the normal, expected format), or turn it off to generate stringData instead, useful when you want to read or hand-edit the plaintext values directly in the YAML before applying. Copy or download the result and apply it with kubectl apply -f configmap.yaml, free to use with no account required.
data vs stringData in a Kubernetes Secret
This k8s secret stringdata vs data choice controls how the values appear in the generated YAML. The data field expects every value already base64-encoded, which is what kubectl and the Kubernetes API actually store internally, this generator handles the encoding for you automatically. stringData accepts plain, unencoded text directly, Kubernetes encodes it server-side. stringData is a write-only convenience, useful for humans hand-editing a Secret file, but a `kubectl get secret -o yaml` will always show you the encoded data field back, stringData never round-trips.
| Field | Values Must Be | Best For |
|---|---|---|
| data | Already base64-encoded | Standard, machine-generated Secrets (the default) |
| stringData | Plain, unencoded text | Hand-editing a Secret file before applying it |
Common Mistakes This Tool Helps Avoid
The single most common Kubernetes Secret mistake is treating base64 as if it were encryption, it isn't, and this tool's generated output includes a decoded-value reference comment specifically to make that visible rather than hidden behind an encoded blob. A second common mistake is putting genuinely sensitive values, like database passwords, into a ConfigMap instead of a Secret because it's the first field someone reaches for, this tool's two separate key=value fields (one clearly labeled ConfigMap, one clearly labeled Secret) make that split a deliberate choice rather than an accident. A third: assuming a Secret is automatically safe once applied, it isn't, without RBAC restricting read access and etcd encryption at rest enabled on the cluster, anyone who can read Secret objects can decode every value in seconds.