skip to content

A batch job shares a rented machine with your checkout service — what identity does the local credential endpoint give the batch job?

level: middleimportance: should knowfreq 46%

answer

  1. the endpoint sees a connection, not a caller
  2. one box, one identity
  3. co-tenants inherit it by being there
  4. the grant is a union of needs
  5. separation is a deployment change

basics

~20 s

The same one the checkout service gets. The credential endpoint answers a machine, not a process or a local user, so everything running on that box receives the machine's identity and its full set of permissions.

solid answer

~40 s

The endpoint decides whether to answer on one basis: the request reached it from this machine. It cannot see which process opened the connection, which local user owns it, or which deployment unit the binary came from, so the batch job receives exactly the credential the checkout service receives. The consequence is that the machine's identity must hold the **union** of what every tenant on the box needs — the service's reads, the job's writes, the log shipper's pushes — and a bug in the least important of them carries the permissions of the most important. There is no endpoint setting that changes this; separation comes from changing the deployment, by giving the sensitive workload a machine, or a platform, whose identity nobody else shares.

go deeper

for a junior

Remember the scope: the credential belongs to the machine, so every process on it gets the same identity. Co-locating a job on a box means giving that job the box's permissions.

for a middle

Explain why: the endpoint's only check is that the request came from this machine, so it has no way to distinguish processes, users or deployment units, and the grant must be the union of all of them.

for a senior

Demonstrate the operational reading: a grant that cannot be narrowed without breaking a co-tenant, an agent nobody owns holding production permissions, and platform records that cannot attribute a call to a workload.

for a principal

Treat co-location as an identity decision rather than a cost decision. The standard you set is which workloads may ever share a machine, because that choice fixes the smallest grant anyone on it can have.

## The endpoint answers a machine, not a process The local credential endpoint has exactly one input to its decision: the request arrived from this machine. It sees a network connection and nothing behind it. It does not see the process identifier, the operating-system user, the deployment unit, or the service account the code believes it is running as. There is no per-process authentication step in the design, because the design's boundary is the machine. So the answer is blunt: **the batch job gets the same identity as the checkout service**, with the same permissions, at the same moment, and neither one can tell the difference. Whatever one of them is allowed to do, the other is allowed to do. This surprises people because every other layer of a modern deployment does distinguish processes — the process table does, the file system does, the container runtime does. The credential endpoint is deliberately below all of that, answering a machine the platform knows about rather than a workload it does not. ## Everything on the box shares it The set of things that can read the credential is wider than the two workloads you deployed on purpose: - a second service co-located to save money - a batch or cron job that runs for a few minutes an hour - an operator with an interactive shell, for as long as that session lasts - an agent you did not write — a log shipper, a metrics collector, a configuration agent — running as a different local user - a container whose traffic is not isolated from the host's network stack - any code that a remote-execution bug in any of the above manages to run Each of those reads the same values and calls the platform as the same principal. Platform-side records will show the machine's identity acting, with nothing to say which of them acted. ## The union grant Because the identity is shared, its permissions must cover everything on the machine at once. That is the real cost, and it compounds quietly. The checkout service needs to read one store; the batch job needs to write another; the log shipper needs to push somewhere else. The machine identity ends up holding all three, and each new tenant on the box widens the grant for the tenants already there. | | Machine-scoped credential | Per-workload credential | |---|---|---| | Who the platform sees | the machine | the individual workload | | Size of the grant | the union of every co-tenant's needs | that one workload's needs | | Blast radius of one bug | everything the box is allowed to do | what that workload is allowed to do | | Platform records show | the machine acting | the workload acting | | Cost of co-locating one more job | widens the grant for everyone on it | none | The last row is the one teams feel first, usually as an argument in a review about whether a small job can "just run on the same box". ## Getting separation back No setting on the endpoint makes it answer differently per process. Separation comes from changing the shape of the deployment: 1. **One workload per machine**, with an identity sized for that workload alone. Blunt, more machines, and often the right answer for the sensitive half of a system. 2. **Move the sensitive step off the shared box**, so the wide permission lives with a workload nobody else shares a network stack with. 3. **Run somewhere that issues a credential per workload** rather than per host, so the platform decides who is asking instead of the machine boundary deciding it. 4. **Keep the shared identity minimal and explicit.** If it must exist, the review question changes: not "does this workload need this permission" but "is this permission acceptable for every process on this machine, including the ones nobody deployed on purpose". ## What to check first On an unfamiliar machine, three checks give you most of the picture: - which identity is attached, and what it is permitted to do - what else is running there, including agents installed by another team - whether the endpoint answers those processes at all, or has been restricted or switched off If the attached identity is wider than the most sensitive workload on that box warrants, you do not have a permissions problem to tune later. You have a co-location decision to revisit now, because tuning the grant downward will break whichever tenant needed the part you removed.

  • Would running each workload as a different local user separate their platform permissions?
    No. The endpoint never sees the local user; it answers a connection from the machine. Local users separate files and processes, which is worth having, but both users read the identical credential set and call the platform as the identical principal. Any separation you gain is inside the operating system, not at the platform boundary.
  • If the machine identity is shared, how do you tell afterwards which workload made a platform call?
    From the platform's own records, you generally cannot — they show the machine's identity acting. You have to correlate with something you control on the host: which process was running, what your own application logged, what the call pattern looks like. That ambiguity is itself an argument for not co-locating workloads whose actions you may need to tell apart.

saying these in an interview costs you the question

  • Thinks the endpoint authenticates the calling process
  • Believes separate local users get separate platform identities
  • Assumes a lower-privileged workload cannot read the credential
  • Says the grant can be narrowed without moving a workload
  • Expects platform records to name which co-tenant acted