Hello there! I have two security related questions: 1. If we deploy to Azure with a Service Principal, the deployment engine certainly needs to have those credentails. My question is: Is it guaranteed that those credentials are never transmitted or stored at Pulumi? So even if Pulumi was hacked, the only thing that would leak is the encrypted states and not the service principal credentials? 2. The documentation for secrets (https://www.pulumi.com/docs/intro/concepts/secrets/) details how to use an external encryption providers (e.g. Azure KeyVault) for secrets and this works obviously for inputs. But how does Pulumi handle sensitive output? Is that output stored directly to the encryption provider or will the output always end at Pulumi?

From my understanding: 1- pulumi CLI uses Azure CLI to connect to Azure so does not store anything, simply uses a token retrieved by the azure CLI 2 - outputs/your state are stored in the backend you choose. It is Pulumi by default, but you can choose other backends like an azure blob storage or your local system. In any case, sensitive data in the state is stored encrypted.

Thanks - great article! For 2) The setup I was thinking of is using Pulumi for storing the state but Azure KeyVault for the secrets. I haven't found out if secrets generated during a deployment are also stored in Azure KeyVault or if the end up in the stat file.

Hi @few-diamond-68626 , perhaps the switch

secrets-provider

is misleading. I had the same impression too, that I could use a keyvault to store our secrets. But on the contrary, the secrets-provider is actually an Encryption Provider in the sense that it uses the given Key in the keyvault to encrypt the secrets in the stack.... So, in short... the secrets end up in the stack (state) file, but will be encrypted with your key.

I can confirm that only a single key from the vault is being used - I've set up Key Vault as a secrets provider and have seen only a single key being referenced. I second the motion 🙂 to rename their stack init param to --encryption-key-provider - especially given Azure KV - which provides "keys", "secrets" and "certs".

Thanks for your answers - that clarifies a lot!