security is typically "an onion", so it's a matter of how much hardening that you want. if you store the credentials as lambda, then anyone who can view the lambda details can gain access to those credentials - is that fine for the environment that you work in? if you have a few people with a high amount of trust, then that might be fine.
there's also the notion of bad/rogue actors to consider - just because you're in a private vpc doesn't really mean that no one can connect to it. if someone gains access to an ec2 instance that can reach the database server - how much more work do they have to do to get at your data? if the credentials are in environment variables, probably not a lot.
what if you start VPC peering - do you fully trust all of the other VPCs you're peered with to not be compromised?
what if one of your devs had their laptop stolen and their access keys are on there? could an attacker launch an ec2 instance, connect to it, then access your DB?
some people go through to the lengths of putting fake credentials in environment variables; then they up the logging on the RDS instances to record login failures. steam that to lambda, and if you find a failed login attempt, you can then search your instances/lambda for where those credentials (login name) are in the environment variables and hibernate that compromised resource. sort of like a honeypot. to me, that sounds like a lot of wasted time for most scenarios, but for highly sensitive or critical systems, it might be worth it.
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
thank you very much for your detailed comment. of course as almost everything in programming it depends on the specific use case and requirements.
I like the example of security as an onion and reminds me of the swiss cheese paradigm. ( every layer of security might - and will - have holes. we must be sure these holes don't align ).
The last part of your comment is also somehow similar to what described in the AWS Security Workshop i attended at the Serverless Days i blogged about here.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
security is typically "an onion", so it's a matter of how much hardening that you want. if you store the credentials as lambda, then anyone who can view the lambda details can gain access to those credentials - is that fine for the environment that you work in? if you have a few people with a high amount of trust, then that might be fine.
there's also the notion of bad/rogue actors to consider - just because you're in a private vpc doesn't really mean that no one can connect to it. if someone gains access to an ec2 instance that can reach the database server - how much more work do they have to do to get at your data? if the credentials are in environment variables, probably not a lot.
what if you start VPC peering - do you fully trust all of the other VPCs you're peered with to not be compromised?
what if one of your devs had their laptop stolen and their access keys are on there? could an attacker launch an ec2 instance, connect to it, then access your DB?
some people go through to the lengths of putting fake credentials in environment variables; then they up the logging on the RDS instances to record login failures. steam that to lambda, and if you find a failed login attempt, you can then search your instances/lambda for where those credentials (login name) are in the environment variables and hibernate that compromised resource. sort of like a honeypot. to me, that sounds like a lot of wasted time for most scenarios, but for highly sensitive or critical systems, it might be worth it.
thank you very much for your detailed comment. of course as almost everything in programming it depends on the specific use case and requirements.
I like the example of security as an onion and reminds me of the swiss cheese paradigm. ( every layer of security might - and will - have holes. we must be sure these holes don't align ).
The last part of your comment is also somehow similar to what described in the AWS Security Workshop i attended at the Serverless Days i blogged about here.