How should a hosted browser provider's account name and key reach a CI test run?

A hosted browser provider gives you an account name and a long-lived key. Your charity donation-checkout suite has to present both on every run, and the client wants them inside the connection address it dials. The question is how those two values get from wherever they are kept into a running CI job without leaving a copy behind. ## What injection means for this particular credential The general discipline is familiar: the secret is not in the source tree, the job receives it at start, and the process reads it from its environment. What is specific here is the **destination**. This credential's destination is a component of a URL, not a header the client sets for you. That single fact changes what "injected" has to mean: - the job receives the **name** and the **key** as two separate protected variables; - the harness reads both and assembles the address **in memory** at the moment it dials; - the assembled value exists only for the life of the process; - no file, image layer, cache or pipeline definition ever contains the joined form. ## Why the halves stay separate An assembled address is the entire working credential in one string. Anything holding it — a config file, a shell history, a cached fixture, a screenshot of a terminal — is holding a usable secret rather than a fragment of one. Keep the halves apart and: 1. No stored value is by itself the thing that opens the account. 2. The pipeline can protect each half independently. 3. A changed key is an edit to one variable, not a rewrite of an address string duplicated across several jobs. 4. The harness can tell you precisely which half is missing when a job fails to start. ## The places it must never end up The usual list applies — not in the repository, not in an image layer, not on a command line the job echoes — and your pipeline's own secret-store guidance already makes that argument. What is specific here is *what* must not end up there. Not the key: the **joined address**, which no secret store ever sees because your own code produced it. So the leaks that actually happen on this credential are the ones the store cannot help with: - a committed properties or YAML file holding the whole address "just for local runs", which reads like configuration and gets reviewed like configuration; - a debug line added during an incident and never removed; - a re-run hint printed by the harness so a developer can reproduce the failure locally. The last two survive review because they were added under pressure and they look helpful. ## Failing loudly, without printing anything A job that starts without its credentials should stop immediately with a message that names the missing variable and says nothing about any value it did find. Two mistakes are common here, and both are avoidable: - **Falling back to a default.** A hard-coded default address is a committed credential with extra steps, and it hides the misconfiguration until something odd happens much later. - **Echoing to help diagnose.** Printing what was read, even truncated, puts part of the secret in the log. Print the variable's name and whether it was empty; never its contents. ## A local run is the same problem Developers will want to run the suite on their own machines, and that is where committed addresses come from. Give them the same shape: the harness reads the same two variable names, and the developer supplies them from their own local environment. The suite should have exactly one code path that builds the address, whether it runs in CI or on a laptop, so there is nothing to maintain separately and no second place for a value to be written down. ## What this does and does not settle Injection settles where the credential comes from and what the repository contains. It does not settle what happens to the value once the process holds it. The job's process environment, the address object your code is holding and anything the far side sends back are separate copies with separate fixes, and a team that has done the injection part well can still leak the credential through any one of them. Getting injection right is the necessary first step — it removes the copy that lives forever in version control — and it is worth being strict about precisely because the later copies are harder to see. ## How to describe it in an interview Say what arrives, where it is joined, and what never exists on disk: two protected variables in, one address assembled in memory, nothing written down, and a hard failure with a named variable when either half is absent. Then name the thing that makes this credential different from a token in a header — it ends up inside a string that other tools are happy to print — and say that the suite therefore has one redaction path in front of every log line.