In our Kubernetes (K8s) clusters, sensitive data is like hidden treasure. It includes passwords, API tokens, database credentials, and private keys. This data allows our systems to talk to each other securely. If it falls into the wrong hands, attackers can unlock our backend systems, view private data, or even control our cluster.
In this post, we’ll review the Attack Tree of Accessing Sensitive Information in Kubernetes, provided by the CNCF and we’ll use to understand where sensitive information might be stored in our K8s, how an attacker could try to get access to and how to protect our K8s environments from that to happen.
Where is the Sensitive Data in K8s?
We store this sensitive data in several places:- In Kubernetes Secrets
- In Kubernetes ConfigMaps
- In the etcd store
- Inside container images
- In Pod/Deployment Definitions (yaml files)
- In application logs
- On persistent volumes
- In memory or environment variables
How Attackers Try to Access Sensitive Data
Same as we know where our sensitive information in our K8s clusters is, attackers know it as well. With that, these are some of the approaches an attacker could take to break into our system and steal that info:
Reading Secrets and ConfigMaps
Kubernetes usesetcd to store its data. It’s like the cluster’s brain. If an attacker gets access to etcd, they might read secrets directly—especially if they’re not encrypted. Secrets may also be exposed if a pod is compromised. Why? Because Kubernetes often mounts secrets inside pods. If one pod is taken over, its secrets go with it.Targeting Kubelets
Kubelets are agents on each node. They manage pods and share data between the node and the cluster. If a kubelet is attacked, an attacker can pull pod specs, logs, and even mounted secrets.Misconfigured RBAC
RBAC stands for Role-Based Access Control. It decides what a pod or user can do. If we misconfigure RBAC, attackers could gain powerful permissions. For example, if a pod has permission to read secrets, an attacker can use that pod to grab credentials for backend systems.Exploiting Container Images
Images may contain hardcoded secrets, backdoors, or old vulnerabilities. If our container registry isn’t protected, attackers can download these images and extract sensitive information.Reading Application Logs
Logs help us debug issues, but they can also leak secrets. Some apps write tokens, credentials, or personal data into logs. If attackers get into our containers, they can read these logs. Worse, they might change logging settings to redirect logs somewhere they can access.Mounting Persistent Volumes
Data in Kubernetes doesn’t always disappear with pods. Persistent volumes keep it safe between restarts. But attackers can abuse this. If they already control a pod, they can mount volumes and steal the data. Or they might access volumes by reaching the containers that use them.Dumping Host Memory
If a container is allowed to useHostPID, it can see other processes on the node. From there, attackers might dump memory from the host and find sensitive data stored in running memory.Reading Environment Variables
Sometimes, developers store secrets in environment variables. If an attacker gets into a pod, they can list those variables and steal tokens or passwords.Eavesdrop on Network Traffic
From a compromised pod, an attacker can- Use
tcpdump,wireshark, or similar tools to sniff traffic on the pod's interface. - If privileged, they can access the host network namespace and sniff traffic between other pods or nodes.
tcpdump -i eth0 port 80How We Can Protect Our Sensitive Data
Now that we know where our sensitive data might be located and the different paths and attack vectors an attacker coulld use get access to that info, let’s see how we can close these paths. Here's how:- Ensure RBAC permissions are correctly set up. This way we ensure that service accounts in our cluster get access exclusively to the resources they need and cannot exploit excessive permissions in a pod or container
- Encrypt Secrets in etcd - Always turn on encryption at rest. Kubernetes supports this. Use strong encryption keys.
- Harden Kubelets - Secure kubelet ports. Use authentication and authorization. Disable read-only ports.
- Avoid Hardcoding Secrets - Never bake credentials into images. Use Kubernetes Secrets or external secret managers.
- Protect Your Container Registry - Use authentication to control who can pull images. Scan images for vulnerabilities.
- Sanitize Logs - Never log secrets. Use log redaction if your app supports it. Audit your logs regularly.
- Secure Persistent Volumes - Set correct file permissions. Use encryption. Don’t let untrusted pods mount shared volumes.
- Disable HostPID When Not Needed
Don’t allow pods to use host-level process IDs unless required. This reduces memory exposure. - Avoid Storing Secrets in Env Vars
Prefer mounting secrets as files. If you must use environment variables, limit who can see them. - Encrypt network traffic - If communication between our services, pods and nodes within our cluster is not encrypted an attacker could intercept this communication and get access to sensitive data such as credentials, tokens.. which might lead to unauthorised access and data breaches. We must encrypt communication within our cluster between components