---
title: "Kubernetes Secrets Management: 5 Best Practices You Need to Know"
published: true
description: "Learn how to properly secure secrets in Kubernetes with encryption at rest, external secret managers, RBAC, and more practical tips."
tags: kubernetes, devops, security, cloudnative
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/your-cover-image.png
---
Managing secrets in Kubernetes can be tricky. Hard-coded credentials, exposed environment variables, and insecure ConfigMaps are common pitfalls that can compromise your entire infrastructure. Here's how to do it right.
## The Problem
By default, Kubernetes secrets are just base64-encoded (not encrypted!) and stored in etcd. Anyone with cluster access can decode them instantly:
bash
kubectl get secret my-secret -o jsonpath='{.data.password}' | base64 --decode
Not exactly secure, right?
## 5 Essential Best Practices
### 1. Enable Encryption at Rest
Configure your Kubernetes cluster to encrypt secrets in etcd:
yaml
encryption-config.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets providers:
- aescbc: keys: - name: key1 secret:
- identity: {}
Apply this to your API server with the `--encryption-provider-config` flag.
### 2. Use External Secrets Operators
Integrate with cloud-native secret managers like AWS Secrets Manager, Azure Key Vault, or HashiCorp Vault:
yaml
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: database-credentials
spec:
refreshInterval: 1h
secretStoreRef:
name: aws-secrets-manager
kind: SecretStore
target:
name: db-secret
data:
- secretKey: password
remoteRef:
key: prod/database/password
This syncs secrets from your vault into Kubernetes automatically.
### 3. Implement RBAC Properly
Restrict who can read secrets with Role-Based Access Control:
yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: production
name: secret-reader
rules:
- apiGroups: [""] resources: ["secrets"] resourceNames: ["db-credentials"] verbs: ["get"]
Never give blanket `secrets` access across namespaces.
### 4. Use Sealed Secrets for GitOps
Store encrypted secrets in Git safely using Sealed Secrets:
bash
Encrypt a secret
kubectl create secret generic mysecret \
--from-literal=password=mypassword \
--dry-run=client -o yaml | \
kubeseal -o yaml > sealed-secret.yaml
Safe to commit to Git
git add sealed-secret.yaml
Only your cluster can decrypt these sealed secrets.
### 5. Rotate Secrets Regularly
Automate secret rotation with tools like cert-manager for certificates or custom CronJobs:
yaml
apiVersion: batch/v1
kind: CronJob
metadata:
name: rotate-api-keys
spec:
schedule: "0 2 * * 0" # Weekly at 2 AM
jobTemplate:
spec:
template:
spec:
containers:
- name: rotator
image: my-secret-rotator:latest
env:
- name: SECRET_NAME
value: "api-credentials"
restartPolicy: OnFailure
## Quick Security Checklist
- β
Enable encryption at rest
- β
Use external secret managers
- β
Implement strict RBAC
- β
Never commit secrets to Git (use Sealed Secrets)
- β
Rotate secrets regularly
- β
Audit secret access logs
- β
Use service accounts with minimal permissions
- β
Scan images for exposed secrets
## Cloud-Specific Tips
**AWS EKS**: Use IAM Roles for Service Accounts (IRSA) to avoid storing AWS credentials entirely.
**Azure AKS**: Leverage Azure Key Vault Provider for Secrets Store CSI Driver.
**GCP GKE**: Use Workload Identity with Secret Manager integration.
## Conclusion
Kubernetes secrets management doesn't have to be complicated. Start with encryption at rest, integrate an external secrets manager, and implement proper RBAC. Your security team (and your future self) will thank you.
---
**What's your approach to managing secrets in Kubernetes? Share your tips in the comments!** π
Top comments (0)