Kubernetes ConfigMap & Secret Generator

Hand-writing Kubernetes manifests is fiddly: one wrong indent, an unquoted true that YAML reads as a boolean, or a Secret value you forgot to base64-encode, and kubectl apply rejects the file. This generator builds a valid apiVersion: v1 ConfigMap or Secret for you from a simple list of key/value pairs — with correct indentation, quoting, and base64 encoding handled automatically.

What it does

Pick a resource type, give it a name and (optionally) a namespace and labels, then paste your configuration as KEY=value or KEY: value pairs, one per line. The tool emits ready-to-apply YAML:

• ConfigMap — kind: ConfigMap with your pairs under data: as plain strings, quoted only when a value would otherwise be ambiguous (numbers, booleans, values containing : or #, etc.).
• Secret — kind: Secret with a selectable type (Opaque, kubernetes.io/tls, kubernetes.io/dockerconfigjson, and more) and your choice of data: (base64-encoded) or stringData: (plain text).

How to use it

1. Choose ConfigMap or Secret.
2. Enter a Name (lowercase RFC 1123 — letters, digits, -, .) and an optional Namespace.
3. For a Secret, choose the type and whether values go in data: or stringData:.
4. Add your pairs in the Key / Value Data box. Only the first =/: on a line splits the pair, so a value like postgres://user:pass@db:5432/app keeps its own colons. Need a multi-line value (a config file, a certificate)? Write \n where the line breaks should go and the tool emits a YAML literal block scalar (|-).
5. Optionally add labels and toggle immutable.
6. Copy or download the generated manifest.

What's the difference between data and stringData?

This is the part that trips people up. A Kubernetes Secret ultimately stores every value base64-encoded. The two fields are just two ways to give it those values:

• data: expects values that are already base64-encoded. This tool encodes them for you, so password=s3cr3t becomes password: czNjcjN0. This is the canonical on-disk form you'll see when you run kubectl get secret -o yaml.
• stringData: takes plain-text values. When you apply the manifest, kubectl (really the API server) base64-encodes them for you and merges them into data. It's a write-only convenience field — it never appears when you read the Secret back.

Use stringData when you want a human-readable manifest; use data when you want the exact stored representation. Either way the Secret behaves identically once applied.

Is base64 encryption?

No. Base64 is encoding, not encryption — anyone can decode it instantly. A Kubernetes Secret is not encrypted at rest unless your cluster is configured for encryption at rest. Treat the output as sensitive and never commit real Secret manifests to a public repository.

Why is my value quoted / turned into a block?

To keep the YAML unambiguous. A value that looks like a number (1024), a boolean (true), or that contains YAML-significant characters (:, #, @, leading spaces) is double-quoted so it's read as a string. Values containing newlines are written as a literal block scalar so whitespace is preserved exactly.

What does "immutable" do?

Adding immutable: true marks the resource so it cannot be updated after creation — you'd delete and recreate it to change it. It's recommended for Secrets and ConfigMaps that never change: it protects against accidental updates and reduces load on the kubelet, which stops watching immutable objects.

Privacy

Everything runs entirely in your browser. Your names, labels, and — most importantly — your Secret values are never uploaded, logged, or sent to any server. The generation, base64 encoding, and YAML formatting all happen locally on your device, so it's safe to paste sensitive configuration.