Secrets

Welcome to this lesson on managing sensitive data with Kubernetes Secrets.

A presentation slide titled "Kubernetes Secrets" with a dark curved panel on the right displaying a locked folder icon. The left side is mostly white with a small "© Copyright KodeKloud" notice in the corner.

Overview

Kubernetes Secrets provide a way to store and manage sensitive information such as passwords, tokens, and keys. Unlike ConfigMaps (which store plain-text configuration), Secrets store values as base64-encoded data. Remember: base64 is only encoding, not encryption — apply RBAC, encryption at rest, and external KMS integrations for production workloads.

Kubernetes Secrets store values as base64-encoded data. This encoding hides values from casual viewing but is not strong encryption. Use encryption at rest and appropriate RBAC policies for production.

Example application: what not to do

Below is a simple Python Flask app that connects to MySQL. The database hostname, username, and password are hardcoded — which is insecure and not recommended.

import mysql.connector
from flask import Flask, render_template

app = Flask(__name__)

@app.route("/")
def main():
    mysql.connector.connect(host='mysql', database='mysql',
                            user='root', password='paswrd')
    return render_template('hello.html', color=fetchcolor())

if __name__ == "__main__":
    app.run(host="0.0.0.0", port=8080)

Move non-sensitive configuration to ConfigMaps

ConfigMaps are suitable for non-sensitive values (hostnames, feature flags). Do not store credentials here in production. Example ConfigMap (declarative):

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DB_Host: mysql
  DB_User: root
  DB_Password: paswrd

Note: The DB_Password above should not be stored in a ConfigMap — shown here only for contrast. Secrets vs ConfigMaps (quick comparison)

Feature	ConfigMap	Secret
Intended for	Non-sensitive config	Sensitive data (passwords, tokens)
Storage	Plain text	Base64-encoded (not encryption)
Use cases	Hostnames, flags	DB credentials, API keys

Creating Secrets

Two common workflows:

Imperative: kubectl create secret from literals or files.
Declarative: apply a YAML Secret manifest where data is base64-encoded.

Imperative creation from key/value pairs:

kubectl create secret generic app-secret \
  --from-literal=DB_Host=mysql \
  --from-literal=DB_User=root \
  --from-literal=DB_Password=paswrd

Create a Secret from a file (file contents become the secret value):

kubectl create secret generic app-secret \
  --from-file=app_secret.properties

Declarative creation requires base64-encoded values

Convert values to base64 on a Linux/macOS host:

echo -n 'mysql' | base64
echo -n 'root' | base64
echo -n 'paswrd' | base64
# cGFzd3Jk

Secret manifest with encoded values:

apiVersion: v1
kind: Secret
metadata:
  name: app-secret
type: Opaque
data:
  DB_Host: bXlzcWw=
  DB_User: cm9vdA==
  DB_Password: cGFzd3Jk

Apply the YAML (you can use either kubectl create -f or kubectl apply -f):

kubectl create -f secret-data.yaml
# or
kubectl apply -f secret-data.yaml

Inspecting Secrets

List secrets:

kubectl get secrets

Example output:

NAME                    TYPE                                  DATA   AGE
app-secret              Opaque                                3      10m
default-token-mvtkv     kubernetes.io/service-account-token   3      2h

Describe a secret (shows metadata and key sizes, not raw values):

kubectl describe secret app-secret

Example output excerpt:

Name:         app-secret
Namespace:    default
Labels:       <none>
Annotations:  <none>

Type:  Opaque

Data
====
DB_Host:       5 bytes
DB_Password:   6 bytes
DB_User:       4 bytes

Get the Secret YAML (values remain base64-encoded):

kubectl get secret app-secret -o yaml

Decode base64 back to plain text:

echo 'bXlzcWw=' | base64 --decode
# outputs: mysql

(Adjust the decode flag for your platform: GNU coreutils use --decode or -d; macOS may use -D.)

Injecting Secrets into Pods

Secrets can be exposed to containers in two common ways:

Environment variables (single keys or all keys at once).
Mounted as files via a secret volume (each key becomes a file with the decoded content).

Example: inject all Secret keys as environment variables using envFrom:

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: app-container
    image: your-image:latest
    envFrom:
      - secretRef:
          name: app-secret
  restartPolicy: Never

Each key in app-secret becomes an environment variable inside the container (e.g., DB_Host, DB_User, DB_Password). Example: mount the Secret as files inside a volume:

apiVersion: v1
kind: Pod
metadata:
  name: app-pod-with-secret-volume
spec:
  containers:
  - name: app-container
    image: your-image:latest
    volumeMounts:
    - name: app-secret-volume
      mountPath: /opt/app-secret-volumes
      readOnly: true
  volumes:
  - name: app-secret-volume
    secret:
      secretName: app-secret
  restartPolicy: Never

When mounted as a volume, each key becomes a file in the mount directory:

$ ls /opt/app-secret-volumes
DB_Host  DB_Password  DB_User

$ cat /opt/app-secret-volumes/DB_Password
paswrd

Quick reference table

Action	Command / YAML
Create secret from literals	`kubectl create secret generic app-secret --from-literal=DB_Password=paswrd`
Create secret from file	`kubectl create secret generic app-secret --from-file=app_secret.properties`
Apply declarative secret	`kubectl apply -f secret-data.yaml`
List secrets	`kubectl get secrets`
Describe secret	`kubectl describe secret app-secret`
Get YAML (base64 values)	`kubectl get secret app-secret -o yaml`
Decode a value	`echo 'bXlzcWw=' \| base64 --decode`

Best practices and security considerations

Do not store plaintext credentials in ConfigMaps.
Treat base64 as encoding, not encryption—enable encryption at rest for Secrets on the cluster.
Restrict Secrets access using RBAC policies.
Consider integrating with an external secrets manager (HashiCorp Vault, AWS KMS/GCP KMS/Azure Key Vault) for higher assurance.

Remember: base64 encoding is not encryption. For production workloads, enable encryption at rest for Secrets, restrict access via RBAC, and consider integrating with an external secrets manager or KMS for better security.

Links and references

Kubernetes Secrets documentation: https://kubernetes.io/docs/concepts/configuration/secret/
Kubernetes ConfigMap documentation: https://kubernetes.io/docs/concepts/configuration/configmap/
Best practices for secret management: https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/

Introduction

Core Concepts

Scheduling

Logging & Monitoring

Application Lifecycle Management

Cluster Maintenance

Security

Storage

Networking

Design and Install a Kubernetes Cluster

Install "Kubernetes the kubeadm way"

Troubleshooting

Helm Basics (2025 Updates)

Kustomize Basics (2025 Updates)

Other Topics

Mock Exams

Overview

Example application: what not to do

Move non-sensitive configuration to ConfigMaps

Creating Secrets

Declarative creation requires base64-encoded values

Inspecting Secrets

Injecting Secrets into Pods

Best practices and security considerations

Watch Video

Practice Lab

​Overview

​Example application: what not to do

​Move non-sensitive configuration to ConfigMaps

​Creating Secrets

​Declarative creation requires base64-encoded values

​Inspecting Secrets

​Injecting Secrets into Pods

​Best practices and security considerations

Watch Video

Practice Lab

Overview

Example application: what not to do

Move non-sensitive configuration to ConfigMaps

Creating Secrets

Declarative creation requires base64-encoded values

Inspecting Secrets

Injecting Secrets into Pods

Best practices and security considerations