The web console (in Activity / Changes, for the “Diff” and also the file obtained via “Down stack checkpoint”) shows the raw output of each state change ,which including things like plaintext passwords, even for things marked as secrets. The “Resources” view correctly identifies these as encrypted (as per https://www.pulumi.com/docs/intro/concepts/secrets/)

i think you should be able to use pulumi config set --secret to store your secrets as ciphertext. didn't look at the thread so not sure if you have already tried this.

If you pass the input to

Secret

as a pulumi secret it will not be stored in plaintext. So like:

const cfg = new pulumi.Config()
const param = new aws.ssm.Parameter("a-secret-param", {
    type: "SecureString",
    value: cfg.requireSecret("my-secret-value"),
});

Will never be stored as plaintext in the checkpoint file. You can also use your own secret provider and the service will never have access to the decrypted secret.

Thanks you @red-match-15116 - I’m aware of Pulumi secret config and also using an external service for performing the encryption (indeed, the example above is doing the latter). This isn’t quite what i’m looking for however. I seem to be doing a very poor job explaining what I’m asking! Let me try again

What I want is to avoid placing my secrets in Pulumi at all, regardless of whether Pulumi is able to decrypt them or not

Yeah, that's not possible unless you use self-managed or self-hosted as you described above.

Thanks for confirming @red-match-15116. I’ll raise a feature request for this, as it would be sad to miss out on the benefits of using the Pulumi managed backend due to this. Rationale: Creating an encrypted/secret config entry to avoid plaintext secrets from being sent to the backend (as part of the checkpoint data) is an undesirable workaround when you consider that the Pulumi backend doesn’t actually need the secret at all. A better solution is to not send the secrets to the Pulumi backend at all, minimize the attack surface/audit surface. Also, the secrets themselves may be rotated (i.e. auto key rotation on AWS secretmanager) and so the encrypted secret that Pulumi holds in state will be stale anyway and so not even useful for “has this changed?” purposes (I tested this out to confirm the behaviour). The feature request is therefore something like (BDD style): “as a devops user, I want to use the Pulumi managed service for managing my cloud infra state without sharing any plaintext or encrypted secret values that are not required to be held by the service to manage that state”

Could you provide an example of the request above? In your example using an SSM Parameter, the actual secret value is “part of the state” in that if you modify the underlying secret value, then pulumi should detect the diff and update that value. You could choose not to manage that part of the state via pulumi and purposely have it drift from state via

ignoreChanges

and feeding in an initial dummy value that you later change out of band of Pulumi.

Rationale: Creating an encrypted/secret config entry to avoid plaintext secrets from being sent to the backend (as part of the checkpoint data) is an undesirable workaround when you consider that the Pulumi backend doesn’t actually need the secret at all.

The Pulumi backend does need the secret if you are creating the secret in Pulumi because it is part of the `Secret`'s state. It also needs the secret if you are passing it as an input into another resource (because it is part of that resource's state). If you are using Pulumi to manage your state, it seems inconceivable that it wouldn't need your secret in some form - since that secret is inherently part of the state that you are asking Pulumi to manage.

I wasn’t aware of

ignoreChanges

@faint-table-42725, thank you for flagging that, it is certainly useful here.

Is this operation ever invoked as part of another command or only ever explicitly?

Refresh is only ever called explicitly or by setting a Pulumi.yaml config setting to always refresh on update. Your approach sounds reasonable to me!

Thank you both very much, your help has been invaluable!