I prefer doing .gitignore .env + .env.example for ease of use and possibility to pass it to lambda even without a file.
SSM is great and all, but its a whole lot of setup to do a key store value, and when you need to use it in any serious manner, you need devops to add it to the stack as well.
And if this post target group is people who hardcode credentials in the codebase, i can already tell you, they wont go with the SSM hassle, for sure. ;))
Trouble maker and Problem solver ⚙️🔧
Loves simplicity, hates bullshit 💩.
Productivity obsessed, avid learner 🖥🚀
Sport and outdoor freak 🧗⛰
Metalhead 🎸🤘 Father of 2 👨👩👦👦
Opinions are my own
true! :-)
my main problem with the .env file is that even though you don't commit the file to the repo (and if you are fine with having the credentials in plaintext in the AWS Console) somehow you have to keep those credentials somewhere. where do you keep them? how do you share them with your coworkers?
i dont think SM / Secrets manager require a lot of setup. probably we are still using a naive approach but we have a couple of scripts in the package json to generate credentials and create the secrets in SSM. then we rely on serverless to handle permissions and other stuff.
When im developing a function i keep it locally (or i keep it in lambda configuration, you can pass env.* - docs.aws.amazon.com/lambda/latest/... ).
When it gets plugged into the stack (the serious approach), its prepared somehow on the fly by scripts provided by our devops inside docker container before deploying the function.
Trouble maker and Problem solver ⚙️🔧
Loves simplicity, hates bullshit 💩.
Productivity obsessed, avid learner 🖥🚀
Sport and outdoor freak 🧗⛰
Metalhead 🎸🤘 Father of 2 👨👩👦👦
Opinions are my own
I prefer doing .gitignore .env + .env.example for ease of use and possibility to pass it to lambda even without a file.
SSM is great and all, but its a whole lot of setup to do a key store value, and when you need to use it in any serious manner, you need devops to add it to the stack as well.
And if this post target group is people who hardcode credentials in the codebase, i can already tell you, they wont go with the SSM hassle, for sure. ;))
true! :-)
my main problem with the .env file is that even though you don't commit the file to the repo (and if you are fine with having the credentials in plaintext in the AWS Console) somehow you have to keep those credentials somewhere. where do you keep them? how do you share them with your coworkers?
i dont think SM / Secrets manager require a lot of setup. probably we are still using a naive approach but we have a couple of scripts in the package json to generate credentials and create the secrets in SSM. then we rely on serverless to handle permissions and other stuff.
When im developing a function i keep it locally (or i keep it in lambda configuration, you can pass env.* - docs.aws.amazon.com/lambda/latest/... ).
When it gets plugged into the stack (the serious approach), its prepared somehow on the fly by scripts provided by our devops inside docker container before deploying the function.
Maybe your code can pass a security review that way; mine can’t. Corporate dev rules laugh at this approach.
which of the above exactly?