Automating a Lambda Perform Deployment | by Teri Radichel | Cloud Safety | Sep, 2022

September 16, 2022

2

ACM.52 Making a Lambda perform to generate a Job ID

It is a continuation of my collection of posts on Automating Cybersecurity Metrics.

Within the final put up I defined that we’re going to create a cryptographically safe job ID. We’ll generate this ID in an AWS Lambda perform. We’ll prolong this perform within the subsequent put up. That is all a part of the cloud safety structure I’ve been engaged on step-by-step.

I already defined how one can create a batch job manually within the AWS console:

On this put up we’re going to try automating our Lambda Perform with CloudFormation:

This shall be quite simple Lambda perform so we received’t want a lot of what’s listed right here:

You possibly can learn the main points of every configuration merchandise within the above documentation, however right here’s what we are going to want:

Architectures: arm64

I defined within the prior put up that arm is a bit cheaper and can work for our wants on this perform.

Code

We’ll specify the code for this straightforward perform in-line. There are alternative ways to deploy the code to your Lambda perform however I’m holding is easy for this preliminary put up.

FunctionName

We’ll give our perform a reputation.

Handler

The handler is the identify of the perform or methodology in our code that the Lambda perform initially invokes. This worth is required in our case.

You’d suppose that the worth you cross into the handler within the CloudFormation stack ought to match the identify of your code perform, however if you’re including code in-line within the CloudFormation template the worth is “index.[your function name].”

So in our case we’re going to put in writing some code with a technique referred to as “handler(occasion, context)” and we have to set this worth to “index.handler”.

Function

We might want to specify a task if the Lambda perform. That is required, although for the time being we don’t so as to add any permissions. We might want to add permissions within the subsequent put up.

Runtime

The runtime doesn’t look like required in our case, however we are going to specify it anyway. We wish to use the most recent model of Python.

VpcConfig

I defined how a VPC Configuration could also be helpful for safety causes in a previous put up on LambdaNetworking, however we’re going to go away this off for the second.

KMS and Atmosphere variables

I’m not going to make use of atmosphere variables right here so we don’t want a KMS key, however one of many issues I test for on cloud safety assessments and pentests is uncovered atmosphere variables. When you use atmosphere variables, use a KMS key to encrypt them and prohibit entry to the Lambda function.

Create the Lambda Function

Step one shall be to create our Lambda function. We already created a Lambda function template for this objective so we are able to simply reuse that:

We will replace our deployment script for roles with the next command:

lambdaname='GenerateBatchJobId'
deploy_lambda_role $lambdaname $profile

Now run the deploy script:

./deploy.sh

Recall that this CloudFormation creates a task with a belief coverage that permits a Lambda perform to imagine the function.

Create the Lambda Function Coverage

Our job wants a coverage, even when clean so we’ll create that and add it to our Lambda folder.

Navigate to the folder the place we’re creating Lambda features and create a brand new folder for our batch job:

mkdir GenerateBatchJobId

We will copy the code from our different batch job and modify the permissions to save lots of time.

mkdir GenerateBatchJobId/cfncp TriggerBatchJob/cfn/TriggerBatchJobLambdaPolicy.yaml    
GenerateBatchJobId/cfn/GenerateBatchJobIdPolicy.yaml

Edit the brand new coverage to take away the permissions in it we don’t want. The attention-grabbing factor right here is that we don’t want any permissions but for this Lambda perform however we have now so as to add a press release to our coverage.

What can we do? Add a deny all coverage assertion.

Copy the deploy script from our present job to the brand new batch job:

cp TriggerBatchJob/deploy.sh GenerateBatchJobId/deploy.sh

Edit it and add the brand new coverage deployment code.

Python code to generate a random job id

Now we are able to add some code to our python perform. I wrote about making a cryptographically safe random worth for our job ids within the final put up.

Fortunately the Python documentation has a code pattern for precisely what we have to do:

https://docs.python.org/3/library/secrets and techniques.html

