This article explains Kubernetes secrets management, focusing on the main threat models for secrets at rest, in transit, and through API abuse, as well as how native Secret objects and external solutions address them. It also highlights practical security tradeoffs such as environment variables versus mounted files, RBAC limitations, etcd encryption, and risks like storing sensitive data in ConfigMaps. #Kubernetes #etcd #RBAC #RKE #ConfigMaps
Keypoints
- Secrets in Kubernetes are meant to protect sensitive data such as API keys and database credentials needed by applications and system components.
- The main threat categories are secrets at rest, secrets in transit, and attacks on APIs that provision secrets.
- Kubernetes Secret objects store data in etcd and can be mounted into Pods or exposed as environment variables, with mounted files generally being safer.
- Dedicated Secret objects are preferable to ConfigMaps because they signal sensitive intent and can be handled differently by logging and RBAC systems.
- Managed Kubernetes relies on the cloud service provider to secure etcd and related infrastructure, while unmanaged clusters must handle encryption and access control themselves.
- Any user or service account with list/watch access to secrets can effectively read the secret contents, and any pod creator in a namespace can access secrets in that namespace.
- External secrets solutions may offer better auditing, finer-grained access control, or hardware-backed encryption, but they add management overhead and cost.
MITRE Techniques
- [T1005] Data from Local System – An attacker may extract secrets by accessing the etcd host, node OS, physical disks, or backups (‘gaining access to the etcd host, the node OS, or physical disks and backups in order to extract information’).
- [T1552] Unsecured Credentials – The article describes secrets being stored and exposed through Kubernetes mechanisms, making credentials recoverable if access controls fail (‘secrets at rest’, ‘request the secrets directly’, ‘access any secret in that namespace’).
- [T1040] Network Sniffing – Secrets in transit could be intercepted by monitoring traffic between etcd, the API, and nodes (‘intercepting traffic as it flows between the database and nodes’).
- [T1557] Adversary-in-the-Middle – An attacker could position themselves between components to capture secret traffic (‘intercepting traffic as it flows between the database and nodes’).
- [T1190] Exploit Public-Facing Application – The article notes API abuse against Kubernetes and etcd interfaces to retrieve secrets (‘attacks on APIs that provision secrets’, ‘request the secrets directly’).
- [T1611] Escape to Host – An attacker with privileged shell access on a node may pull secrets from containers on that node (‘an attacker with privileged shell access to the underlying node can likely pull secrets from any container running on that node’).
- [T1068] Exploitation for Privilege Escalation – Creating arbitrary hostPath mounts can be used to reach other containers’ secret volumes (‘attackers with the ability to create arbitrary hostPath mounts can access the secret volumes of any other container’).
- [T1613] Container and Resource Discovery – Listing secrets with Kubernetes commands can reveal all secrets and their contents (‘kubectl get secrets -o yaml will show all the secrets and their contents’).
Indicators of Compromise
- [CVE] critical vulnerability reference – CVE in the RKE distribution associated with sensitive data being stored in a ConfigMap (‘a critical CVE in the RKE distribution of Kubernetes’).
- [Kubernetes object names] example manifests used in the article – my-api-secret, webapp
- [Kubernetes resource types] sensitive data storage and retrieval examples – Secret, ConfigMap, Deployment, etcd
- [Kubernetes commands] secret enumeration example – kubectl get secret SECRET, kubectl get secrets -o yaml
- [Data encoding example] sample secret value shown in base64 – aHVudGVyMg==
Read more: https://securitylabs.datadoghq.com/articles/kubernetes-security-fundamentals-part-8/