With the widespread adoption and popularity of Kubernetes, Kubernetes security education cannot be more relevant. Despite the popularity, Kubernetes security didn't catch on. In this blog, I introduce Kubernetes, however, this blog is not an introduction to K8s, I mainly explore the security challenges in Kubernetes and the principles of Kubernetes security. Read on!
Introduction
Kubernetes is an application orchestrator.
For the most part, it orchestrates containerized cloud-native apps.
To understand this definition we have to familiarize ourselves with each new word in it.
Orchestrator
An orchestrator deploys an app and responds to changes. For example, Kubernetes can:
Deploy your application
Scaling up and down based on demand
self-heal it when it breaks.
perform zero downtime rolling updates and rollbacks
And the best part is after you have initially set up you don't have to manually intervene and let Kubernetes do this all on its own.
A Containerized App
A containerized app is an app that runs in containers.
While Kubernetes can also orchestrate VMs and servers, containers is it's main use case.
A Cloud Native App
A cloud native app is an app that is designed to meet cloud-like demands of autoscaling, self-healing, rolling updates, rollbacks and more.
A Microservices App
A microservices app is built from a lot of independent small specialized apps. These independent apps are called Microservices. These are typically owned by separate teams and each microservice can be modified, and scaled without disrupting other parts. Each microservice runs as a separate container.
A more familiar Definition
Kubernetes dynamically deploys and manages applications that are packaged and run as containers and built in ways that allow them to support features like autoscaling, self-healing, rolling updates and rollbacks etc.
Etymology
The name Kubernetes (koo-ber-net-eez) comes from the Greek word meaning Helmsman – the person who steers a seafaring ship. This theme is reflected in the logo, which is the wheel (helm control) of a ship.
Some of the people involved in the creation of Kubernetes wanted to call it Seven of Nine. If you know your Star Trek, you’ll know that Seven of Nine is a Borg drone rescued by the crew of the USS Voyager under the command of Captain Kathryn Janeway. Sadly, copyright laws prevented it from being called Seven of Nine. So the creators gave the logo seven spokes as a tip-of-the-hat to Seven of Nine.
One last thing about the name before moving on. You’ll often see it shortened to “K8s” (pronounced “kates”). The number 8 replaces the 8 characters between the “K” and the “s” and is why people sometimes joke that Kubernetes has a girlfriend called Kate.
A quick Analogy
Consider the process of sending goods via courier. What we do is package our courier according to the standard packaging and label the courier. We don't need to specify which plane to use, which highway to use, who should drive the trucks, etc. The only thing we should do is package it and label it. In the same way, you only need to package and give a Kubernetes manifest and Kubernetes takes care of everything else.
A Little History
Google created the Kubernetes platform from its Borg and Omega, the in-house technology used to run it's Search and Gmail services as containers at an extreme scale long before Docker popularized containers, to abstract the underlying infrastructure of AWS and donated it as open source project to CNCF in 2014.
Kubernetes enables two things Google and the rest of the industry need.
It abstracts underlying infrastructure such as AWS It makes it easy to move applications on and off clouds
Understanding the Kubernetes Ecosystem
Now, let us take out out big guns!
A Kubernetes cluster is made up of a control plane and a data plane.
Control plane: Manages Kubernetes clusters and the workloads running on them. It includes components such as API server, Scheduler, and controller manager.
Data Plane: The Data Plane is responsible for running workloads. It consists of worker nodes.
The worker nodes host the Pods that are the components of the application workload.
(Picture courtesy: Kubernetes)
Components of Control Plane
The components of the control plane make important decisions about the cluster, respond to events of the cluster.
The core components of the control plane are:
kube-apiserver
kube-apiserver is front end for Kubernetes control plane. It exposes the Kubernetes API so users and other components can interact with it.
Among other things, kube-apiserver is responsible for:
Providing front end for cluster's shared state, through which all other components interact.
Authorizing and authenticating requests.
Providing a REST API for users to interact with the cluster.
The kube-apiserver is a critical component of Kubernetes and needs to be highly available. This is achieved through deploying it multiple times in a cluster and a load balancer is used to distribute traffic between the instances.
etcd
etcd is a distributed key-value store that is used by Kubernetes to store its state. It is a highly available and consistent store that can be used to store any kind of data, but it is well-suited for storing configuration data and metadata.
etcd stores the following information:
current state of the cluster.
desired state of the cluster.
The history of the cluster, including all the changes that have been made to the cluster.
Like kube-apiserver, etcd also needs to be highly available so it is typically deployed multiple times in the cluster and a load balancer is used to manage traffic between instances.
kube-scheduler
kube-scheduler is a component of the Kubernetes control plane that is responsible for scheduling pods to nodes.
kube-scheduler works as follows:
It maintains a list of all unscheduled pods in the cluster.
It periodically queries the Kubernetes API server to get a list of all available nodes.
It selects a node that meets the pod's resource requirements and other constraints,
It binds the pod to the scheduled node and updates the list of available nodes and unscheduled pods.
kube-controller-manager
kube-controller-manager is a component of Kubernetes cluster control plane that is responsible for running a number of controllers. Controllers are control loops that continuously evaluate the state of the cluster and make changes to move towards the desired state.
Some of the controllers run by kube-controller-manager are the Replication controller, Daemonset controller, Deployment controller, etc.
kube-controller-manager also needs to be highly available so it is typically deployed multiple times in the cluster and load balancer is used to manage traffic between instances.
cloud-controller-manager
cloud-controller-manager is responsible for managing cloud specific resources such as load balancers, persistent volumes, etc.
cloud-controller-manager manages a number of cloud specific controllers. Some of the cloud-specific controllers that are implemented by the cloud-controller-manager include: Load balancer controller, Persistent volume controller, Node controller, Route controller, etc.
cloud-controller-manager also needs to be highly available so it is typically deployed multiple times in the cluster and load balancer is used to manage traffic between instances.
Components of Data Plane
If control plane is the conductor, data plane is the orchestra.
Control plane tells data plane what to do and data plane carries out the instructions.
The components that make up data plane are:
Pods
Pods are the smallest deployable units in Kubernetes. They contain one or more containers, as well as shared resources such as networking and storage.
Pods are isolated from each other, but they can communicate with each other through Kubernetes networking. Pods can also access shared resources on the node, such as storage and networking.
Pods are scheduled to nodes by the Kubernetes control plane.
Once a pod is scheduled to a node, the kubelet on the node creates the pod and runs the containers inside it. The kubelet monitors the pod and restarts it if it fails.
Nodes
Nodes are the physical or virtual machines that run the Kubernetes workloads. They provide the compute, storage, and networking resources for the pods that run on them.
When a node is added to the kubernetes cluster, the control plane will register the node and add it to the list of available nodes.
Each node is identified by a unique identifier by the control plane. Control plane schedules pods to nodes based on availability and capability of nodes. If a node fails, control plane schedules the pod to available nodes.
Nodes can also be configured to have different resource requirements. For example, some nodes may have more CPU resources than others, while other nodes may have more storage resources than others.
Nodes can be configured to have different roles. Some nodes may be assigned to run critical workloads while other nodes may be dedicated to less critical workloads.
Nodes are the foundation of a Kubernetes cluster.
Kubelet
Kubelet is an agent that runs of each node in a Kubernetes cluster. It is responsible for managing the pods on that node.
Kubelet is also responsible for collecting metrics from the node and reporting them to the control plane. This information is used by control plane to schedule Pods to nodes.
Kubelet is the critical component of Kubernetes and it must be running on each node.
Container runtime
A container runtime is a software responsible for running containers.
Container runtimes work by creating a lightweight virtual machine for each container. This virtual machine is isolated from other containers and the host operating system, which helps to improve security and reliability.
Container runtimes also provide resource management for containers. This includes resources such as CPU and memory limits, which makes sure that containers do not consume too many resources and affect the performance of other containers or the host operating system.
Some popular container runtimes include:
Docker
containerd
Podman
rkt
Container runtimes are a critical component of container orchestration platforms such as Kubernetes. Kubernetes uses container runtimes to run the pods that are scheduled to nodes in the cluster.
Container network
A container network is a network that connects containers to each other and to the outside world. It provides a way for containers to communicate with each other and to access external resources, such as databases and web services.
The container networking plugin is responsible for creating and managing the container network.
Some popular container networking plugins include:
Flannel
Calico
Weave Net
CNI
Challenges in Kubernetes Security
Although kubernetes is being adopted widely, security investment hasn't kept up, combined with ever-present skills gap, security incidents can have devastating consequences.
Security incidents can slow down the application development and deployment.
Kubernetes and container security issues can also result in revenue, customer loss, employee termination and additional impacts on business operations.
Common challenges and Risks
In a Kubernetes cluster, pods can communicate with each other freely by default unless a relevant security policy prevents it. This means a single pod that is breached can be used to access other pods in the cluster.
Dynamic nature of containers makes it difficult to identify misconfigurations and maintain a consistent security posture. Misconfigurations are human errors.
Kubernetes clusters are often complex and distributed, making it difficult to secure all of the entry points and potential vulnerabilities. Attackers may be able to gain unauthorized access to Kubernetes clusters by exploiting vulnerabilities in software or hardware, or by using compromised credentials.
Kubernetes clusters often store sensitive data, such as customer information, financial data, and intellectual property. Attackers who gain access to Kubernetes clusters may be able to steal this data or modify it.
Kubernetes clusters are susceptible to DoS attacks, which can make them unavailable to legitimate users. DoS attacks can be carried out by flooding Kubernetes clusters with traffic or exploiting vulnerabilities in software or hardware.
Kubernetes clusters are susceptible to malware infections, which can damage systems, steal data, or disrupt operations. Malware can be spread through a variety of methods, such as phishing attacks, email attachments, and removable media.
Security Principles in Kubernetes
Kubernetes security principles are a set of best practices that can be used to improve the security of Kubernetes clusters and applications. They are based on:
Defense in Depth
Defense in depth (DiD) is a security strategy that uses multiple layers of security controls to protect an information system. The goal of DiD is to make it more difficult for an attacker to successfully exploit a vulnerability and gain access to the system. If one layer of security is compromised, the other layers will hopefully prevent the attacker from gaining further access.
The four layers, 4 C's of Cloud Native security are Cloud, Clusters, Containers, and Code.
(Picture courtesy: Kubernetes)
Each layer builds on top of next outermost layer. You cannot address base level security concerns by only focusing on the code.
Lease Privilege
Kubernetes components and applications should be given only the permissions that they need to function. This helps to reduce the attack surface and limit the damage that can be done if an attacker is able to gain access to the cluster.
Security by design
Kubernetes security should be considered from the beginning of the application development process. In this way, applications are designed with security in mind.
Specific examples of how Kubernetes security principles can be implemented:
Role-based Access Controll
Network Policies
Audit logging to track security activity.
Some Additional Tips:
Keep the Kubernetes software up to date
Scan container images for vulnerabilities.
Train employees on Kubernetes security.
Use container run time security solution. Some examples are:
Aqua Security
CloudGuard Workload Protection
Falco
Sysdig Secure
Qualys Container Security
Snyk Container
Anchore Engine
Clair
I hope you found this blog informative and helpful. This blog is first in the series blogs I'll be writing. If you like this considering liking the blog and subscribing to my newsletter.