In a shared Kubernetes cluster, which of namespace, pod and node is a real trust boundary?

## What a trust boundary actually is On a data-flow diagram a trust boundary is a line crossed by data or control where the level of trust changes **and something enforces the change**. Both halves matter. A line with a trust difference and no enforcement is a wish drawn in ink, and a line with enforcement but no trust difference is clutter. Modeling a cluster goes wrong when people reach for the org chart's lines (team, namespace, project) instead of asking, for each line, *what mechanism stands on it, and which threats does that mechanism see?* ## The candidate lines inside a cluster | Candidate line | Enforced by | Holds against | |---|---|---| | Container / pod | Kernel isolation on the node: separate process and filesystem views, dropped capabilities, syscall filtering | A workload staying inside its own view of the host — only as far as those settings are actually applied | | Namespace | The control plane, when it authorizes API requests and scopes object names | An identity acting through the API; nothing that travels below the API | | Node | The host kernel, plus the node's own identity and disk | Workloads running on other nodes; not workloads on the same node | | Control plane | Authentication and authorization at the API server, and access to its datastore | Everyone who is not an administrator of the cluster | | Cluster edge | The ingress path and the surrounding cloud network or account | The internet and the rest of the estate | The crucial observation is that the namespace line and the node line face **opposite directions relative to the API**. Namespace separation is decided by the control plane on the way in through the API. Node separation is decided by the kernel, underneath every API call. An attacker who is already executing code inside a pod does not need the API at all, so a model that only draws namespace lines has drawn none of the boundaries their path crosses. ## Worked example: the payments and marketing namespaces An internal platform cluster runs a `payments` namespace and a `marketing-site` namespace, scheduled onto one shared node pool because it was cheaper. The threat to model is not an anonymous internet attacker stealing a database; it is the low-value workload as the foothold and payment-flow integrity as the asset. Assume the marketing workload is compromised through a flaw in its own application code. The attacker is now a process on a node that also runs payment pods. Without ever authenticating to the API as payments, they are adjacent to: - the **host kernel**, and through it every other pod on that node if isolation fails; - the **node filesystem**, including material mounted for the other pods scheduled there; - the **node's credential**, which is normally limited to the objects the node's own pods need — but those include the secrets mounted into every pod scheduled on it, payments among them; - the node's **network position** inside the cluster. So the namespace line, drawn as though it separated the two tenants, does not sit anywhere across the attacker's path. That is the finding, and it is worth more than a page of generic threats. ## Escape as the named assumption Attach one sentence to the node boundary: *we assume the container runtime and host kernel keep workloads on a node from reading or influencing each other.* Writing it down does two useful things. It becomes reviewable — a privileged pod, a host path mount, a shared device, or a runtime change all invalidate it, and the review is now a one-line diff rather than a re-read of the whole model. And it makes the consequence explicit: a container escape is not one more threat in the list, it **deletes a boundary**, so every threat you suppressed because of that boundary comes back at once. ## What the model says next Work STRIDE per crossing rather than per box. At the node line, elevation of privilege (violating authorization) and information disclosure (violating confidentiality) dominate; the marketing-to-payments direction is lateral movement, so the ratings that matter are tampering with payment flow and disclosure of payment data. Rate against the **asset**, not against the element: the risk is money and transaction integrity, not an abstract cluster. Then offer the choices the boundary work exposes: keep the arrangement and add compensating detection on the node line; move payments to its own node pool so the line falls where the kernel is; or move the tenant out entirely. Each is a different cost, and the model's job is to make the cost visible rather than to pick for the organisation. ## Common mistakes Drawing a box around every pod and stopping there hides both the node and the control plane, which is where the interesting privilege lives. Treating the cluster's internal network as trusted because it is internal reintroduces every spoofing and disclosure threat you thought you had removed. And treating the control plane as somebody else's infrastructure leaves the one component that is inside all of your boundaries out of the diagram.