This message was deleted.
# generals
sparse-intern-71089
07/08/2022, 7:33 PMThis message was deleted.
b
billowy-army-68599
07/08/2022, 7:37 PM
lots of options here, putting secrets in Secrets Manager is a good idea.
• you can still store the secret in Pulumi config
• You would then store that secret in secrets manager using
SecretsVersionbillowy-army-68599
07/08/2022, 7:37 PM
I can maybe put an example together for you using something like wordpress if that helps?
c
crooked-laptop-67565
07/08/2022, 7:39 PMAn example would be super helpful 🙂
Re: "how are you running your app" it's primarily going to be running on EKS, though I expect we might end up with some vanilla EC2 instances as well, at least when doing testing and dev.
crooked-laptop-67565
07/08/2022, 7:48 PMRegarding using SecretsVersions - it sounds like in that case the secret starts off in Pulumi's config and then is put in SM. I was thinking of using SM as the canonical/originating source for secrets, because it also solves the problem of having a system that people can look at to see what the secrets are - eg if I need to give an engineer the database credentials so they can connect locally. Secrets could still go into Pulumi's config for doing Pulumi things, but the canonical home would be SM. Though I don't know if that's a good idea
crooked-laptop-67565
07/08/2022, 7:49 PMOh I just remembered that Pulumi's config files are encrypted and get checked into Git. So the secrets could safely start off in Pulumi and then be put in SM...
b
billowy-army-68599
07/08/2022, 7:53 PM
@crooked-laptop-67565 something I often advocate for in these situations is using pulumi-random to generate a password per stack, sotring that in secrets manager and then having users who need that password grabbing it from there or from the Pulumi stack output, as it'd audited that way
c
crooked-laptop-67565
07/08/2022, 7:57 PMOh I like that idea
b
billowy-army-68599
07/08/2022, 7:58 PM
2 Views