Creating a Base Container for Lambda Functions

ACM.354 A base container with shared code and the Lambda Runtime Interface Emulator for local and in-Lambda testing

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics | Code.

🔒 Related Stories: AWS Security | Container Security | Lambda Security

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the last post, I finally resolved some issues cloning an AWS CodeCommit repository in a Lambda function.

That took way too long but part of the time was resolving network issues and part of the time I was rearranging my code to make a base Lambda container I can use for all my Lambda functions going forward.

Here’s what I did.

Container Naming Conventions

What’s annoying is that container names need to be all lowercase, and Lambda function names can’t have underscores in them. So we can’t easily align our naming convention.

In my containers folder, I initially named a container I was working on with underscores in the name like this:

code_commit_to_s3

But what I realized when I tried to deploy my Lambda function is that it couldn’t have any underscores in it. So I ended up naming the container with all lower case, no underscores to use the same name for both container and function.

codecommittos3

That is is kind of ugly but I want to make it easy to write code because the two names match and tell which containers belong to which functions in our AWS Elastic Container Registry.

I named my base container and created a matching folder for the files:

bashcustomruntime

Merge the code from prior tests

I copied and merged the files from multiple prior tests when I was creating my codecommittos3 container. I did a lot of the groundwork already while creating that container to create a base container for my bash custom runtime, so I copy all those files into my base container directory, but I’m going to remove the job-specific code.

Here’s what the root directory looks like:

Note: I explained what all these files are in prior posts. I’m just rearranging them here. You can find an explanation of all these files in these posts:

build_and_push.sh — this file calls the higher level build.sh and push.sh scripts to build the container and push it to ECR.

Dockerfile — for building the base container image.

include — a directory for common functions included in the base container.

job — a directory for the run.sh file, creds.sh, and any job-specific files. Remember that I exclude creds.sh from my git repository using a .gitignore file.

lambda — this folder contains the files for the bash custom runtime.

test-invoke.sh — test the Lambda function in AWS by calling it with the AWS CLI.

test-local.sh — test the Lambda function locally using the Lambda Runtime Interface Emulator in the container.

Include Files (Common functions shared by jobs)

The include files currently consist of the secrets.sh and validate.sh explained in these posts. This directory is for common functions used by many jobs. I could and probably will further organize it later if it starts to contain a lot more files.

These files are separate from the bash runtime as that code is specific to running a Lambda function. The include files could end up in a Lambda function, on an EC2 instance, or in a batch job, for example. They are not specific to Lambda.

Job files

The job folder will initially only contain run.sh which runs a specific job. For the moment this job will simply output some information about the current job and execution environment by printing out the headers passed into the job and it will run the env command to print out any environment variables.

run.sh

Lambda files

I moved all the following files (again, explained in other posts) to the lambda directory as they are related to running a Lambda function specifically.

The only file you may not recognize if you have been following along is the bash-runtime.sh file. I renamed the Lambda runtime interface emulator file from the blog post I started with because this is actually not the runtime interface emulator. That is embedded in the base container from AWS that we used to build our container. That file is actually creating our bash custom runtime.

The rest of the files are the same but I did a bunch of troubleshooting and revising of those files to make them work in the new directory structure. All the file paths had to be revised in any file referencing another file, as well as file paths in the Docker container.

Dockerfile

I simplified the Dockerfile by reducing redundant code. I had to fix all the file paths. It took me a while to get all the tools installed due to networking and other issues.

I’m leaving these common tools in my base container and the configuration to use the AWS CLI for AWS CodeCommit discussed in the last post.

I changed my build and push code to use the current directory name when building and pushing a container to ECR. That means I can simply run this command:

./build_and_push.sh

When I run my container, as expected, I get an error on credentials not configured.

I explained in a prior post how I get credentials from a Lambda function. To get the credentials, I can use my Lambda deployment methods from earlier posts to deploy a Lambda function using this container, grab the credentials, and populate the creds.sh file now in the job directory. That way I can perform local testing as I did before with credentials that have the exact same permissions as my Lambda function because they are session credentials for that role.

Using the base container

Now that I have a generic base container, I can use that container in my FROM statement at the top of my Dockerfile.

I can remove all the common code and just add the job-specific code.

I’ll be using this container more in upcoming posts and so will demonstrate in more detail later. We’ll also review the security of our container and see if there’s anything else we can do to further secure it.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab