A per-node agent's spec asks to share the host's process and network views — what does the boundary stop hiding?

## The views are the boundary's cheap half Of the two halves of a container boundary — the per-resource views and the restraints on privilege — the views are the part people stop thinking about, because they feel like tidiness rather than security. Each container seeing only its own processes looks like good hygiene. In practice the views carry a lot of the boundary's real value, and these two grants hand that value back. Neither grant adds any privilege. Both simply widen what the container can see and address, and on a busy host that is enough. ## Sharing the host's process view What becomes visible: - **Every process on the machine**, with the arguments it was started with. Credentials passed on a command line are readable immediately, by anyone. - **Other processes' environments and memory**, depending on the account each of those processes runs under and the privilege the container holds. Same account, or added privilege, means readable — and environment values are where most workloads receive their credentials. - **The ability to signal them.** Stopping a neighbour is an availability attack that needs no exploit at all. What it does not give: it is not, by itself, code execution as the host's administrator. It is a reading and signalling grant. The reason it still matters is that reading one credential from a neighbour's environment usually leads somewhere that *is* administrative. A second, quieter effect: a lot of operational reasoning assumes a container sees only itself. Tooling that counts processes, watches for unexpected children or attributes activity to a workload behaves differently for a container in the host's view, and the anomaly is easy to explain away as "that agent is special". ## Sharing the host's network view | Consequence | Why it follows | |---|---| | Reaches services bound to the host's loopback interface | Those services are reachable only from the host — and the container now *is* on the host, from the network's point of view. Loopback-bound endpoints are frequently unauthenticated for exactly that reason. | | Binds ports on the host directly | Including the ability to occupy or impersonate a port a node-local service was expected to answer on. | | Loses per-workload network rules | Allow/deny rules that select workloads by their own address cannot distinguish this container from the host itself, so an egress or peer restriction written for it does not bite. | | Sees the host's traffic paths | Observation of traffic is possible where the container also holds the privilege for it. | The loopback row is the one that turns this from a hardening nit into an incident: the node agent, local administrative endpoints and local metrics interfaces are commonly bound there on the assumption that only the host reaches them. ## Why these sit below the top tier, and why that is not comfort Ranked against privileged mode, a writable host-root mount or the runtime's control socket, these two are a step down: they do not directly give arbitrary execution as the machine's administrator. They give **credential theft and lateral reach**, which in most estates is one hop from the same place. A reviewer should say so plainly rather than treating the two tiers as equivalent — the ranking is what makes the negotiation possible. ## What to grant instead 1. **Name the specific thing the workload reads.** "We need the host's process view" almost always means "we need per-process figures for the whole machine"; the narrower answer is whatever per-workload data the platform already publishes. 2. **Name the specific endpoint it must reach.** "We need the host's network view" usually means one local endpoint; reaching that one endpoint is a routing and authorisation question, not a reason to dissolve the container's own network view. 3. **Grant one view, not both.** They are independent switches and are frequently requested as a pair out of habit. 4. **Remember what the grant costs across a fleet.** A workload placed on every host holds the grant on every host, so the theft surface is every workload in the estate, not one machine's worth. ## The sentence to leave the room with The views are not decoration. Sharing them does not raise what the container is *allowed* to do; it raises what the container can *see and address*, and on a shared host those two are most of what stands between one compromised workload and the credentials of all its neighbours.