re: Where do you keep credentials for your Lambda functions? VIEW POST


Am I missing something here ? Because the AWS best practices are to put your db in a private subnet of your VPC so it can't be reached even if the credentials are stolen right? So in your article when you say'handle configuration safely' what are trying to imply? This is not to say I'm supporting being sloppy is fine. but I kinda didn't understand the use case are you worried that people sometimes use same credentials somewhere else too and it's a big compromise ? in our company we pretty much use the environment variables section in Lambda console we never had a issue and if somebody somehow gets the credentials I still have the VPC coming into the rescue


our use case was simply that we have different restapi and etls accessing the same db. or different db for different stages - accessed by lambdas from different environments. therefore we found quite messy dealing with lots of env.whatever-stage files. duplicated in multiple repos. Secretmanager solved our issues

the lambda being hacked and credentials being stolen might be paranoid, dunno. i read it / saw it in the video and struck me, therefore i mentioned it as well. :-)


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.

code of conduct - report abuse