How does Pulumi keep secret values out of plaintext in stack config and in state, and what is a stack's "secrets provider"?

## The problem Every infrastructure tool eventually has to hold a database password, an API token or a TLS key — first as an input you set, then as a value recorded in whatever the tool uses to remember what it built. Pulumi's position is that both places are encrypted by default rather than plaintext-with-a-warning, which is the main reason this topic comes up in interviews. ## Marking a value secret There are two entry points. From the CLI, `--secret` on config: ```bash pulumi config set --secret dbPassword 'hunter2' pulumi config set dbUser app # not secret ``` The resulting `Pulumi.dev.yaml` looks like: ```yaml encryptionsalt: v1:AbCdEf...:v1:... config: myapp:dbUser: app myapp:dbPassword: secure: v1:9zQ...:ciphertext... ``` Because only ciphertext lands in the file, the stack config file is committed to the repository like any other source. From inside the program, `pulumi.secret(value)` wraps a computed value, and reading a secret config key returns it already marked (the config API has explicit "secret" accessors for this). Either way, the engine now knows this particular value is sensitive. ## Secretness propagates This is the part candidates most often miss. Pulumi's values are `Output`s, and secretness travels along the dataflow: if a secret feeds an `apply`, a string interpolation over Outputs, or a resource argument, the result is secret too. Consequences: - In previews and `pulumi up` output, the value renders as `[secret]`. - In the **state checkpoint**, the property is stored encrypted, not in the clear. `pulumi stack export` emits a JSON document in which those properties are ciphertext. - Outputs exported from a secret are themselves secret, so `pulumi stack output dbPassword` refuses to print it unless you pass `--show-secrets`. The escape hatches are the obvious ones: if you pull the value out of the Output system into a plain string and log it, print it, or feed it to a provisioner-style command that echoes it, nothing protects you afterwards. Encryption at rest is not the same as never being observable. ## The secrets provider The secrets provider is the key material used to encrypt the stack's secrets. It is set when the stack is created: ```bash pulumi stack init prod --secrets-provider="awskms://alias/pulumi-prod?region=eu-west-1" pulumi stack init dev --secrets-provider=passphrase ``` The options in practice: - **Pulumi Cloud (default when logged into the service).** The service manages a per-stack key; access follows your Pulumi Cloud permissions, and nothing extra needs distributing to engineers or CI. - **`passphrase`.** A key derived from a passphrase you supply, with the salt recorded as `encryptionsalt` in `Pulumi.<stack>.yaml`. Every place that runs `pulumi` must have `PULUMI_CONFIG_PASSPHRASE` (or `PULUMI_CONFIG_PASSPHRASE_FILE`) set. Simple, and the usual choice for a self-managed backend — but the passphrase is a shared secret you now have to distribute and rotate, and if it is lost the stack's secrets are unrecoverable. - **A cloud KMS key** — `awskms://`, `gcpkms://`, `azurekeyvault://`, or `hashivault://`. Pulumi stores the provider URL and an encrypted data key in the stack file; the decryption right becomes an IAM/policy decision on that key rather than a string in someone's password manager. This is the strongest option for a team on a self-managed backend, because you can audit and revoke access to the key. A stack can move between providers later with `pulumi stack change-secrets-provider`, which re-encrypts the stack's secrets under the new key. ## Revealing values on purpose ```bash pulumi config get dbPassword --show-secrets pulumi stack output connectionString --show-secrets ``` Both exist because you sometimes genuinely need the value — but they are also how secrets end up in CI logs. Treat `--show-secrets` in a pipeline as something that needs a reason. ## Where this leaves you in an interview The crisp summary: *marking* is per-value and sticky, *encryption* covers both the config file and the state checkpoint, and the *secrets provider* is the pluggable key behind both. The follow-up worth anticipating is what happens when the key is lost or the value leaks — the ciphertext protects the file, but a value that was ever committed in the clear must be rotated at its source, because re-encrypting the config does nothing about copies already in the repository's history.