Kubernetes Secret Builder

Build Kubernetes Secret manifests for any type — Opaque, TLS, Docker Registry, Basic Auth, or SSH.

100% client-side — your secrets never leave your browser.

Quick Start — Try a template

1 — Secret type

Generic key/value secret (default) — Opaque

2 — Secret metadata

Name

Namespace

3 — Options

4 — Secret data

Key / Value / Description

How to use this tool

What are Kubernetes Secrets?

A Kubernetes Secret is an object that stores sensitive data such as passwords, tokens, keys, and certificates. They keep confidential data out of your Pod specs and container images. Values in a Secret are base64-encoded (not encrypted) by default, so you should combine them with RBAC and encryption-at-rest for production security.

Secret Types

Opaquetype: Opaque

The default type. Stores arbitrary key-value pairs. Used for database credentials, API keys, connection strings, and general application secrets.

TLStype: kubernetes.io/tls

Stores a TLS certificate (tls.crt) and its private key (tls.key). Commonly used with Ingress resources for HTTPS termination.

Docker Registrytype: kubernetes.io/dockerconfigjson

Stores credentials for pulling container images from a private registry. Generates the .dockerconfigjson format automatically. Referenced via imagePullSecrets in the Pod spec.

Basic Authtype: kubernetes.io/basic-auth

Stores a username and password for basic HTTP authentication. The API server validates that both keys are present.

SSH Authtype: kubernetes.io/ssh-auth

Stores an SSH private key (ssh-privatekey). Typically mounted as a volume and used for Git operations or SSH tunnels from within pods.

stringData vs data

stringData

Values are written in plain text. Kubernetes automatically base64-encodes them when the Secret is created. Easier to read and edit.

data

Values must be pre-encoded in base64. This is the native storage format. Use this when passing already-encoded values or copying from kubectl get secret -o yaml.

Immutable Secrets

Setting immutable: true prevents the Secret from being updated after creation. This protects against accidental changes and improves cluster performance since the API server does not need to watch for changes. To update an immutable Secret, you must delete and recreate it.

Mounting Secrets as Volumes

Instead of injecting secrets as environment variables, you can mount them as files in a pod. Each key in the Secret becomes a file in the mount path. This is required for TLS certificates and SSH keys, and is useful when your application reads config from files. The files are automatically updated when the Secret changes (unless immutable).

Security Considerations

Base64 is encoding, not encryption. Enable encryption at rest via EncryptionConfiguration.
Use RBAC to restrict who can read Secrets. Limit get/watch/list access.
Consider external secret managers (Vault, AWS Secrets Manager, GCP Secret Manager) via operators like External Secrets.
Avoid storing Secrets in Git. Use sealed-secrets or SOPS for GitOps workflows.
Pods that reference a Secret can only access it if the Secret is in the same namespace.