Working with specific Kubernetes secret types

Published: 2026-08-30

When working with secrets in Kubernetes, you often only need to create generic secrets. But every now and then, I find myself having to create specific secret types. The only difference between these secrets and generic ones is that they have a type field and required data keys. Here are some snippets, tips, and my understanding of these special kinds of secrets.

Basic authorization secret

The kubernentes.io/basic-auth secret types is just that, it’s for authorization operations. It has two required keys: username and password.

Here’s an example from the official documentation:

apiVersion: v1
kind: Secret
metadata:
  name: secret-basic-auth
type: kubernetes.io/basic-auth
stringData:
  username: admin
  password: t0p-Secret

I find that I need them most often when setting up PostgreSQL databases. If you’re using a controller like CloudNativePG, you can reference basic-auth secrets as part of it’s database Cluster specification.

TLS secret

Another common type is the kubernetes.io/tls secret. I’ve encountered these the most, of course, when dealing with CA certificates. The two required fields are the tls.crt and tls.key key pair.

apiVersion: v1
kind: Secret
metadata:
  name: secret-tls
type: kubernetes.io/tls
stringData:
  tls.crt: "REPLACE_WITH_BASE64_CERT"
  tls.key: "REPLACE_WITH_BASE64_KEY"

When I used Sealed Secrets for secret management, it was helpful to generate these secrets for development and testing clusters. Under the hood, the Sealed Secrets controller usees the key pairs to encrypt and decrypt secrets it manages.

Some helpful hints

It took be a while to figure this out, but just because these secret types have required fields, it doesn’t mean that they are limited to these fields. I noticed this when inspecting secrets that were auto-generated by CloudNativePG. They included some other helpful keys like the full database URI, service names, and ports.

Knowing this helped out when creating secrets for other deployments that required kubernetes.io/basic-auth secrets but also needed supplemental credentials to be provided. I could still put everything into one resource if I wanted!