skip to content

Setting the credential endpoint's reply hop limit to one blocks which callers on a rented machine, and which does it leave untouched?

level: seniorimportance: nice to knowfreq 27%

answer

  1. a counter every router decrements
  2. it measures distance, not identity
  3. one hop means the reply dies at the router
  4. bridged containers lose it, host-networked do not
  5. the forging bug is zero hops away

basics

~20 s

It blocks anything a routing hop away — a container on an address-translated network, a proxy relaying an outside request, a neighbouring machine — because the reply dies in transit. Code in the host's own network namespace is untouched.

solid answer

~40 s

Every IP packet carries a counter that each router decrements, and the endpoint lets you set it on the replies it sends. At one, a reply survives only as far as the machine's own network stack. So the setting answers **how far away** the caller is, not **who** it is: containers whose traffic is bridged or address-translated through the host lose access, as does a forwarding proxy and anything on another machine that acquired a route. It does not touch a process in the host's network namespace — which is precisely where a request-forging bug in your own service lives — nor a host-networked container, nor an attacker already holding a credential. Read it as reachability reduction that pairs with the request handshake, and expect it to break co-located callers nobody inventoried.

go deeper

for a junior

Recall what it measures: a reply hop limit of one means the answer cannot cross a router, so only callers on the machine's own network stack ever receive it.

for a middle

Explain the split it creates: bridged or address-translated containers and forwarding proxies are a hop away and lose access, while host-networked containers and host processes are not and keep it.

for a senior

Demonstrate the limit of the control: it does nothing about a forging bug in the service itself, which is zero hops away, and it breaks co-located callers nobody recorded, so inventory precedes rollout.

for a principal

Set the ladder as a standard: handshake required, hop limit where the topology allows, and the endpoint switched off outright on machines whose workloads make no platform calls.

## What the hop limit actually is Every IP packet carries a counter that each router decrements as it forwards the packet; at zero the packet is discarded. The credential endpoint lets you set that counter on the **replies it sends**. Set it to one, and a reply survives exactly as far as the machine's own network stack — it never crosses a routing hop. The question the setting answers is therefore not "who are you" but "how far away are you". It is a distance check, and distance is a proxy for a category of caller rather than for an intent. ## Who loses access - **A container on a bridged or address-translated network.** Its packets are routed through the host, so the reply has a hop to make and dies making it. This was the original motivation: on a shared host, containers inherited the host's platform identity purely by being able to reach the endpoint. - **A forwarding proxy running on the machine** that relays a request inward on someone else's behalf — the reply has to cross that forwarding hop to get back out. - **Anything on another machine** that could reach the address through a route somebody added, deliberately or otherwise. ## Who does not - **The service itself.** A process in the host's network namespace talks to the endpoint with no router in between. A request-forging bug in that service issues a request *from* that service, so the hop limit does not touch it at all. This is the half candidates miss. - **A container running with host networking.** Same namespace, same zero hops, same access as the service beside it. - **An attacker who already holds the credential.** The hop limit governs reaching the endpoint, never the use of what it returned; the stolen values remain bearer material usable from anywhere. | Caller | Hops to the endpoint | Reachable with a reply hop limit of one | |---|---|---| | process in the host's namespace | none | yes | | host-networked container | none | yes | | bridged or address-translated container | one or more | no | | request relayed through a local forwarding proxy | one or more | no | | workload on another machine entirely | one or more | no | ## So what is it for Read it as a **reachability reduction**, in the same family as not exposing an administrative port: it removes whole categories of caller that had no business holding the machine's identity, and it does so without your having to enumerate them one by one. Paired with a required request handshake, the two cover different attackers — the handshake removes the one-way forged fetch, the hop limit removes the caller a routing hop away. Neither removes the other's case, which is why they are usually set together. Neither of them, though, is the strongest setting available. ## Switching the endpoint off The strongest setting is not to answer at all. A machine whose workload makes no platform API calls, or which receives its credential by some other route, has no use for the endpoint, and an endpoint that does not answer is one no bug on that machine can talk to. It is the only configuration with no attack surface here, and it is badly underused, because using it requires knowing what the workload actually calls — which is a question most teams have never had to answer precisely. The practical ladder, weakest to strongest: 1. The endpoint answers any local reader. 2. The endpoint requires the write-then-read handshake. 3. The handshake is required **and** the reply hop limit is one. 4. The endpoint does not answer on this machine at all. ## Rolling it out Both settings break callers quietly, and at some distance from the change: - co-located jobs that had been using the machine credential without anyone recording it - agents and tooling installed by another team, which nobody thinks of as platform callers - container setups configured to let workloads fall back to the host's identity So the order is: find out who reads the endpoint on that machine, give the legitimate readers their own route to a credential, then tighten. A hop limit applied to a fleet nobody inventoried produces an outage whose cause sits three network layers away from the symptom, and the usual outcome is that the setting is reverted and never revisited.

  • Why does a host-networked container still reach the endpoint under a hop limit of one?
    Because it shares the host's network namespace, so its packets and the replies to them never cross a router. The hop limit only discriminates by distance, and that container is at the same distance as the service running directly on the host. If you need it excluded, the lever is the handshake requirement or turning the endpoint off, not the hop count.
  • When is switching the endpoint off entirely the right call?
    When the workload on that machine makes no platform API calls at all, or receives its credential by some other route, so nothing legitimate reads the endpoint. It is the only setting with no surface for any bug on that machine to reach. The obstacle is never the setting, it is establishing with confidence what the workload actually calls.

saying these in an interview costs you the question

  • Thinks a hop limit stops a forging bug in the service itself
  • Believes it makes a retrieved credential unusable off the machine
  • Assumes every container is blocked regardless of its networking
  • Confuses the hop limit with disabling the endpoint
  • Applies it fleet-wide without inventorying who reads the endpoint