Course outline

01 · Kubernetes Architecture Deep Dive

02 · Workloads & Scheduling

03 · Networking, Storage & Service Mesh

04 · Platform Engineering & Multi-Tenancy

05 · Networking & Service Mesh

06 · Observability & Autoscaling

07 · Configuration & Secrets Management

08 · Stateful Storage Operations

09 · Security, Identity & Admission

10 · Release Packaging with Helm & Kustomize

11 · Operators, CRDs & Controllers

12 · Production Troubleshooting & Operations

Stage 5 · Platform

Configuration & Secrets Management

Secret Types

Opaque, TLS, dockerconfigjson, service account tokens, and encryption at rest with KMS.

7 min readKubernetes & Cloud NativePlatform

Secret Overview

Secrets store sensitive data: passwords, tokens, certificates. They are similar to ConfigMaps but are base64-encoded and (with encryption at rest) encrypted in etcd. Secrets are namespace-scoped and can be mounted as volumes or injected as environment variables.

Secrets are not secure by default

Secrets are only base64-encoded, not encrypted. Anyone with cluster access can read them with kubectl get secret. Enable encryption at rest with KMS to protect secrets in etcd. Never commit secrets to Git.

Opaque Secrets

Opaque is the default Secret type. It stores arbitrary key-value pairs as base64-encoded strings. Use it for database passwords, API keys, and any sensitive configuration.

Opaque Secret creation


apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
  namespace: production
type: Opaque
data:
  # echo -n "mypassword" | base64
  password: bXlwYXNzd29yZA==
  # echo -n "admin" | base64
  username: YWRtaW4=
stringData:
  # stringData is auto-encoded to base64
  connection-string: "postgresql://admin:mypassword@postgres:5432/mydb"
  api-key: "sk-1234567890abcdef"

data field requires base64-encoded values. stringData accepts plain strings and encodes them automatically. stringData is not returned by the API — it's write-only. Use kubectl create secret to avoid managing base64 manually.

TLS Secrets

TLS Secrets store TLS certificates and private keys. They are used by Ingress controllers, Service mesh, and admission webhooks. The tls.crt and tls.key fields are required.

TLS Secret for Ingress


apiVersion: v1
kind: Secret
metadata:
  name: api-tls-cert
  namespace: production
type: kubernetes.io/tls
data:
  tls.crt: <base64-encoded-certificate>
  tls.key: <base64-encoded-private-key>
---
# Create from files
# kubectl create secret tls api-tls-cert \
#   --cert=cert.pem --key=key.pem -n production

TLS Secrets are referenced in Ingress spec.tls[].secretName. The Ingress controller reads the certificate and configures TLS termination. cert-manager can automate TLS certificate provisioning and renewal.

Docker Config Secrets

Docker Config Secrets store registry credentials. They are used by kubelet to pull images from private registries. The kubernetes.io/dockerconfigjson type stores the full Docker config.json.

Docker registry Secret


apiVersion: v1
kind: Secret
metadata:
  name: ghcr-credentials
  namespace: production
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: <base64-encoded-docker-config>
---
# Create from docker login
# kubectl create secret docker-registry ghcr-credentials \
#   --docker-server=ghcr.io \
#   --docker-username=myuser \
#   --docker-password=mypassword \
#   -n production
---
# Use in pod spec
apiVersion: v1
kind: Pod
metadata:
  name: private-image-pod
spec:
  imagePullSecrets:
  - name: ghcr-credentials
  containers:
  - name: app
    image: ghcr.io/my-org/private-app:1.0

imagePullSecrets tells kubelet which Secret to use when pulling images. The Secret must be in the same namespace as the Pod. For multiple namespaces, create the Secret in each namespace.

Service Account Tokens

Service account tokens are JWT tokens issued to pods for authenticating with the API server. In v1.24+, tokens are bound to the pod's lifetime and audience by default. They are projected into the pod at /var/run/secrets/kubernetes.io/serviceaccount/.

Projected service account token


apiVersion: v1
kind: Pod
metadata:
  name: api-caller
spec:
  serviceAccountName: api-reader
  automountServiceAccountToken: true
  containers:
  - name: app
    image: my-app:1.0
    volumeMounts:
    - name: sa-token
      mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      readOnly: true
  volumes:
  - name: sa-token
    projected:
      sources:
      - serviceAccountToken:
          path: token
          expirationSeconds: 3600  # 1 hour
          audience: https://kubernetes.default.svc

Projected tokens are scoped to a specific audience and expiration. The token is auto-rotated by kubelet before expiry. automountServiceAccountToken: false disables automatic mounting if the pod doesn't need API access.

Encryption at Rest

Encryption at rest protects secrets in etcd. Without it, secrets are stored as base64-encoded plaintext. With KMS (Key Management Service), secrets are encrypted using a key managed by your cloud provider. This is required for compliance.

Encryption configuration


apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
  - secrets
  - configmaps
  providers:
  - aescbc:
      keys:
      - name: key1
        secret: <base64-encoded-32-byte-key>
  - identity: {}  # Fallback to plaintext for reading

aescbc encrypts secrets using AES-CBC mode. identity provider reads plaintext (for migration). When writing, aescbc is used. When reading, providers are tried in order. Rotate keys by adding a new key and removing the old one.

Azure Key Vault integration

Use External Secrets Operator or Secrets Store CSI Driver to sync secrets from Azure Key Vault. This eliminates storing secrets in etcd entirely. Secrets are fetched from Key Vault and mounted into pods at runtime.

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.