Part of my series on Automation of cybersecurity measures. Lambda. Internet Security. GitHub Security. Container security. Deploy a static website. THE Coded.
Free content on Cybersecurity Jobs | Register at Broadcast list
In the last article, I figured out why my requests to AWS services after deploying the VPC Endpoint deployment were excessively slow and fixed it.
Before I finish my AWS Secrets Manager solution, I need to fix my error handling because it only works for a single line of code. Oops. And let’s just say it wasn’t easy. But if it works, it will save me a lot of time in the future and can easily be integrated into every container that uses my Bash runtime. Warning: I’m sure I’ll find and fix more errors in the future, but this seems to work and here’s the short version of the problems I encountered along the way.
TLDR;
* Set some bash flags to make sure your error messages show up where intended
* AWS CLI seems to be redirecting standar error to standar out
* For other bash commands you would need to do that yourself if did this another way
* That means you'd need to know if you were handling an AWS CLI command or a bash command.
* Try to abstract your error handler out to a single function call as I did here.
* A single function call to a standard function reduces errors.
* If you pass variables between Bash files, pass them via TMP files.
* Something was setting certain variables (like one containing my request ID) to an empty string for some reason not in my code.
* Handling strings with multiple quotes is very, very tricky.
* Make sure your error messages do not have quotes in them.
* A divide by zero error is a good thing to test.
* The difference between an initialization and an invocation error is the request id.
* If you have any errors in your error handling, the message won't get back to the Lambda function.
* Local testing is good.
* sts get-caller-identity is not working in Lambda
* Using temporary credentials for testing is not perfect, but reduces…