A workload on a rented machine stores no platform key anywhere, yet its API calls are authorized — where does its credential come from?

## What is attached to the machine When you create a machine on a cloud platform you can attach a **workload identity** to it — a principal the platform defines, with permissions granted to it, referenced from the machine's configuration record. The attachment is a pointer, not a value. Nothing secret is copied into the machine, into its image, or into any file the machine can read. Take a disk image of the running box, open it, and there is no key in it. The credential the workload actually signs its calls with is **derived from that attachment at runtime**, by the platform, on demand. ## The local credential endpoint Providers that rent you machines expose the same construct under different names: a small HTTP service reachable from the machine at a **fixed link-local address** — an address valid only on the local link, never routed. The platform's own host agent answers it, out of band from your private network. Two properties define it: - It is **reachable only from the machine itself**. There is no route to it from your private address range, from a peered network, or from the internet. - In its simplest form, **locality is the authorization**: the endpoint asks for nothing beyond the request having arrived from that machine. That is the whole elegance of the design and the whole of its exposure, which is why providers later added a request handshake and a reply hop limit on top of it. ## What comes back, and for how long A read of the credential path returns a small document — a handful of values and the moment they stop working: | Field | What it is | |---|---| | identifier | the non-secret half, which appears in request signatures and in platform-side records | | secret | the signing material, never sent on the wire in a normal signed request | | session token | the value telling the platform this is a derived session rather than a standing key | | expiry | the timestamp after which the set stops being accepted, usually hours away rather than days | The exact lifetime is set by the platform and by how the identity was configured. Treat it as short and never hard-code a number. ## Who refreshes it Application code almost never calls the endpoint directly. The platform's client library does, and the loop is always the same: 1. Check the cached credential. 2. If there is none, or its expiry is closer than a safety margin, read the endpoint again. 3. Cache the new set until its own expiry minus that margin. 4. Sign the outgoing call with whatever is cached. The margin matters more than it looks. Without it, a long-running call can be signed with a credential that lapses before the platform validates it, and you get an authorization failure that looks like a permissions bug and is really a clock. Failure to reach the endpoint deserves deliberate handling too: it is a local dependency, and a workload that treats one failed read as fatal will restart itself over a blip that a retry would have covered. ## What you manage instead "No key on disk and nothing to rotate" removes a real class of work, and it is easy to hear it as "nothing to manage". What replaces rotation is: - **The attachment.** Which identity sits on which machine is now a first-class configuration decision, reviewed like a grant, because changing it changes what every process on that box can do. - **The permissions on that identity**, which are what the derived credential carries. The credential is disposable; the grant behind it is not. - **Expiry as the revocation story.** You do not replace the value. You detach the identity, change the grant, or wait out the lifetime — a different operational reflex from swapping a key, and one worth rehearsing before you need it. - **The endpoint's own settings** — whether the hardened request path is required, what the reply hop limit is, and whether the endpoint should answer on that machine at all. The mental model to keep is three separate things: the **identity** is the durable object you design and review, the **credential** is a short-lived artefact the platform mints from it, and the **endpoint** is the delivery mechanism between them. Being able to pull those three apart, and say which one you would change for a given problem, is most of what this question tests.