K8S Threat Model

Threat Actors

Sources

For an overview of the current state of Kubernetes Threat Modelling, please refer to:

• Marco Lancini The Current State of Kubernetes Threat Modelling

Threat Actor	Description
External Attackers	Risk: People who have no access to the cluster apart from being able to reach the applications running on it and/or the management port(s) over a network Security Controls: Ensure that management services (e.g. the API server, kubelet and etcd) are not exposed to untrusted networks without authentication controls in place API Server Authentication API Server Authorisation Kubelet Authentication Where services that don’t allow authentication (e.g. cAdvisor or the read-only Kubelet) are required, restrict access to a whitelist of source addresses
Malicious Containers	Risk: An attacker has access to a single container and would like to expand their access to take over the whole cluster Privilege escalation: via the kubelet via access to etcd via service tokens, which are deployed on all containers with high privileged rights Some Kubernetes implementations have tokens for AWS/Azure APIs: this will increase the impact of a single container being compromised Security Controls: Ensure that all management ports visible on the cluster network require authentication for all users Ensure that service accounts are either not mounted in containers or have restricted rights (i.e. not cluster admin) Use Network Policies to restrict access between namespaces and pods
Malicious User / Stolen Credentials	Risk: An attacker has valid credentials to execute commands against the Kubernetes API, as well as network access to the port Security Controls: Ensure that RBAC policies are in place for all users, providing ‘least privilege’ access to cluster resources Ensure that Pod Security Policies are in place for all users to restrict the rights of pods that can be created, paying particular attention to high risk items such as privileged containers
etcd	Risk: etcd stores the cluster state including items like service tokens, secrets and service configurations kubeadm will bind etcd to the localhost interface only an attacker would need to get access to the master node in order to get access to the API interface the exposure is somewhat limited Problem with localhost binding only is that it doesn’t allow for clustered etcd setups if you want to have multiple etcd databases (redundancy) you need to allow for communications between datastores in these cases port 2379/TCP and 2380/TCP are likely to be exposed on the network 2379 is for client –> etcd communications 2380 is for communications between the different nodes in the etcd cluster Security Controls: Use client certificate authentication

Security Boundaries

Concept	Description
Cluster	Comprises all nodes as well as control-plane components, providing network isolation, and forms the top-level unit You might prefer different clusters for each team and/or stage (e.g., development, staging, production) to implement multitenancy over namespace-level or node-level isolation
Node	A virtual or bare-metal machine in the cluster hosting multiple pods and system components (e.g., kubelet) Those nodes are restricted to exactly access the resources necessary to carry out their tasks
Namespace	A sort of virtual cluster, containing multiple resources (e.g., services and pods) Namespaces are the basic unit for authorization
Pod	Used to group containers with the guarantee that all containers in the pod are scheduled on the same node It offers a certain level of isolation: you can define a security context and enforce it as well as specify network-level isolation
Container	A combination of cgroups, namespaces, and copy-on-write filesystems that manages the application-level dependencies By configuring the Quality of Service of your pods, you can influence the runtime behaviour, but unless you’re using advanced runtime sandboxing techniques, containers typically do not provide strong isolation guarantees beyond the kernel-level security ones