ACM.321 This issue can apply to any cloud provider: check where your packages are coming from on the network.
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 talked about a generic credential manager for a custom Lambda runtime and the associated risk.
What I wanted to do next was show you how we’re going to use the values stored in the Secrets Manager and mirror a GitHub repository to AWS CodeCommit. But of course, I ran into a problem. There is always a problem.
First, I had to open up my network to access GitHub from my now locked EC2 environment. This led me down a rabbit hole of Transit Gateway and GitHub prefix lists that I’ll write about later.
Next, I wanted to install a package to parse JSON more easily. I considered using the method used in the AWS Bash sample code to write a temporary file and parse the values. However, you then have temporary files containing credentials. And no one wants that. Maybe you delete the temporary files when you’re done, but what if an error occurs before the delete command? If the temporary file is in the /tmp directory, it can remain between invocations.
I decided to install jq. This particular package hopefully allows us to parse JSON more easily (although I still find it complicated and wrote my own Python parser…but I’m not using Python here.) This particular package is risky if it is compromised because it can potentially access any value you have. we remove JSON strings. So we want to make sure that we’re getting the legitimate package from a legitimate source, right?
We get it from AWS via a Yum command, so it should be fine, right?
Well, I’m running a yum install of a package called jq in a container in an AWS network that has an S3 endpoint for private access to S3 for yum updates. I only want these updates to come from the region I’m in…