In this video, we get an overview of the Kubernetes attack surface through a fun demo of hacking a Kubernetes cluster.

Join our Slack community for FREE: https://kode.wiki/JoinOurSlackCommunity

Full Certified Kubernetes Application Developer (CKAD) course: https://kode.wiki/CKAD_YT

There are several areas that are vulnerable to attacks and that's what we'll go through in this lecture. Let's start with the cloud itself. The infrastructure that hosted the Kubernetes cluster wasn't properly secured and allowed access to the cluster's ports from anywhere. If network firewalls were in place, we could have prevented remote access from the attacker's system. This is the first C in cloud-native security. It refers to the security of the entire infrastructure that hosts the servers. This can be a private or public cloud, a data center that hosts physical machines, a co-location environment. We discuss this in more detail in the last section of the course where we talk about how to detect all stages of an attack, regardless of where it occurs and how it spreads.

Next comes cluster security. The attacker was easily able to gain access through the publicly accessible Docker daemon as well as the publicly accessible Kubernetes dashboard which was publicly accessible without proper authentication or authorization mechanisms. This could have been prevented if security best practices were followed in securing the Docker daemon, Kubernetes API as well as all the GUIs we use to manage the cluster such as the Kubernetes dashboard. We look at these in much more detail in the first section of the course where we talk about setting up and securing clusters. We will see how to secure the Docker daemon and Kubernetes dashboard as well as other best practices to follow such as using network policies and Ingress.

Next comes the container. The hacker could run any container, with no restrictions on the repository or tag. The attacker could run a container in privileged mode, which should have been prevented. The attacker could also install any application on it, with no restrictions. This could have been prevented if restrictions had been put in place to only run images from a secure internal repository and if running containers in privileged mode had been prohibited. And sandboxing made containers better isolated. We discuss these in the "Minimizing Microservices Vulnerabilities" section and the supply chain security sections of the course.

And finally, code. Code refers to the application code itself. Hardcoding applications with database credentials or passing critical information through environment variables, as well as exposing applications using TLS, are bad coding practices. This is mostly outside the scope of this course, but we cover some areas, such as securing critical information with secrets and vaults, enabling Metals encryption to secure pod-to-pod communication, etc.

To learn more about security in cloud-native computing and Kubernetes, take our Certified Kubernetes Security Specialist course. We go in-depth in each of these areas, understanding common vulnerabilities and security concerns in an environment and how we can protect our systems from attacks. The course is fully hands-on and includes lab activities to help you reinforce and retain what you've learned in the videos. This will also help you prepare for and pass the Certified Kubernetes Security Specialist exam.

Join our student community at cks.kodekloud.com

#HackingaKubernetesCluster #kodekloud

Please take the opportunity to connect with your friends and family and share this video with them if you find it useful.