Common Security Issues in Kubernetes Clusters -- Part 1

Photo by Sigmund on Unsplash

Common Security Issues in Kubernetes Clusters -- Part 1

Kubernetes shines at the orchestration of thousands of containers but the security of these assets is one of the biggest concern of enterprises today

54% of enterprises mentioned Security as their biggest challenge in Kubernetes. Almost 7 out of 10 have limited or lack resources to manage security as Kubernetes has a steep learning curve. Now it is not only the Kubernetes lacking native security scanning ability rather any vulnerability in an application running on the cluster may lead to a bigger threat. Here are a few hacks from the past:

Now that we know that a single container vulnerability may compromise the overall security of the cluster, let us review a few aspects.

Public Nodes

A public cluster is one whose Nodes are accessible from the internet, technically they have one or more networks configured with ExternalIP. You can test it using the following command

kubectl get node <node-name> -o jsonpath='{.status.addresses}' | grep ExternalIP

Replace with your node name in the cluster. following the sample output

Screen Shot 2022-10-10 at 9.34.50 AM.png

If any of your nodes have an ExternalIP then it is exposed, which means all your containers/pods running on this node are also exposed to the public. It is highly recommended to keep your nodes private and route the outgoing traffic using a Cloud NAT.

Public Kubernetes Dashboard

Kubernetes Dashboard is an open-source deployment used to manage and monitor cluster deployments and other objects. It is available on all clusters and can be deployed or installed with a few simple commands. Here is how you can also deploy it on your cluster:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.6.1/aio/deploy/recommended.yaml

Once installed you can proxy it to access it from your remote machine (machine with cluster access) using kubectl proxy command. Now you can access your dashboard using the following url: http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

Note: The kubeconfig authentication method does not support external identity providers or X.509 certificate-based authentication. The UI can only be accessed from the machine where the command is executed. See kubectl proxy --help for more options.

Now, this is your standard access method, if one of your vulnerable (or compromised) containers has the access to your dashboard then the hacker will have access to the whole Kubernetes cluster.

Exposed Observability Platform

If you are using Prometheus, Grafana, or Splunk, chances are that you are exposing them by using an external load balancer. These and other observability platforms are often used to monitor and prevent performance, security, and other issues in a cluster. Once exposed to public traffic either through an ingress or through a vulnerable (or compromised) container may lead to a brute force attack. A hacker can take control of the whole cluster once getting access to such a platform.

Privileged Container

A privileged container is one that has full access to itself and through the reverse shell technique it can also get full control over its encapsulating Node. Full access to a node exposes all the images stored on it and it may lead to access to other nodes in the network exposing all available resource objects on the cluster. Hackers may deploy a cron job or hijack the resources of the nodes without even letting it be noticed from the Kubernetes platform.

Conclusion

In this part, I have just scratched the surface and mentioned some of the most common security vulnerabilities. An attacker can use impact techniques to destroy, abuse, or disrupt the normal behavior of an environment. I will discuss some more security vulnerabilities in my upcoming articles.