I'm not really finding anything on this through do...
# general
v
I'm not really finding anything on this through docs and after digging through the source a bit. If I don't want to store the config in the repositories but do want to store them with the run, is there a reasonable way to approach that? My current thinking is in CircleCI, running
pulumi config refresh
to pull the config down from Pulumi - or maybe
pulumi config set
for every value in the config from environment variables. Are there any other approaches?
f
Is there a reason to not keep the config file in source? I know this is somewhat of an anti-pattern, especially if there are secret values there. To remedy not having sensitive data in your repo when using config, pulumi enables you to use encryption. Any values that are marked as secret using the
--secret
flag when setting config are encrypted. You can setup the encryption provider of your choice (KMS, Vault, etc). For more info see: https://www.pulumi.com/docs/intro/concepts/config/ and https://www.pulumi.com/docs/intro/concepts/programming-model/#secrets. Alternatively, since pulumi code is authored using real programming languages, you can expect and read environment variables directly, without using the pulumi config system. I’m sure others have insight on this as well 🙂
note if you use environment variables for secret values and you want to encrypt those values in the state file you want to mark those values as secret.
v
Is there a reason to not keep the config file in source? I know this is somewhat of an anti-pattern, especially if there are secret values there.
I suppose not, aside from it being an anti-pattern 🙂 We follow twelve-factor app patterns everywhere else, and aiming to here, as well. Using Kubernetes as an example with Helm - the way we'd operated before was that the secrets & configuration are injected once & not stored in source control. Per the secrets - definitely helpful to have encrypted them. Not even that concerned about people having access to the secrets if they're encrypted, I s'ppose - at least, not with my current role. Previously, even encrypted secrets being committed into source control meant we'd be required to rotate that secret - financial folks sure are picky about that kinda thing.
Alternatively, since pulumi code is authored using real programming languages, you can expect and read environment variables directly, without using the pulumi config system.
Definitely can! I really like what Pulumi does here, and I did notice this. It was quite nice at first - but the problem I ran into with it was that it wasn't being reflected in Pulumi itself when I wanted to see how the deployment had occurred. Hence the idea to read them and run
pulumi config set
for them so it would get reflected on the stack.
f
Another option that comes to mind is to use
.get
functionality and retrieve your secrets from ssm, vault, etc. Then only simple config would live in the Pulumi.stack.yaml.