> To specify an AWS KMS CMK, use the KeyId par...
# aws
f
To specify an AWS KMS CMK, use the KeyId parameter. The default is the AWS managed CMK for your account, aws/ssm.
It sounds like it uses a default one if not supplied.
b
yeah it'll use the pre generated key for the account
f
Thanks. Do you think it’s a bad idea to store both secrets there as well as relying on Pulumi?
b
what are the secrets?
db password?
f
Passwords for Redis, Postgres, AWS tokens for S3 uploads, Admin Dashboard passwords and default user account passwords, tokens for CLI to tweak app settings.
b
it's generally good practice to store those kinds of things in SSM. if you could give a little more info about how you plan to use them, I might be able to help a little more
f
Well, right now all secrets are generated by Pulumi and stored by Pulumi. tls.PrivateKey.privateKeyPem  RDS password ElastiCache password Admin passwords Tokens for Secure CLI access etc And they are stored by Pulimi and hopefully as secrets. So far we haven’t had a need to create a secret and store it by pulimi, but if we ever do, that feature doesn’t exist and we have to use parameter store. And I hate the idea of having secrets spread out. Read more https://pulumi-community.slack.com/archives/C84L4E3N1/p1615294554106700
So I was thinking of just relying on Parameter Store, but there are some stuff that will still be stored by Pulumi but parameter store is the default place. E.g password generation and TLS Private Keys will be created (and probably stored) by Pulumi, I can’t help that.. But I can make sure it’s replicated to AWS parameter store as a single source of truth (and backup) as well.
b
that all makes sense, and is a common parameter store pattern. All you need to do is think about if you're okay with the default CMK (which generally is wide open for use within the account) is okay, or you'd rather generate a dedicated key
f
Yeah will use the same CMK but restrict access per param based on prod/staging/dev-env-*/ephemeral-pullrequests.