Is it possible to merge or apply multiple config files? e.g.: We have some shared config in

Pulumi.review.yaml

and some extra config in

./.deployment/Pulumi.extra.yaml

. Is that possible? This is related to the use case I described earlier of having arbitrarily many stacks (stack-per-branch). When creating what GitLab calls review apps, we may, for example, generate random credentials to inject as secrets per-stack, but we would also have a bunch of static config stored in a shared file.

It's not currently possible, you would need to duplicate the shared things into each file. One of the key things that makes this necessary currently is that secrets are stored encrypted in this file, but the encryption keys are different for each stack. So secrets cannot be shared across stacks. We are looking at a range of changes/improvements to config generally in the near future - we'll reach out as part of planning for those changes to make sure we capture your full feedback as input into this. /cc @bitter-oil-46081

Some issues to follow or comment on: https://github.com/pulumi/pulumi/issues/2307, which is the general "it would be nice to have some project specific configuration that was applied across all stacks" and https://github.com/pulumi/pulumi/issues/2445 which is related to also allowing project wide secrets as well.

Thanks for following up! As a follow-up question, is there a story for asymmetric encryption of secrets?

Thanks for following up! As a follow-up question, is there a story for asymmetric encryption of secrets?

Sorry for the delayed response, @orange-policeman-59119. Are you saying that you asking about a model where you encrypt secrets using some public key and then hand the private key to

pulumi

during a

preview

or

update

so that pulumi is unable to decode the secrets without a key you provide? We do have an issue tracking the ability to plugin in a provider that handles encryption/decryption of secrets. See https://github.com/pulumi/pulumi/issues/1547, which would be our answer here.

@bitter-oil-46081 no, this would be orthogonal to the provider/plugin model. Suppose I've committed a

Pulumi.stack.yaml

with secrets to my Git repo. I'd like an engineer to be able to run `pulumi config set --secret foo bar`without needing the symmetric key. That is, in addition to the symmetric key, it would be nice to be able to set an asymmetric key, where the public key is stored in the config file, and the private key is used by the CI/CD system or unlocked with a symmetric key.

Let me restart what I think you are asking. You'd like it if instead of using a symmetric key managed by the pulumi service when encrypting secrets, instead, you'd like to use a public/private key pair, with the public key stored in

Pulumi.<stack-name>.yaml

This means that

pulumi config set --secret

could be run by any engineer (it just needs to encrypt a value using the public key, which is right in the file) but operations like

pulumi config get --show-secrets

,

pulumi preview

and

pulumi update

which require you to actually decrypt the secret would require you to provide the private key somehow (i.e. you could imagine a

--private-key-path

argument you'd pass to these commands). Do I have the right of it there, @orange-policeman-59119?

Yes!

I believe that we think whatever solution we come up with for #1547 must make it possible for the above experience to be built somehow. It's less clear that it would end up built in, but I think a limited form that sort of hits at the above is something that would be worthwhile.