For the sake of brevity, this blog post will only go over the Kubernetes architecture components which are directly related to the common Kubernetes misconfigurations rather than being a comprehensive guide on Kubernetes. If you missed part 1, it can be found here: What is Kubernetes?.
Kube API Server: The Kube API server is the communications component of Kubernetes where it is responsible for validatingand processing incoming communication requests then passing it on to the relevant components. The Kube API server is also responsible for handling the authentication and authorisation components of Kubernetes. The Kube API Server performs the following actions when a request comes in:
1. Validates the request format
2. Authenticates the requester
3. Checks if the requester is authorised to make the change
4. Reads or writes to the etcd component
It is also worth noting that, other Kubernetes component are only supposed to communicate via the Kube API server and should not communicate directly with each other. Moreover, it is not responsible for storing and maintaining the database for the desired state nor is it responsible for enforcing the active state as those operations belong to other Kubernetes components.
Etcd: The etcd component is a distributed key-value database that acts as Kubernetes’ single source of truth. It stores the cluster configuration, resource definitions, and event history. In short, it stores everything the environment knows about itself. All reads and writes should flow exclusively through the Kube API Server, meaning that etcd should never be directly exposed. A compromised etcd gives an attacker complete visibility into the entire cluster.
Kubelets: The Kubelet is a local agent running on every node in the cluster and acts as the point of contact between the node andthe rest of the Kubernetes control mechanisms. It takes instructions from the Kube API Server detailing which pods pods should be running on its node, ensure those pods are started and kept healthy, and continuously reports the node’s status back to the API Server. A Kubelet exposes its own API endpoint, which can become a significant attack surface if left improperly secured.
Nodes: A node is a physical or virtual machine within the Kubernetes cluster. Essentially it is best to visualise an individual node within a Kubernetes environment as an individual machine within a corporate network. Worker nodes are responsible for running the application containers while control plane nodes are responsible for hosting the Kubernetes environment’s management components such as the API server.
Pods: A pod is the smallest deployable unit in Kubernetes and runs on top of a node. It is a wrapper which houses one or more containers and provides them with a shared network identity and storage. Each pod receives its own IP within the environment, allowing it to communicate with other pods. If a pod crashes or becomes unhealthy, Kubernetes automatically replaces it. It is best to think of a pod as a virtual machine while the node is similar to a physical machine.
Namespace: A namespace is a logical partition within a Kubernetes environment that groups and isolates resources from each other.They are used to separate different environments (i.e. staging, production, or development) or to divide resources within a Kubernetes environment. Bydefault, resources within one namespace cannot communicate with or access resources within another namespace. However, misconfigurations could allow aworkload to break out of its namespace and access resources it should normally not be allowed to reach as these are logical separations rather than physicalseparations.
Containers: A container is lightweight, stand alone, and executable package of software that encompasses everything an application needs to run which includes code, runtime, system tools, libraries, and settings. In short, they are execution environments tailored for a specific software to run in so that the software can run consistently despite the user’s underlying infrastructure. Within the context of Kubernetes, containers run within pods.
That is a wrap regarding what we need to understand for the basic architecture for the Kubernetes attacks. Next time we will be covering how to set up your own local Kubernetes testing environment from scratch so that we can begin simulating our misconfiguration in later parts.
Stay safe and keep your YAML files indented correctly!
