I have a few questions for the folks at Pulumi so I'm going to create a couple threads 😅 First: What is the data flow for secrets? 1. The user encrypts the plaintext secret using a Pulumi CLI command, which places a ciphertext in the YAML file. 2. The Pulumi CLI encrypts the secret by ...? (obtaining a key from the server, or transmitting the plaintext to Pulumi?) 3. The cipher used is a symmetric (?) block cipher (AES-?) or an asymmetric cipher?

Great questions - and sorry for the delay getting back to you! First thing to note, we are currently making some significant changes and improvements in this area - so some of what I say below is point-in-time. We're definitely interested in feedback in this area. Today, there are two "backends" for the

pulumi

CLI - the default pulumi.com backend (which manages state and secrets at pulumi.com), and an optional local backend (which manages state and secrets locally on the developer machine). The pulumi.com backend manages keys on the server (currently using AWS KMS), with per-stack encryption keys. Config secrets are sent in plain text (over HTTPS) to the pulumi.com backend. On the backend, we currently use AES256GCM to encrypt values with the stack key. The local backend manages keys on the client machine using a passphrase + salt. This also uses AES256GCM, but with a key derived using pbkdf2 from the passphrase provided on each invocation of the

pulumi

CLI (or from environment variable). You can see the core implementation of these at https://github.com/pulumi/pulumi/blob/dee2c37d9d053ff6b9291e2256308925a386bdef/cmd/new.go#L772-L782 (and in the implementations of the two functions referenced there for each of the two backends). In terms of upcoming changes: * In the very near term, we will add the ability to use a local-passphase encryption option even when using pulumi.com for state storage. This will decouple the choice of using pulumi.com to manage state and to manage encryption. See https://github.com/pulumi/pulumi/issues/1867. * In the slightly further (but still near) term, we will be adding the ability to use a pluggable secret store - so that the acquisition of secret values can be done entirely outside of Pulumi - for example, secrets stored in AWS Secrets Manager could be used as a source of values for a config setting, and the client machine would make calls to Secrets Manager when it needed to access the values for use in doing a deployment (using the AWS role/credentials provided for deployment on the local machine as normal). See https://github.com/pulumi/pulumi/issues/1547.

Thanks @white-balloon-205, is the time scale for the very-near-term weeks, months, quarters?

We will be implementing these changes within the next four weeks.

🙌