skip to content

What changes about who can read a credential when a workload fetches it itself at run time instead of receiving it injected at start-up?

level: middleimportance: must knowfreq 58%

answer

  1. delivery description or process memory
  2. the platform as courier, or not
  3. injected copy lives as long as the instance
  4. fetching makes short validity possible
  5. fetching adds a start-up dependency

basics

~20 s

Fetching moves the value out of the workload's delivery description entirely: it exists in the process's memory from the moment it is fetched, so it can be short-lived and renewed. Injection puts a static value into the instance for the instance's whole life.

solid answer

~50 s

Injection makes the platform the courier. The value has to exist in whatever the platform reads the workload's start-up inputs from, and it is delivered into the instance where it stays, unchanged, for as long as that instance lives — so anyone who can read the delivery description or inspect the workload can read it. Fetching moves the value out of that path: the deployment describes *which* credential to obtain, not the credential, and the value only exists in the process from the moment it asks for it. That narrows the readership to the process and the source, and it makes short-lived, renewable credentials possible, because renewing no longer means replacing the instance. The costs are real: the process needs a way to prove what it is to the source, the source's availability becomes part of the workload's, and it takes code rather than configuration.

code

pseudocode · 15 lines
pseudocode
on start:
    credential = fetch_from_source(scope = "ledger-datastore", validity = 60 minutes)
    if credential is error:
        fail_start("no credential available")   # refuse to run with nothing
    open_datastore(credential)

every 1 minute:
    if credential.expires_in < 20 minutes:
        renewed = fetch_from_source(scope = "ledger-datastore", validity = 60 minutes)
        if renewed is ok:
            credential = renewed
            use_on_next_connection(credential)
        else:
            log("renewal failed; current value valid for", credential.expires_in)
            # keep serving and retry next minute, until it actually expires

go deeper

for a junior

Know that a credential can either be handed to the process when it starts or asked for by the process itself, and that only the second one keeps the value out of the deployment's own description.

for a middle

Explain where the value comes to rest in each shape, who can read it there, and why renewing without replacing the instance is only possible when the process fetches.

for a senior

Weigh the costs honestly: a bootstrap identity problem, a start-up dependency on the source, and real code in the workload — then decide per credential rather than fleet-wide.

for a principal

Set the rule for which credentials must be fetched and which may be delivered, and own the consequence that the credential source is now on the critical path for starting workloads.

## Three shapes, and what each one does to readership Delivery is the last hop: how a credential reaches a process that is already packaged and already scheduled. The shape you choose sets who else ends up holding the value. | Delivery shape | Where the value comes to rest | Who can read it | How it changes | | --- | --- | --- | --- | | Baked into the artifact | Inside the immutable artifact | Everyone who can obtain the artifact | Rebuild and roll out | | Injected at start-up | The delivery description, then the instance | Whoever can read that description or inspect the workload | Deliver again, replace the instance | | Fetched by the process | The process's memory, from the fetch onward | The source, the verifier, and the process | Renew in place, no redeploy | The first row is a different question. This one is the boundary between the second and the third. ## Injected at start-up: the platform is the courier In this shape something outside the workload holds the value and hands it over when the instance starts. That has three consequences worth stating precisely: - **The value must exist in the delivery path.** Whatever the platform reads the workload's start-up inputs from now holds a copy of the credential, which is why that store gets its own access rules, its own encryption at rest, and its own audit trail. Whether the value is encoded for transport is irrelevant to who can read it — encoding is not encryption. - **The copy lives as long as the instance.** The process receives the value once at start-up; nothing about that copy changes afterwards. Anyone who can inspect the running workload can see it, and a crash dump of that process can contain it. - **Changing it is an instance-level operation.** A new value has to be delivered *and* the instance replaced, because the delivered copy is only read at start. (Whether the platform can update what is on disk under a running process, and how long that takes to be noticed, is the propagation question, not this one.) What injection buys is simplicity: the workload needs no code, no client, no network dependency. It reads a value it was given and starts. ## Fetched by the process: the value never enters the delivery description Here the deployment says *which* credential this workload is entitled to, and the process asks for it once it is running. What moves: - **The readership narrows.** The value is not in the delivery description, not in whatever the platform stores start-up inputs in, and not in the artifact. It is in the source, in the process's memory, and known to the verifier that will check it. Reading it now requires access to the source or to the running process. - **Lifetime becomes adjustable.** Because renewing no longer means replacing the instance, the credential can be issued with a short validity and refreshed on a timer. That is only possible in this shape. - **The credential can be per-instance.** Each process can hold a different value, so an exposure is attributable and revocable without disturbing anything else. And what it costs: - **The process must prove what it is to the source** before it is given anything — a bootstrap problem with its own solutions, and a subject of its own. - **A new start-up dependency.** If the source is unreachable, the workload cannot start; the source's availability is now part of the workload's. Mature implementations decide deliberately whether to fail fast or to start degraded. - **Code, not configuration.** Fetching, caching, renewing before expiry and reconnecting on renewal all live in the workload. A process that fetches once and never renews has taken the costs without the benefit. ## Choosing per credential, not per platform The two credentials in a payments ledger usually land differently. A datastore credential is issued by something you control, is renewable, and can be scoped per workload — a good candidate for fetching, with a short validity. An outbound partner key is issued by somebody else's process, often long-lived by design and sometimes not programmatically obtainable at all, so it is delivered to the instance and rotated as a deliberate operation. Designs genuinely differ here, and the right answer names the credential rather than the platform. ## What neither shape fixes Once the value is inside the process, both shapes converge: it is in memory, it can be logged by accident, it can appear in a crash dump, and it is as powerful as the rights attached to it. Delivery decides who holds a copy *before* the process has it, and how much work changing it is. It does not decide what the credential is allowed to do — that is least privilege, and it is a separate decision that neither shape makes for you.

  • If the process fetches its own credential, what does it present to the source to get one?
    Something that proves what the workload is, rather than a stored password — otherwise you have only moved the problem to whatever the process uses to authenticate. How a workload establishes that identity is a subject of its own; what matters here is that the fetching shape only helps when the thing it presents is not itself a long-lived delivered secret.
  • A workload fetches its credential once at start-up and keeps it forever. What has it gained?
    Only the narrower readership: the value stays out of the delivery description. It has given up the main benefit, because a value that is never renewed cannot be short-lived, and it has taken on the cost — a start-up dependency on the source. Fetching pays for itself when renewal is implemented, not when the fetch is.
  • Does delivering the value at start-up rather than fetching it make rotation impossible?
    No, it makes rotation an instance-level operation: deliver the new value and replace the instances that hold the old one. That is slower and more visible than a renewal timer, and it is why credentials delivered this way need a window in which both the old and the new value are accepted.

Injection is a key posted to the flat before you move in; it sits in the drawer until you move out. Fetching is collecting a key from the concierge each morning, which only works if the concierge is awake and recognises you.

saying these in an interview costs you the question

  • Thinks fetching removes the value from memory as well
  • Believes an injected value refreshes itself while the instance runs
  • Says a fetching workload needs no way to authenticate to the source
  • Treats encoding of a delivered value as protection of it
  • Fetches once at start-up and calls the credential short-lived
  • Ignores that the source becomes part of the workload's availability