A per-node log shipper's spec asks for privileged mode, a writable host-root mount, the runtime's control socket and the host's process view — how do you rank and narrow them?

seniorshould knowfreq 49%

answer

rank the grants, do not count them
three of four are one tier
one tier-1 grant is the whole loss
read-only mount of one directory
per-host placement multiplies the radius

basics

~20 s

Privileged mode, a writable host-root mount and the control socket are each already administrative access to that machine — one tier, where one grant is the whole loss. Narrow them to a read-only mount of the log directory.

solid answer

~50 s

Rank before you count. Privileged mode, a writable mount of the host's root and the runtime's control socket land in the same tier: each on its own lets the workload write what the host executes, so holding three is not three times worse than holding one, and removing two while leaving one changes nothing. The host's process view is a tier below — it yields neighbours' command lines and credentials rather than direct execution, which is usually one hop from the same outcome. Then narrow: the job is reading log files, so grant a read-only mount of the one directory that holds them and nothing else; the workload identity the shipper wants for labelling is already injected into its environment or written beside the data. And say the multiplier out loud — one copy per host means one compromise is the whole fleet.

code

yaml · 12 lines

yaml

workload: log-shipper
placement: one copy on every host
grants:
  privilegedMode: true
  hostMounts:
    - hostPath: "/"
      mountedAt: "/host"
      access: read-write
    - hostPath: "/runtime-control.sock"
      mountedAt: "/runtime-control.sock"
      access: read-write
  shareHostProcessView: true

go deeper

for a junior

Recall the sorting rule: privileged mode, a writable host-root mount and the runtime's control socket are each already administrative access to that machine, so they belong in one group.

for a middle

Explain why one grant from that group is the whole loss, and what the narrow substitution looks like — a read-only mount of the single directory the job reads, and identity taken from what the platform already injects.

for a senior

Run the negotiation: name what the workload does without each grant, refuse the tier that cannot be narrowed, argue the view separately, and state the fleet multiplier explicitly rather than implying it.

for a principal

Own the standard that stops this arriving one spec at a time: which workloads may ever hold a host-administrator grant, what a vendor must demonstrate first, and who reviews the images of everything running on every host.

Rank first, because counting misleads

The instinct in a review is to treat four grants as four risks and negotiate each down a bit. That is the wrong shape for this material, because three of these four are the same grant wearing different clothes.

Grant	What it gives immediately	Tier
Privileged mode	Full privilege set and reachable host devices — mount the host's storage, write what it runs	1: host administrator
Writable host-root mount	Direct writes to the files the host executes: scheduled tasks, start-up definitions, trusted keys	1: host administrator
Runtime control socket	Ask the runtime to build a privileged sibling with the host mounted in; plus every neighbour's configuration	1: host administrator
Host process view	Neighbours' command lines, their environments where the account allows, and the ability to signal them	2: theft and lateral reach

The consequence of the table is the answer to the question: any one tier-1 grant is the whole loss. Cutting the spec from three tier-1 grants to one is not a 66% improvement; it is no improvement. A review that trades two of them away and books a win has achieved nothing except a shorter spec.

The tier-2 grant is not a rounding error

The host's process view does not hand over the machine. It hands over whatever the neighbours put on their command lines and, depending on the account they run under and the privilege this container holds, whatever is in their environments — which is where credentials usually are. On a shared host that is a credential harvest, and a harvested credential frequently reaches somewhere administrative anyway. Rank it below tier 1 honestly, and do not dismiss it.

The narrowing conversation

The workload's actual job is: read files under a log directory and send them somewhere.

Grant the directory, not the filesystem. One host path, read-only. This is the single substitution that removes the tier-1 mount.
Remove privileged mode outright. Reading files needs no device access and no kernel privilege. If a specific operation was denied, name that operation; the mode is never the smallest form of an answer.
Replace the control socket with data that already exists. The reason a shipper asks for it is labelling — which workload produced this line. The platform already injects that identity into the workload's environment and usually into the path where the data lands. Where richer data is genuinely needed, a filtering proxy that permits only the named read requests is the fallback, and the socket itself is then reachable by nothing else.
Split the views from the rest. If per-process figures are truly needed, that is a separate, tier-2 request to be argued on its own merits — not a rider on a tier-1 spec.

The fleet multiplier

This workload runs one copy on every host. That changes the arithmetic in two directions and reviewers routinely get it backwards:

The blast radius is every machine, because the same grant is held everywhere. One compromise of the image, its update channel or its configuration is a simultaneous compromise of the estate.
The value of the target rises accordingly. A workload that runs everywhere with a tier-1 grant is the single most attractive thing on the estate, and its supply chain is now part of your host security, not part of your logging pipeline.

So a per-host placement raises the bar rather than lowering it, and "it is just the logging agent" is the exact sentence to distrust.

When tier-1 is honest

Some workloads genuinely manage the machine, and for those a tier-1 grant may be the right answer. The control then moves off the spec and onto the surroundings:

keep the set of such workloads small enough that somebody can recite it;
know who may change their specs and their images, because that set now holds the same privilege;
pin what runs to an exact, verified artifact rather than a moving pointer;
keep them off the hosts that do not need them.

Whether something automatically refuses a spec like this before it starts is a separate subject with its own mechanisms; the point here is that the reviewer must be able to say which tier each grant is in and what the workload would do without it.

The answer in one move

Sort into tiers, state that one tier-1 grant is the whole loss, replace the tier-1 grants with the narrow read-only path the job actually needs, argue the tier-2 grant separately, and multiply everything by the number of hosts the workload lands on.

