https://pulumi.com logo
#general
Title
# general
o

orange-policeman-59119

02/28/2019, 10:56 PM
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.
w

white-balloon-205

02/28/2019, 11:23 PM
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
b

bitter-oil-46081

02/28/2019, 11:27 PM
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.
o

orange-policeman-59119

02/28/2019, 11:54 PM
Thanks for following up! As a follow-up question, is there a story for asymmetric encryption of secrets?
b

bitter-oil-46081

03/01/2019, 10:07 PM
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.
o

orange-policeman-59119

03/01/2019, 10:20 PM
@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.
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.
b

bitter-oil-46081

03/01/2019, 10:26 PM
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?
o

orange-policeman-59119

03/01/2019, 10:26 PM
Yes!
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
b

bitter-oil-46081

03/01/2019, 10:31 PM
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.
2 Views