Is it possible to merge or apply multiple config f...
# general
Is it possible to merge or apply multiple config files? e.g.: We have some shared config in
and some extra config in
. 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:, which is the general "it would be nice to have some project specific configuration that was applied across all stacks" and 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
during a
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, which would be our answer here.
@bitter-oil-46081 no, this would be orthogonal to the provider/plugin model. Suppose I've committed a
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.
It would take some design consideration though, because public key encryption is easy to mess up - just using the public key, a plaintext, and the ciphertext is not enough. A salt/nonce value as an input is also necessary to ensure that setting a secret key value pair is not idempotent.
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
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
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
argument you'd pass to these commands). Do I have the right of it there, @orange-policeman-59119?
That's exactly it.
I think that would be useful to have baked in, as a lower entry cost for users who don't need fully pluggable secret management. I'm in a HIPAA regulated business, so for my use case, we need BYO-secret-management to be able to go live with Pulumi. We're using Google Cloud KMS for that right now in a truly epic hack, but I'd like to use the Pulumi SAAS as soon as we can so that we're not dependent on epic hacks.
DM me if you're curious about the hack
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.