## Rank first, because counting misleads The instinct in a review is to treat four grants as four risks and negotiate each down a bit. That is the wrong shape for this material, because three of these four are the same grant wearing different clothes. | Grant | What it gives immediately | Tier | |---|---|---| | Privileged mode | Full privilege set and reachable host devices — mount the host's storage, write what it runs | 1: host administrator | | Writable host-root mount | Direct writes to the files the host executes: scheduled tasks, start-up definitions, trusted keys | 1: host administrator | | Runtime control socket | Ask the runtime to build a privileged sibling with the host mounted in; plus every neighbour's configuration | 1: host administrator | | Host process view | Neighbours' command lines, their environments where the account allows, and the ability to signal them | 2: theft and lateral reach | The consequence of the table is the answer to the question: **any one tier-1 grant is the whole loss**. Cutting the spec from three tier-1 grants to one is not a 66% improvement; it is no improvement. A review that trades two of them away and books a win has achieved nothing except a shorter spec. ## The tier-2 grant is not a rounding error The host's process view does not hand over the machine. It hands over whatever the neighbours put on their command lines and, depending on the account they run under and the privilege this container holds, whatever is in their environments — which is where credentials usually are. On a shared host that is a credential harvest, and a harvested credential frequently reaches somewhere administrative anyway. Rank it below tier 1 honestly, and do not dismiss it. ## The narrowing conversation The workload's actual job is: read files under a log directory and send them somewhere. 1. **Grant the directory, not the filesystem.** One host path, read-only. This is the single substitution that removes the tier-1 mount. 2. **Remove privileged mode outright.** Reading files needs no device access and no kernel privilege. If a specific operation was denied, name that operation; the mode is never the smallest form of an answer. 3. **Replace the control socket with data that already exists.** The reason a shipper asks for it is labelling — which workload produced this line. The platform already injects that identity into the workload's environment and usually into the path where the data lands. Where richer data is genuinely needed, a filtering proxy that permits only the named read requests is the fallback, and the socket itself is then reachable by nothing else. 4. **Split the views from the rest.** If per-process figures are truly needed, that is a separate, tier-2 request to be argued on its own merits — not a rider on a tier-1 spec. ## The fleet multiplier This workload runs one copy on every host. That changes the arithmetic in two directions and reviewers routinely get it backwards: - The **blast radius** is every machine, because the same grant is held everywhere. One compromise of the image, its update channel or its configuration is a simultaneous compromise of the estate. - The **value of the target** rises accordingly. A workload that runs everywhere with a tier-1 grant is the single most attractive thing on the estate, and its supply chain is now part of your host security, not part of your logging pipeline. So a per-host placement raises the bar rather than lowering it, and "it is just the logging agent" is the exact sentence to distrust. ## When tier-1 is honest Some workloads genuinely manage the machine, and for those a tier-1 grant may be the right answer. The control then moves off the spec and onto the surroundings: - keep the set of such workloads small enough that somebody can recite it; - know who may change their specs and their images, because that set now holds the same privilege; - pin what runs to an exact, verified artifact rather than a moving pointer; - keep them off the hosts that do not need them. Whether something automatically refuses a spec like this before it starts is a separate subject with its own mechanisms; the point here is that the reviewer must be able to say which tier each grant is in and what the workload would do without it. ## The answer in one move Sort into tiers, state that one tier-1 grant is the whole loss, replace the tier-1 grants with the narrow read-only path the job actually needs, argue the tier-2 grant separately, and multiply everything by the number of hosts the workload lands on.

The vendor says the shipper will not start without the runtime's control socket. Now what?
It stops being a configuration question and becomes a product choice. The options are: front the socket with a proxy permitting only the requests the shipper actually issues; run it only on the hosts whose data justifies the grant; or pick a shipper that reads the identity the platform already writes. A per-host workload that demands administrative access is a supply-chain decision, not a logging one.
Two of the three tier-1 grants are removed and one remains. What has the review achieved?
Nothing measurable. Each tier-1 grant independently lets the workload write what the host executes, so the remaining one reproduces the full outcome by itself. The only honest reports are "tier 1 removed" or "tier 1 accepted as a named exception" — a partial reduction inside the tier is paperwork.
Does running the shipper on every host make the grant more or less acceptable?
Much less. The same grant is held on every machine, so one compromise of the workload, its image or its update path is the whole estate at once, and it becomes the highest-value target you run. Per-host placement raises the bar, and a review that treats "it is just an agent" as reassurance has it backwards.
What if the workload's genuine job is managing the host?
Then a tier-1 grant can be honest, and the control moves to its surroundings: keep that set of workloads short and named, know exactly who may change their specs and images, pin what runs to a verified artifact rather than a moving pointer, and keep them off hosts that do not need them.

saying these in an interview costs you the question

Treats four grants as four risks to be reduced proportionally
Books removing two tier-1 grants as a win while one remains
Treats a read-only mount of the whole host filesystem as harmless
Assumes a per-host workload has a smaller blast radius than a cluster-wide one
Says the control socket is milder than privileged mode because it only talks to the runtime
Accepts the grants because the image comes from a trusted internal team

A per-node log shipper's spec asks for privileged mode, a writable host-root mount, the runtime's control socket and the host's process view — how do you rank and narrow them?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Rank first, because counting misleads

The tier-2 grant is not a rounding error

The narrowing conversation

The fleet multiplier

When tier-1 is honest

The answer in one move

▾common follow-ups4 questions

▾red flags6 flags

Rank first, because counting misleads

The tier-2 grant is not a rounding error

The narrowing conversation

The fleet multiplier

When tier-1 is honest

The answer in one move

answer

go deeper