#Threat modeling
Kubernetes can be an important target for data and/or computing power theft. While data theft has traditionally been the primary motivation, cyber actors seeking computing power (often for cryptocurrency mining) are also drawn to Kubernetes to exploit its underlying infrastructure. In addition to resource theft, cyber actors can also cause denial of service against Kubernetes. The threats below represent the most likely sources of disruption to Kubernetes clusters.
- Supply Chain Risk - Attack vectors against supply chains are diverse and challenging to mitigate risks. Supply chain risk is the risk that an adversary could subvert any element that makes up a system, including product components, services, or people that help deliver the final product. This may include third-party software and vendors used to create and manage Kubernetes clusters. Potential threats to the supply chain can impact Kubernetes on multiple levels, including:
- Container/Application Level - The security of applications running in Kubernetes and their third-party dependencies relies on the trustworthiness of developers and the defense capabilities of the development infrastructure. Malicious containers or applications from third parties can provide cyber actors a foothold in the cluster.
- Infrastructure - The underlying systems hosting Kubernetes have their own software and hardware dependencies. Any potential threat to a system that is part of a worker node or control plane could provide a cyber actor with a foothold within the cluster.
- Malicious Threat Actors - Malicious actors often exploit vulnerabilities to gain access from remote locations. The Kubernetes architecture exposes several APIs that could potentially be exploited by cyber actors for remote exploitation.
- Control Plane - The Kubernetes control plane has various components that communicate to track and manage the cluster. Cyber actors often exploit exposed control plane components that lack proper access controls.
- Worker Node - In addition to running the container engine, worker nodes also host the
kubeletandkube-proxyservices, which may be exploited by network actors. Additionally, worker nodes exist outside of a locked-down control plane and may be more easily exploited by network actors. - Containerized Applications - Applications running within a cluster are common targets. Applications are often accessible outside the cluster, making them accessible to remote network actors. Cyber actors can then work from an already compromised application or leverage the exposed application's internally accessible resources to escalate privileges within the cluster.
- Insider Threats - Threat actors can exploit vulnerabilities or use privileges gained by individuals while working within an organization. Individuals from within the organization are given special knowledge and privileges that can be used to compromise Kubernetes clusters.
- Administrator - Kubernetes administrators have control over running containers, including the ability to execute arbitrary commands within a containerized environment. Kubernetes-enforced RBAC authorization can help reduce risk by limiting access to sensitive capabilities. However, since Kubernetes lacks two-person integrity control, you must have at least one administrative account to gain control of the cluster. Administrators often have physical access to systems or hypervisors, which can also be used to compromise a Kubernetes environment.
- User - A user of a containerized application who may have the knowledge and credentials to access containerized services in a Kubernetes cluster. This level of access can provide sufficient means to leverage the application itself or other cluster components.
- Cloud service or infrastructure provider - Access to the physical systems or hypervisors that manage Kubernetes nodes can be used to compromise the Kubernetes environment. Cloud service providers often have multiple layers of technical and administrative controls to protect systems from privileged administrators.