Revisiting The Generic Lambda Function Objective

ACM.346 Create a Lambda function to push changes in CodeCommit to an S3 bucket — The Function

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

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

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

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

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

In the last post I was exploring AWS CodeCommit triggers. Before I go through the exercise of trying to use a new thing I want to see if it’s even going to work. I think it will but the documentation is a bit confusing.

In this post I want to deploy a Lambda function that copies code from AWS CodeCommit to S3 when a new code gets pushed to a repository.

Recall that I already have deployed a repository and showed you how to create Lambda functions that use containers in this series. I also created a bash custom runtime for Lambda and I’m going to use that for this function.

First, I create a new folder for my new lambda function. I name it:

CodeCommitToS3

I copy the deploy file from the dockertest lambda container experiment and rename the function in it.

Recall that I changed deploy_lambda_policy to deploy_app_policy while testing AWS Batch since both could deploy a generic role that has access to a secret with the name name as the Batch Job or Lambda function. I need to modify the name in the script above and in the dockertest Lambda function deployment script while I’m at it. I’m going to set secret to false because this function does not need a secret in AWS Secrets Manager.

But recall that I was not able to assume a role in the Lambda function, though I don’t see any documentation that is disallowed:

I’m still wondering if I did something wrong or if that is a temporary glitch. But for now I’m going to presume it’s not allowed. The credentials from the Lambda function work locally but not in Lambda.

Since I cannot assume a role from the Lambda role, I cannot create a generic policy to deploy with every Lambda function. I need to create a specific policy for my Lambda function with everything it needs to do in that policy. That means if I need something unique, I can’t use the generic role, without giving permission to all other Lambda functions to do the thing I want this Lambda function to do.

I need the Lambda function I’m creating in this post to be able to copy files from a repository and push them to an S3 bucket. I also want to make sure the wrong repository is not pushed to the wrong S3 bucket. That requires some thought and policy limitations or account segregation. I’m not going to get into here too deeply, but we don’t want a policy that has access to every S3 bucket in the organization that leads to something like the Capital One breach.

My current approach will be that this function will have access to specific static website repositories. It will be able to push to S3 buckets in an AWS account that is specifically used for hosting static websites. No sensitive data will exist in the S3 buckets in that account.

The function will be generic such that it can only pull from and push to a source and destination with matching (or aligned depending on naming restrictions) names. In other words, dev.rainierrhododendrons.com code must be pushed to a dev.rainierrhododendrons.com bucket.

The account will also be locked down when not being updated. I demonstrated such security controls with Service Control Policies here:

For now, the policy is going to allow access to a specific repository and an S3 bucket in another account.

I’ll create that in a future post and update the Lambda function with that policy because I ran into a bunch of other issues trying to get this function deployed.

While deploying this function I got blocked by an SCP policy that said my SandboxAdmin was blocked by a specific deny. Well, that is not exactly accurate. It could be that the policy was blocking the SandboxAdmin on MFA.

Ok so I removed the MFA restriction as a test. But the SandboxAdmin was still blocked. The only thing that was remaining in the policy was the network restriction. Lambda traffic should only be coming from a specific IP (for the console) and from specific VPC Endpoints.

This worked before and does not make any sense that it is not working now. I see that AWS was working on an AWS operational issue this a.m. and I wonder if it could somehow be related. In any case, I temporarily removed this restriction to deploy the Lambda function and restored it afterwards.

I had a problem like this the other day with the SCP in the AWS documentation that only allows specific regions. It started blocking global services.

I had to remove that regions SCP previously. Now I have reapplied it and hopefully it’s working again. I am able to access IAM, etc.

I later figured out why the SCP is failing and I don’t agree with how this is implemented. I hope AWS will fix it.

Well that took some time to sort out which slowed down this blog post.

Then something else odd happened. My trust policy, which worked fine before, didn’t work anymore. I got an error saying the role does not allow Lambda to assume it.

Here’s what my trust policy looked like:

Well, I modified the trust policy slightly to look like this:

Then it worked. I have no idea why that made a difference if it worked before.

Finally…I could deploy the Lambda function with an error that makes sense. It said that I was trying to deploy the Lambda with a container that has been deleted.

So here’s the next predicament. I was using the function name for the container name.

The problem is that I named my function with upper and lowercase letters. My container name can only have lowercase letters so I can’t make the names match if I use that.

Initially I tried to create a container name with underscores (_) between the words to make it easier to read. But you cannot have underscores in Lambda names.

I want to make sure the container and Lambda function are aligned and the only way to do that is with a completely lowercase name which is kind of ugly. But I guess that is our only option.

So I’m going to change the Lambda function name to:

codecommittos3

I also have to push a container to ECR with that same name even if it is just a placeholder. I’ll need to reconsider my order of deployment tasks for Lambda functions. Once I have a base container I can push a default to ECR during the deployment process that just prints “hello world” or something.

With that code change and a temporary container with the correct name pushed to ECR as I explained how to do in prior posts, I was able to deploy the Lambda function. Not sure why all those things that worked before started failing.

I’ll deploy the policy next and a container that clones and copies the files to S3.

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