Deploying A Generic Lambda Container Role and Policy

ACM.290 Reusable scripts for deploying Lambda roles and policies with CloudFormation

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

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

🔒 Related Stories: AWS Security | Lambda Security | IAM

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

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

In the last post, I was considering changes I need to make to my repository and code if I want to reuse single templates for my Lambda function, role, and policy.

In this post, I want to try to leverage some of those concepts to deploy a generic Lambda role and policy.

From the last post the first thing I need to do is rearrange my directory structure. I moved my existing code under a folder called POC — that includes the static website code I’ve been working through.

SecurityMetricsAutomation/Apps/POC

I created a new folder named stacks as explained in the last post and a folder within that named cfn.

SecurityMetricsAutomation/Apps/stacks/cfn

I want to put my generic Lambda function template in that cfn folder and see if I can make it work.

SecurityMetricsAutomation/Apps/stacks/cfn

That’s where I will put the Lambda template. But what about the role and policy?

A Generic Lambda IAM Role

Well the role already exists. Unless we want to add other restrictions, this is the generic role we used in the past:

One of the things I’m going to change in the above is to align the outputs with my new strategy where the name matches the ARN, if one exists, otherwise the ID, if one exists.

That will break some other things which I will need to go back and fix and test. My test scripts are sorely out of date.

A Generic Lambda IAM Policy

What about the policy? Who are we going to allow to deploy those policies? Since I’m attempting to create a generic policy that will handle common use cases, should that remain in IAM repository and code base? I’m going to move it back over there for a minute. That may change later.

Why? I already showed you how one might go about using code from other repositories such as my own, and it will be easier for people to find all the IAM code if it is in one place. I’m sure exceptions to the generic policy will come about but we’ll start with that for now. If our IAM team can come up with a generic, reusable policy, developers won’t have to have a new policy created every time they want to deploy a new process that uses Lambda functions.

We can easily deploy a role for our new function but we need a policy. The first use case is that the function needs a secret matching the process and step name. The container is going to initially use a secret to clone the code from GitHub. Yes, I know there are other options which I will write about later. The point here is that we want to allow the process to access a secret with the same name as the process and step. We’ll start with that and add more permissions later when we need them.

Here’s what the policy would look like roughly — this is not actually the policy we want and may not even work.

We want to limit access to the secret with the name of the process. We could try to calculate a secret ARN using the process name, however secret ARNs end with a unique ID not the name specified for the secret. In order to get a handle on the secret ARN we can use a CloudFormation output — presuming the secret and the policy are in the same account. We can also use the stack output for a role deployed in the same account to assign the policy to a specific role.

Presuming we use the name of the resource as the name of the output that returns the ARN or ID as I wrote about here:

Our code can look something like this:

In order to deploy the above we need to deploy our role and secret first as this policy code depends on the outputs of those stacks. I’ll work on those next. And As I’m writing this, I’m realizing that we’ll need to append the resource type to the end of ${NameParam} because we cannot have two outputs with the same name. I’ll fix that in the post where I deploy this role.

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