The warning on the finish warns us to by no means retailer passwords in plain textual content. What we’re creating right here is transfer of an ID than a password however it’s used to get right into a system. Extra on that suggestion to comply with.

We will put the next code right into a take a look at file with a .py extension:

Take a look at the code few instances and sure, it does produce a random worth:

CloudFormation Template

Subsequent we are able to create our CloudFormation template to deploy our job.

Be aware that there are a number of methods to deploy Lambda recordsdata. We will put the code inline inside our CloudFormation template. We might create a zipper file with the code init. Alternatively we might create a docker container. I’m going to begin with the only method for now. I’ve added the Lambda code to my CloudFormation template. Usually I might suggest one of many different choices to separate utility code from infrastructure code.

Right here’s our template:

Deployment script revisions

Add a deployment script to deploy our Lambda perform and function

Is the above code going to deploy efficiently? No. Why not?

Who’s allowed to deploy Lambda features?

We’re utilizing our IAM profile which is simply allowed to deploy IAM assets. So we’ll want to consider who, in our group we wish to have the ability to deploy utility code resembling Lambda features and Batch job code.

We might add this permission to our builders group since they’re those writing the code. However what is going to we do once we get to the QA and manufacturing environments? We would wish a separate script so as to add the function to QA in a QA atmosphere and Prod customers in a prod atmosphere if you happen to resolve to permit any customers to manually run CloudFormation stacks.

A greater method: Outline a task that’s allowed to deploy purposes, and deployment permissions for utility code. That manner you may enable completely different individuals to imagine the function in several environments. You may not enable anybody to imagine the function in manufacturing in any respect. You may need a deployment system that makes use of that function as an alternative.

Hopefully as soon as the code leaves manufacturing the deployments are automated and use the function with out human interplay, but when we’re requiring MFA to permit the deployment to proceed, the QA workforce would supply these credentials in a QA atmosphere. An ops workforce might present the credentials in a manufacturing atmosphere.

If the ops workforce can not change the code however solely execute deployment jobs, that may stop assaults such because the Photo voltaic Winds breach as a result of hopefully your QA workforce would observed the inserted code through the testing course of and the integrity of the code will be checked finish to finish because it flows by your software program growth lifecycle (SDLC).

Right here’s the place I completely different from what I contemplate an insecure method to DevOps by some who argue concerning the definition. To me having Dev and Ops imply the identical workforce that writes the code deploys the code in manufacturing is a safety nightmare ready to occur. There are the reason why this segregation of duties exists in lots of safety requirements. It is also frequent sense if you happen to cease to consider issues like insider threats and stopping inadvertent errors.

My definition of DevOps: You write code to automate your operations and deployment features. This automation happens in a growth atmosphere. It’s validated and examined in a QA atmosphere by a QA workforce. It’s utilized in a manufacturing atmosphere by an operations workforce.

You take a look at your deployments in QA in such a fashion that QA can’t change any of the code to ensure your deployment code works. You may additionally take a look at your deployments in a staging atmosphere that matches manufacturing to make sure your manufacturing deployment isn’t going to fail as a result of some configuration in manufacturing that wasn’t in QA.

By the point the code is able to deploy in manufacturing you realize it would deploy efficiently. It’s also possible to confirm your code hasn’t modified from the purpose it left your growth atmosphere to forestall safety incidents just like the Photo voltaic Winds breach.

Utility Deployment Permissions

Let’s say we’re going to identify the cli profile “appdeploy” and add that to our code for now. We’re additionally going to vary the “service identify” to AppDeploy. I don’t know if service identify is the appropriate time period for this prefix on our CloudFormation stacks. Maybe it must be “group identify” however in any case it’s a set of stacks associated to a sure group that’s allowed to deploy them.

Create a task for utility deployments

What’s the best approach to create a brand new function for utility deployments? We will create a brand new group and function with just a few traces of code. Assuming we’re in a growth atmosphere now we add the developer to the brand new group.

