CKS — Secrets Management
Chapter 8 — Secrets Management
CKS Exam Domain: Minimize Microservice Vulnerabilities (20%)
Secrets are one of the most critical attack targets in any Kubernetes cluster. A compromised Secret can hand an attacker database credentials, API keys, TLS certificates, or cloud IAM tokens — everything needed to pivot from a single Pod breach to a full infrastructure takeover.
By default, Kubernetes Secrets are base64-encoded, not encrypted. They sit in etcd in plaintext. Anyone with direct etcd access or overly broad RBAC can read every credential in the cluster. The CKS exam expects you to understand this risk and know how to mitigate it at every layer.
What This Chapter Covers
| # | Topic | Focus Area | Link |
|---|---|---|---|
| 1 | Kubernetes Secrets Deep Dive | Secret types, consumption patterns, risks, immutable secrets | Go → |
| 2 | Encryption at Rest | EncryptionConfiguration, providers, API server flags, verification | Go → |
| 3 | External Secret Stores | Vault, AWS Secrets Manager, Secrets Store CSI Driver, ESO | Go → |
| 4 | Secret Rotation | Manual rotation, automated strategies, Pod restart, Reloader | Go → |
| 5 | Secret Access Control | RBAC for secrets, audit logging, namespace isolation | Go → |
| 6 | Hands-On Lab | End-to-end exercises covering all secrets management topics | Go → |
Why Secrets Management Is CKS-Critical
The CKS exam includes encryption at rest as a must-know topic. You may be asked to:
- Configure
EncryptionConfigurationand wire it to the API server - Verify that Secrets in etcd are actually encrypted
- Encrypt all existing Secrets after enabling encryption
- Restrict RBAC so that only specific ServiceAccounts can read specific Secrets
- Choose volume mounts over environment variables for Secret consumption
Threat Landscape
┌────────────────────────────────────────────────────────┐
│ Secret Threats │
│ │
│ 1. etcd Direct Access │
│ └── Secrets stored base64-encoded (NOT encrypted) │
│ └── Anyone with etcd certs can read everything │
│ │
│ 2. RBAC Overpermission │
│ └── `list` + `watch` on secrets = read ALL secrets │
│ └── cluster-admin bindings expose everything │
│ │
│ 3. Environment Variable Leaks │
│ └── `kubectl describe pod` shows env vars │
│ └── Crash dumps, logging frameworks expose env │
│ │
│ 4. Image Pulls / Registry Creds │
│ └── imagePullSecrets visible in Pod spec │
│ │
│ 5. Logging & Monitoring │
│ └── Secrets injected into logs by accident │
│ └── Application debug endpoints dump env │
└────────────────────────────────────────────────────────┘
Exam Relevance
This chapter directly maps to the Minimize Microservice Vulnerabilities domain (20% of the exam):
- Encrypt Secrets at rest — configure EncryptionConfiguration, apply to API server
- Use RBAC to restrict Secret access — namespace-scoped Roles, no wildcard access
- Consume Secrets securely — prefer volume mounts over env vars
- Understand Secret types — Opaque, TLS, dockerconfigjson, service-account-token
Exam Tip: Encryption at rest is one of the highest-yield topics for CKS. The YAML for EncryptionConfiguration and the API server flag
--encryption-provider-configcome up frequently. Know them by heart.
Prerequisites
You should already be comfortable with:
- Creating and managing Kubernetes Secrets (
kubectl create secret) - RBAC fundamentals (Roles, ClusterRoles, RoleBindings)
- API server static Pod manifests (
/etc/kubernetes/manifests/) - Using
etcdctlfor basic etcd operations - Base64 encoding/decoding
| Previous | Up | Next |
|---|---|---|
| OPA Gatekeeper Lab | CKS Home | Kubernetes Secrets Deep Dive |