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.
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 makethe change
4. Reads or writes to the etcd component
It is also worth noting that, other Kubernetes componentsare only supposed to communicate via the Kube API server and should notcommunicate directly with each other. Moreover, it is not responsible forstoring and maintaining the database for the desired state nor is itresponsible for enforcing the active state as those operations belong to otherKubernetes components
Etcd: The etcd component is a distributed key-valuedatabase that acts as Kubernetes’ single source of truth. It stores the clusterconfiguration, resource definitions, and event history. In short, it storeseverything the environment knows about itself. All reads and writes should flowexclusively through the Kube API Server, meaning that etcd should never bedirectly exposed. A compromised etcd gives an attacker complete visibility intothe entire cluster.
Kubelets: The Kubelet is a local agent running onevery 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 theKube API Server detailing which pods pods should be running on its node, ensurethose pods are started and kept healthy, and continuously reports the node’sstatus back to the API Server. A Kubelet exposes its own API endpoint, whichcan become a significant attack surface if left improperly secured.
Nodes: A node is a physical or virtual machine withinthe Kubernetes cluster. Essentially it is best to visualise an individual nodewithin a Kubernetes environment as an individual machine within a corporatenetwork. Worker nodes are responsible for running the application containers whilecontrol plane nodes are responsible for hosting the Kubernetes environment’smanagement 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. Eachpod 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 withina Kubernetes environment that groups and isolates resources from each other.They are used to separate different environments (i.e. staging, production, ordevelopment) or to divide resources within a Kubernetes environment. Bydefault, resources within one namespace cannot communicate with or accessresources within another namespace. However, misconfigurations could allow aworkload to break out of its namespace and access resources it should normallynot be allowed to reach as these are logical separations rather than physicalseparations.
Containers: A container is lightweight, standalone,and executable package of software that encompasses everything an applicationneeds to run which includes code, runtime, system tools, libraries, andsettings. In short, they are execution environments tailored for a specificsoftware to run in so that the software can run consistently despite the user’sunderlying infrastructure. Within the context of Kubernetes, containers runwithin 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!