Within the IAM listing construction, navigate to the group deployment script.

Add a line so as to add a brand new group and three traces so as to add the consumer to the group.

Create a Coverage for the group so it may well assume the brand new group function:

Within the function deployment script add one line so as to add the brand new function.

Create a coverage for the function that permits deployment of AppDeployment CloudFormation stacks. The identify might want to match what our generic deployment stacks anticipate which is the function identify with “GroupRolePolicy.yaml” on the finish.

AppDeploymentGroupRolePolicy.yaml

Run the deployment scripts in every listing.

./deploy.sh

Issues with AWS CloudFormation, Bash and Parameter-Overrides

I’ve written earlier than about having issues with areas, bash, and parameter-overrides right here:

I additionally wrote about how somebody has been attempting to sabotage the search engine rankings of that put up for no matter motive and the way I’m attempting to repair it right here:

One thing odd occurred whereas testing my code for this put up. After I tried to create the brand new IAM assets above, I began getting errors with code that has been working up until now. I take a look at all of the code earlier than I test in and made no adjustments to that code so why was it failing now? Did somebody at AWS make a change? Or did I actually simply not see this blatant error all the opposite instances I examined?

Who is aware of. I simply wish to stop it sooner or later. With the intention to guarantee all my code associated to parameters works precisely the identical manner throughout the board, I created a brand new shared perform. No matter change I made whereas testing another change to the shared features broke different features that had been passing in parameters in a barely completely different manner.

The perform creates the parameter string which will get handed into the perform that deploys a CloudFormation stack:

I put this in my shared_functions.sh file I wrote about in an earlier put up on this collection so it’s already mechanically included in my deploy.sh file.

I add parameters to the parameter string like this now:

Then I take advantage of that string like this when creating my stack:

I removed the deploy_iam_stack perform I left in to maintain my code functioning. That was partly, the supply of the error. I needed to change all my deployment stacks to cease utilizing that and use the frequent stack deployment perform as an alternative in my frequent features file.

I nonetheless have to revise the way in which parameters are handed in just a few locations. However for now, my app deployment function and including customers to it’s working now.

Confirm the IAM deployment

Confirm that each one your assets had been created efficiently.

Person Group named AppDeployment
Developer is within the consumer group
The AppDeployment group has a coverage with the anticipated permissions
AppDeployment function exists
AppDeployment function has the anticipated coverage

All the time confirm your deployment. That is the place I discovered I had the errors I didn’t initially see that I simply wrote about and some others that I needed to repair.

Arrange the brand new CLI profile.

Now arrange the function profile as defined in prior posts so our Lambda deployment can assume the brand new function. I wrote about that right here:

Deploy the Lambda Perform

Now we are able to try and run the Lambda deployment script. When you’ve got arrange your AWS CLI profile appropriately with a coverage outlined as above you’d see this error subsequent:

Our Lambda perform function wants the iam:PassRole motion. What’s that? That may be a complete subject for an additional put up. For now, I’ll simply point out that you have to be very cautious and express when granting permission to cross roles to compute assets. For now, return to the AppDeploy coverage and permit that function to cross the Lambda function to the Lambda perform.

Take a look at our Lambda Perform

Now you may return to the console and take a look at your Lambda perform the identical manner we did on this prior put up and see that sure, our code generates a random ID.

Contemplate the method

Now, you could have been in a position to log into the console and rapidly drop in some code and deploy this Lambda perform. However what we’ve carried out all through this collection isn’t just “construct issues” however to consider how we are able to construct, deploy, and function our purposes securely in a cloud atmosphere. That takes superior preparation and thought over and above writing the code itself.

I’m not carried out with this Lambda perform. Merely deploying a code isn’t that helpful. I’ve a motive for producing this code. Comply with for updates.

Teri Radichel

When you appreciated this story please clap and comply with:

Medium: Teri Radichel or E-mail Listing: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests providers through LinkedIn: Teri Radichel or IANS Analysis