Introduction
In modern cloud-native applications running on Kubernetes, managing sensitive information such as database credentials, API keys, access tokens, and connection strings is a critical responsibility. Mishandling such data can expose systems to security vulnerabilities, unauthorized access, and compliance risks.
A common but risky practice is embedding secrets directly into application code or configuration files. This approach not only increases exposure but also makes rotation and management difficult.
Kubernetes provides a dedicated mechanism called Secrets, designed specifically to handle confidential data in a controlled and secure manner.
This guide walks through how to manage secrets securely in Kubernetes using a structured approach, practical configurations, and production-level best practices.
What are Kubernetes Secrets?
Kubernetes Secrets are objects used to store and manage sensitive data separately from application code.
They are commonly used for:
Database usernames and passwords
API tokens
SSH keys
TLS certificates
Unlike ConfigMaps, which store non-sensitive configuration, Secrets are intended specifically for confidential data.
Why Secure Secret Management Matters
Improper handling of secrets can lead to:
Data breaches
Unauthorized system access
Compromised applications
For example, exposing a database password in a public repository can allow attackers to directly access and manipulate your database.
Secure secret management ensures:
Controlled access
Better compliance with security standards
Reduced attack surface
Step 1: Create a Kubernetes Secret
kubectl create secret generic db-secret \
--from-literal=username=admin \
--from-literal=password=MyStrongPassword
Explanation
kubectl create secret generic: Creates a generic secret objectdb-secret: Name of the secret--from-literal: Defines key-value pairs directly
This command stores the credentials inside the Kubernetes cluster.
Step 2: Inspect the Secret
kubectl get secrets
kubectl describe secret db-secret
Explanation
get secrets: Lists all secrets in the namespacedescribe secret: Displays detailed information
Note: Values are base64-encoded, not encrypted by default.
Step 3: Inject Secrets as Environment Variables
apiVersion: v1
kind: Pod
metadata:
name: app-pod
spec:
containers:
- name: app-container
image: nginx
env:
- name: DB_USERNAME
valueFrom:
secretKeyRef:
name: db-secret
key: username
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: db-secret
key: password
Explanation
env: Defines environment variables inside the containersecretKeyRef: References a key from a Kubernetes Secretname: Secret namekey: Specific value inside the secret
This approach allows applications to access secrets without hardcoding them.
Step 4: Mount Secrets as Volumes
apiVersion: v1
kind: Pod
metadata:
name: app-pod-volume
spec:
containers:
- name: app-container
image: nginx
volumeMounts:
- name: secret-volume
mountPath: "/etc/secrets"
readOnly: true
volumes:
- name: secret-volume
secret:
secretName: db-secret
Join the conversation! Your thoughts help the community grow.