1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
|
# Kubernetes Secret Guide: Secure Storage and Management of Sensitive Data
Kubernetes **Secrets** allow you to store and manage sensitive information like passwords, API keys, and TLS certificates securely inside your cluster.
Rather than embedding these values directly into your application code or Pod specs, you can manage them as separate resources and control their access with RBAC.
---
## Table of Contents
{% toc %}
---
## 1. What Is a Secret?
A **Secret** in Kubernetes stores **confidential key-value pairs**.
These values are **Base64-encoded** and stored in `etcd`. You can inject Secrets into Pods as **environment variables** or **mounted files**.
> Important: Base64 is not encryption — it’s only encoding. To protect against data exposure, you should enable **encryption at rest** in Kubernetes.
---
## 2. Why Use Secrets Instead of Hardcoding?
Hardcoding sensitive data in Deployment YAML or application code has serious drawbacks:
* **Security risk**: Anyone with access to your code or manifests can see credentials.
* **Difficult rotation**: Changing credentials requires editing multiple files.
* **Audit challenges**: No clear record of who accessed or changed secrets.
Secrets address these issues by providing:
* Centralized sensitive data management.
* Controlled access with **RBAC**.
* Separation of configuration from code.
---
## 3. Secret vs ConfigMap
| Feature | ConfigMap | Secret |
| ----------- | --------------------------- | --------------------------------------- |
| Purpose | Non-sensitive configuration | Sensitive data |
| Storage | Plain text | Base64 encoded |
| Security | Low | Higher (can enable encryption) |
| Example Use | App settings, URLs | Passwords, API tokens, TLS certificates |
---
## 4. Key Features of Secrets
* **Centralized secure storage** for sensitive values.
* **Multiple injection options**: Environment variables or mounted volumes.
* **RBAC integration** to control who can access secrets.
* **Support for custom types** for specialized use cases.
* **Extensibility**: Works with tools like HashiCorp Vault, Sealed Secrets, or External Secrets Operator.
---
## 5. Secret Types
| Type | Description | Use Case Example |
| -------------------------------- | --------------------------------- | -------------------------------- |
| `Opaque` | Default generic key-value pairs | DB credentials, API keys |
| `kubernetes.io/dockerconfigjson` | Docker registry authentication | Private image pulls |
| `kubernetes.io/tls` | TLS certificates and private keys | HTTPS services |
| Custom | For plugins/controllers | Sealed Secrets, External Secrets |
---
## 6. Creating Secrets
### 1) Using YAML
```yaml
apiVersion: v1
kind: Secret
metadata:
name: db-secret
type: Opaque
data:
username: YWRtaW4= # "admin" Base64 encoded
password: c2VjdXJlcGFzcw== # "securepass" Base64 encoded
|
Base64 encoding:
1
| echo -n "admin" | base64
|
2) Using CLI#
1
2
3
| kubectl create secret generic db-secret \
--from-literal=username=admin \
--from-literal=password=securepass
|
3) From Files#
1
2
3
| kubectl create secret generic db-secret \
--from-file=username.txt \
--from-file=password.txt
|
7. Using Secrets in Pods#
As Environment Variables#
1
2
3
4
5
6
| env:
- name: DB_USER
valueFrom:
secretKeyRef:
name: db-secret
key: username
|
As Mounted Volumes#
1
2
3
4
| volumes:
- name: secret-vol
secret:
secretName: db-secret
|
This makes /etc/secret-vol/username available inside the container.
8. Production Security Patterns#
When running in production, managing Secrets securely is critical.
Recommended Practices:
- Limit RBAC access to Secrets — avoid cluster-wide read permissions.
- Enable etcd encryption for secrets at rest.
- Use TLS for all API server communications.
- Regularly rotate credentials stored in Secrets.
- Avoid committing unencrypted Secrets to Git.
- Use Sealed Secrets or SOPS for GitOps workflows.
- Audit
kubectl get secret usage in logs to detect unauthorized access.
9. Real-World Use Cases#
- Database authentication: Store DB usernames and passwords securely.
- External API access: Inject API tokens as environment variables.
- TLS termination: Store certs and keys for Ingress controllers.
- Private registry authentication: Pull images from secured registries.
10. Operational Considerations#
- Secrets in environment variables remain in process memory — avoid dumping environment in logs.
- Volume-mounted Secrets update automatically when the Secret is updated.
- Environment variable-injected Secrets require Pod restarts to pick up changes.
- Secrets are namespaced — a Pod can only access Secrets in the same namespace.
11. Common Pitfalls#
- Mistaking encoding for encryption: Always enable encryption at rest.
- Exposing secrets in CI/CD logs: Mask secret values in build pipelines.
- Not rotating secrets: Stale credentials increase security risks.
- RBAC misconfigurations: Overly broad permissions can lead to leaks.
12. FAQ (Answer Engine Optimization)#
Q1. Are Secrets encrypted by default?
No — they are only Base64 encoded. Enable etcd encryption for strong security.
Q2. Will Secret updates automatically propagate to Pods?
- Environment variables: Require Pod restart.
- Volumes: Update automatically.
Q3. Can I store Secrets in Git?
Yes, but only if encrypted (e.g., Sealed Secrets or SOPS).
13. Summary Table#
| Topic | Summary |
|---|
| Purpose | Store sensitive data securely |
| Injection | Environment variables or volumes |
| Best Practice | Use RBAC, encryption, GitOps security tools |
| Key Difference | Secrets are for sensitive data; ConfigMaps are not |
14. Final Thoughts#
Secrets are one of the most important Kubernetes resources for maintaining security and compliance in modern applications.
Mastering how to create, inject, and secure them — while avoiding common pitfalls — ensures your workloads remain both functional and secure.