Why does this generate stringData instead of data?

data expects values that are already base64-encoded, which means either encoding them yourself first or trusting a tool to do it silently. stringData accepts plain text directly, and the Kubernetes API server base64-encodes it into data on your behalf the moment the object is created or updated, merging it in automatically. Using stringData keeps this generator's output human-readable and avoids a client-side base64 step entirely.

Is a Kubernetes Secret actually encrypted?

By default, no: base64 is an encoding, not encryption, and anyone with API read access to the Secret (or etcd access, if encryption at rest isn't configured) can decode it trivially. Enable encryption at rest and RBAC restrictions on Secret access, or use an external secrets manager, for anything genuinely sensitive.

What keys does a kubernetes.io/tls Secret expect?

Conventionally tls.crt and tls.key, holding the PEM-encoded certificate and private key respectively; Kubernetes' TLS-consuming resources (like Ingress) expect exactly these two key names.

What about kubernetes.io/dockerconfigjson?

That type conventionally uses a single key, .dockerconfigjson, containing the full JSON content of a Docker config.json file, used for imagePullSecrets when pulling images from a private registry.

Kubernetes Secret Generator - Build Secret YAML

Overview

Introduction

Typing out a Secret manifest by hand usually means also base64-encoding every value yourself first, an easy step to get subtly wrong (trailing newline, wrong encoding) when done manually.

This tool generates a Secret manifest using stringData, so you type plain-text values and let the Kubernetes API server handle base64 encoding when the manifest is applied, entirely client-side.

What Is Kubernetes Secret YAML Generator?

A Kubernetes Secret YAML generator supporting the three most common Secret types: generic Opaque secrets, kubernetes.io/tls certificate/key pairs, and kubernetes.io/dockerconfigjson registry credentials.

Every key/value entry you add is written under stringData, Kubernetes' plain-text input field for Secret data.

How Kubernetes Secret YAML Generator Works

The Secret type toggle sets the manifest's top-level type field directly, which tells Kubernetes and any tooling that reads Secrets what shape of data to expect inside.

Each key/value row becomes one entry under stringData, written as plain, human-readable text in the generated YAML rather than pre-encoded base64.

When you apply this manifest, the Kubernetes API server merges stringData into data by base64-encoding each value automatically; stringData itself is never actually stored, it's a write-only convenience field.

When To Use Kubernetes Secret YAML Generator

Use Opaque for arbitrary application secrets like database credentials, API keys, or tokens.

Use kubernetes.io/tls when you need to store a certificate and private key for Ingress TLS termination or similar.

Use kubernetes.io/dockerconfigjson to create an imagePullSecret referencing a private container registry.

Often used alongside Kubernetes ConfigMap YAML Generator, Kubernetes Deployment YAML Generator and Kubernetes Ingress YAML Generator.

Features

Advantages

Uses stringData so you never have to base64-encode values by hand or worry about getting the encoding subtly wrong.
Supports the three Secret types teams reach for most often, with the manifest shape (type, expected keys) adjusted per type.
Runs entirely client-side; nothing you type here is ever transmitted anywhere, though see the Developer Notes on what happens once you apply it.

Limitations

Doesn't encrypt or protect the values you type; they're plain text in your browser tab and in the generated YAML until Kubernetes encodes and stores them.
Doesn't validate that a kubernetes.io/tls Secret's values are actually well-formed PEM certificates/keys.
Doesn't support Secret types beyond the three listed (for example, kubernetes.io/basic-auth or kubernetes.io/ssh-auth); use Opaque with the expected key names as a workaround if needed.

Examples

An Opaque Secret with database credentials

Input

name: db-credentials, type: Opaque, entries: [username=admin, password=s3cr3t]

Output

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
stringData:
  username: admin
  password: s3cr3t

Kubernetes base64-encodes both values into the Secret's data field automatically when this manifest is applied.

Best Practices & Notes

Best Practices

Never commit a generated Secret manifest containing real credentials to version control; treat it the same way you'd treat a plaintext password file.
Restrict who can read Secrets in a namespace via RBAC; stringData/data both ultimately just base64-encode, they don't restrict access on their own.
Rotate any credential that was ever pasted into a browser tab (including this tool) if you have any doubt about that tab's security.

Developer Notes

This generator never base64-encodes anything itself; it only ever writes plain-text values under stringData, which is the API server's job to encode into data at apply time. That's a deliberate design choice: performing base64 encoding client-side would offer zero security benefit (base64 isn't encryption) while adding a step that could silently corrupt values (for example, trailing-newline handling differs between naive encoders), so this tool leaves that entirely to Kubernetes.

Kubernetes Secret YAML Generator Use Cases

Creating database or third-party API credentials for a Deployment to consume as environment variables or a mounted volume
Producing a TLS Secret referenced by an Ingress's tls.secretName for HTTPS termination
Creating an imagePullSecret so a cluster can pull images from a private container registry

Common Mistakes

Assuming base64 encoding means the Secret is encrypted or otherwise protected; it is trivially reversible by anyone with read access.
Pasting a certificate or key with an extra trailing newline or missing PEM header/footer into a kubernetes.io/tls Secret, which most TLS consumers will reject.
Committing a filled-in Secret manifest to a public or shared git repository instead of a secrets manager or sealed-secrets workflow.

Tips

Pair a kubernetes.io/tls Secret with the Kubernetes Ingress Generator's tlsSecretName field to wire up HTTPS termination end to end.

Kubernetes Secret YAML Generator