I got some issues with a few things Pulumi does be...
# general
f
I got some issues with a few things Pulumi does before we can actually start migrating over, I am hoping I could get some eyes on this and maybe even suggestions. I am not comfortable with secrets stored in the repo. Encrypted or not. We do store the secrets on Github, but not in the repo, but as Github Action secrets. In fact, we also store configs there ( but not as secret). In the future we would like to store our configs as an .env file and read that into the CI. Is there a way Pulumi could work without config and secrets being defined in the stack.yml file?
f
You could store them in vault or another provider like that and input reference by name as config
Then use the provider and get that value at runtime for that secret
f
@future-barista-68134 I actually like them where they are - as secret env variables in Github. I guess I can just use
process.env
to read them. Then there are secrets generated by Pulumi, like RDS password. That’s fine, that can stay with Pulumi. Out of curiosity, I don’t actually have to save the db, right? Pulumi does that for me when creating the RDS instance and each time I call pulumi up it will use said password for my Pod spec, right?
f
I guess I can just use
process.env
to read them.
Yes this is a good option if you don’t want to use the Pulumi managed config. You could also drop in your own file at runtime and read from it.
each time I call pulumi up it will use said password for my Pod spec, right?
That’s correct. Pulumi keeps track of the inputs for resources in the state file. Pulumi encrypts this in transit and at rest but there are options to manage that yourself. See: https://www.pulumi.com/blog/managing-secrets-with-pulumi/.