Skip to content

K8S Threat Model

Threat Actors

Sources

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

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
Back to top