Kubernetes and Cloud Native Associate (KCNA)Cloud Native SecurityMedium
A security auditor is reviewing a Kubernetes cluster's secrets management strategy. They find that all sensitive data, such as API keys and database credentials, are stored directly in Kubernetes Secrets objects. While these are base64 encoded, the auditor highlights a significant security weakness regarding their protection at rest within the `etcd` datastore. What is the primary concern the auditor is likely raising?
- AImproper Role-Based Access Control (RBAC) for Secrets.
- BInsufficient logging and auditing of Secret access.
- CLack of network encryption for Secrets traffic.
- DSecrets are not encrypted at rest in `etcd` by default.
Show answer & explanationAnswer & explanation
Correct answer: D. Secrets are not encrypted at rest in `etcd` by default.
By default, Kubernetes Secrets stored in `etcd` are only base64 encoded, not encrypted. This means anyone with direct access to `etcd` can easily decode and read the sensitive data, posing a significant security risk for data at rest.
Why the other options are wrong
- A. While important, RBAC controls 'who' can access Secrets via the API, not 'how' they are protected if `etcd` itself is compromised.
- B. Logging and auditing track access, but do not prevent direct reading of unencrypted Secrets from `etcd`.
- C. Network encryption (TLS) typically protects Secrets traffic in transit, but the concern is 'at rest' in `etcd`.
Secrets Encryption at Rest (etcd)
The practice of encrypting sensitive data stored in Kubernetes Secrets objects within the `etcd` key-value store, preventing unauthorized access even if `etcd` itself is compromised.
- By default, Secrets in `etcd` are only base64 encoded, not encrypted.
- Requires explicit configuration (e.g., using an EncryptionConfiguration) to encrypt.
- Protects sensitive data from adversaries with direct `etcd` access.
Memory trick: Etcd's secret is not safe without encryption.