Kubernetes Trust Boundaries and Data Flow: KCSA practice questions

A trust boundary is a point where data or control passes between parts of a system that trust each other to different degrees, and threat modelling Kubernetes starts by drawing them. The CNCF Financial Services User Group threat model, for example, began with workshops that walked through each component of the architecture with the STRIDE methodology to find security issues at the trust boundaries of the platform, using a reference cluster of one master node backed by etcd and three worker nodes.

The central boundary is the API server. Kubernetes follows a hub-and-spoke API pattern: all API usage from nodes and from the Pods they run terminates at the API server, and none of the other control plane components are designed to expose remote services. Every request crosses the same sequence of checks. TLS protects the transport, authentication modules identify the caller or the request fails with status 401, authorization modules decide whether the action is permitted or the request fails with 403, and admission controllers may modify or reject requests that create, modify, delete or connect to objects, though they do not act on requests that only read them.

Traffic from nodes to the control plane is secured by default. Kubelets should hold the cluster's public root certificate and a client certificate, and Pods receive a root certificate and a service account bearer token so they can reach the API server through the kubernetes Service in the default namespace. The reverse direction is weaker. Connections from the API server to the kubelet, used for logs, attach and port-forwarding, do not verify the kubelet's serving certificate unless --kubelet-certificate-authority is set, and connections through the API server proxy to nodes, Pods and Services are plain HTTP by default. SSH tunnels that once protected these paths are deprecated; the Konnectivity service replaces them, with agents in the node network opening connections to a server in the control plane network.

Some data flows skip the API server's controls entirely, and the documentation lists them so they can be restricted. Direct access to etcd on TCP 2379 is neither subject to admission control nor recorded in audit logs, and a certificate from any CA that etcd trusts grants full access to its data; only the API server and backup tooling need that port. The kubelet API, typically on TCP 10250, can disclose Pod details and logs and execute commands in every container on the node, again outside admission and audit. Static Pods are loaded by the kubelet from a directory or URL the API server does not manage, and one that fails admission control still runs on its node. Access to the container runtime socket lets an attacker start or control containers directly.

Inside the cluster, namespaces are the usual tenancy line, but they are not strong on their own. A Pod can run as any ServiceAccount in its namespace and mount the Secrets, ConfigMaps and volumes there, so the RBAC good-practices guide advises treating boundaries within a namespace as weak and placing resources that need different levels of trust in separate namespaces.