Situations and Mappings in CloudFormation Templates | by Teri Radichel | Cloud Safety | Aug, 2022

August 17, 2022

2

ACM.32 Stopping the Confused Deputy Assault in Batch Job Roles

This can be a continuation of my sequence on Automating Cybersecurity Metrics.

I wrote concerning the Confused Deputy Assault within the final publish and the way it may have an effect on the Batch Job Position we created with the choice to move in any ARN.

We are able to repair this drawback by limiting our position template to creating roles for IAM-related batch jobs that may solely be assumed by our IAM administrator and batch job roles for information processing that may solely be assumed by our Batch Job Administrator.

Take away the ARN parameter.Add a batch job kind parameter.The batch job kind parameter can solely have two values: batch or iam.If the worth handed in is batch, our position identify may have a batch prefix and solely batch job administrator will likely be allowed to imagine the position.If the worth handed in is iam, our position identify will begin with an iam prefix and solely the iam administrator will likely be allowed to imagine the position.

Refactoring the code

Only a reminder, the code we’re modifying is the generic batch job position we modified on this publish to permit an IAM administrator to imagine a batch job position in addition to a Batch Job administrator.

Take away the ARN parameter

First we wish to take away the arm parameter. That’s simple.

Add a brand new batch job parameter with allowed values

Subsequent we wish to add a batch job kind parameter, however we solely wish to permit somebody to move in one among two values: iam or batch.

We are able to try this with the AllowedValues attribute of our parameter which permits us to specify the values that CloudFormation will settle for for the parameter. From the documentation:

Format:

So we’ll create our new parameter like this:

Including circumstances to our CloudFormation template

Subsequent we have now wish to set values conditionally primarily based on the worth handed into the batchjobtype parameter. We are able to use AWS Situations for this function:

When you have a look at our present template it has a Parameters and a Sources part.

To make use of circumstances we’re going to add a Situations part.

We are able to use various kinds of circumstances in a CloudFormation template and all of them besides the If perform go within the Situations part of the template.

Setting values primarily based on Batch Job Sort with situation features

We are able to use CloudForamtion’s Equals situation to find out if the batch job worth matches batch or iam:

Then we will use the If situation to set a price primarily based on whether or not the parameter equals a sure worth:

We’ll add the Equals situation within the Situations part of the template. Then we’ll reference that situation in our If statements later.

Utilizing circumstances to set the position identify

We’ll begin with the position identify. We’re going to vary the present worth for RoleName however we’ll proceed to make use of the jobnameparam on the finish of the rolename.

If we wished to make use of circumstances to set the position identify we may create circumstances like this:

Then we may later use an If assertion to set the position identify primarily based on whether or not the Situation IAM job equals true or BatchJob equals true. Let’s factor about how that will work a bit extra.

Later in our template after we wish to set the position identify we may use this:

We may write one thing like this the place we’d calculate the right ARNs like we did earlier than:

!If [IAMJob, '*IAM administrator ARN*', '*Batch Administrator ARN*']

The primary query is, will we wish to assume that if it’s not the IAM admin then it’s the Batch job admin? Perhaps we wish to be extra particular with one thing like this: (pseudo code I haven’t examined):

!If [IAMJob, '*IAM administrator ARN*', !If [BATCHJob, '*Batch administrator ARN*','ERROR']

However what if we wish to add different forms of batch jobs sooner or later with totally different ARNs that may assume the roles for these batch jobs? Now our code is beginning to really feel not so good. Typically that is known as “code scent.”

There’s one other assemble in CloudFormation we will use to unravel this drawback.

CloudFormation Mappings

CloudFormation has the idea of mappings that allow you to map one worth to a different worth that will likely be utilized in a template.

Mappings can be a separate part of the template like Parameters, Situations, and Sources. The format in yaml appears like this:

We are able to create a mapping for our batch job roles with a number of values for every mapping. I’m simply utilizing placeholders for the values proper now:

!FindInMap [BatchJobRoleMap, !Ref ${batchjobtype}, rolename]

We reference our mapping desk, lookup the mapping that matches our batch job kind parameter worth, and get the position identify.

First, repair the position identify within the mappings. Set the position identify to the present position identify within the template however change the prefix on the IAM worth.

Subsequent, calculate the position ARN for every mapping. We’ll presume that the position ought to be created within the Account the place the CloudFormation template will get executed for now.

Now we will use our mapping within the template to replace the position identify and arn in our position. We’ll add the FindInMap perform to get the suitable worth:

We have to replace the deploy.sh file for this position as nicely. We’ll ought to change the argument identify used within the script and we have now to vary the parameter identify. We additionally want to vary the parameter validation and may return a user-friendly error message to let the caller know they should move in “iam” or “batch”. Observe that I didn’t change the stack identify simply but. That’s as a result of if I modify the identify of the stack, the present sources received’t get up to date and we’ll find yourself with two stacks — one with the outdated identify and one with the brand new identify — and two roles.

Listed below are the updates. Once I made these updates I noticed I ought to return to the CloudFormation template and alter the parameter identify to finish in “param” for consistency.

Right here’s the place I get the next error:

An error occurred (ValidationError) when calling the CreateChangeSet operation: Template format error: Each Mappings attribute have to be a String or a Checklist.

Principally we will’t embody parameters or pseudo parameters in our mappings. What can we do? Embrace solely the a part of the string that we’d like for a differentiated worth. Then concatenate parameters with our FindInMap worth.

The mapping part turns into:

We are able to concatenate our mapping worth with the opposite portion of the string we’re formulating for our position identify and ARN utilizing the CloudFormation Be a part of perform:

As an alternate to an inventory of strings in YAML we will use this format:

So the position values change as follows:

Take a look at the template with the batch job identify POC we used earlier than and move within the job kind: batch.

./deploy.sh POC batch

Now we will go test to see if our POC position has the right ARN. Sure it does.

Now let’s attempt to redeploy the POC job with the iam credentials

./deploy.sh POC iam

Now we will test for our POC position once more. It’s been up to date to have the prefix IAMRole.

Our batch job position now additionally has a belief coverage that enables the IAM administrator to imagine the position.

We’re going to have repair a number of different issues now although. The deployment information we created earlier are passing in an ARN as a substitute of a job kind. We have to replace this file for the batch job we’re engaged on that deploys the batch administrator credentials:

jobs/iam/DeployBatchJobCredentials/deploy.sh

Change references to the IAM administrator ARN to move within the batch job kind as a substitute. As well as we aren’t truly utilizing the rolename variable so that may be eliminated.

This properly simplifies our template:

We additionally must edit the take a look at.sh file that passes in an ARN to check the POC batch job:

Now run the take a look at script within the root folder to ensure our modifications didn’t break any of our code:

./take a look at.sh

All of the checks run efficiently however discover that a whole lot of the templates didn’t change. To double test the whole lot deploys accurately I deleted the Batch job coverage and position CloudFormation stacks for the POC job and the DeployBatchJobCredentials job. Then I re-ran the take a look at. All of the CloudFormation templates deployed efficiently.

Observe that it’ll take some time for the IAM insurance policies to kick in. When you get an error saying the IAM administrator will not be approved, save that for the subsequent publish.

Matching our useful resource and stack identify for the IAM position

The CloudFormation stack received’t replace the present sources if the stack identify modifications, it’s going to create a brand new stack. We’re going to vary the identify of the stack to match the identify of the useful resource we’re creating (my private desire). However be aware that you will want to delete the stack with the outdated identify as a result of a brand new stack with a brand new identify will likely be created.

You’ll must delete coverage first as a result of it is determined by the position. Delete the 2 stacks under on this order:

Now return to the deploy.sh script and alter the stack identify as follows:

The primary line provides the batchjobtype variable worth at first of the identify. The second line makes the primary character uppercase.

There’s one different factor we’re going to want to vary. Our kms take a look at script references the identify of the stack for the IAMDeployCredentials job to get the batch job position ARN. Replace that to have the IAMJob as a substitute of BatchJob prefix.

Run the take a look at script within the root of the repo listing once more.

If at any level you get the KMS is Not Allowed error, confer with this publish:

As a way to delete the CloudForamtion stacks it’s important to delete the alias and key utilizing the kms profile first. There’s a schedule-key-deletion script within the kms listing. The issue is that he key will cling round with the identical identify for 7 to 30 days. You can too make a slight modification to the CloudFormation script to get it to replace if it’s not updating after deleting the position previously in the important thing coverage.

All of the CloudFormation stacks ought to full efficiently besides the final one. When you have any errors which might be arduous to pinpoint, run every particular person take a look at script within the iam, kms, and jobs folder individually. Repair every error after which run the general take a look at script.

You would possibly get an error with the final script associated to the IAM position. That’s anticipated for now:

We’ll repair this within the subsequent publish after we have a look at find out how to forestall the confused deputy drawback in IAM Insurance policies. Now we have an issue in one among our administrator position insurance policies now. Do you keep in mind which one?

Observe for updates.

Teri Radichel

When you appreciated this story please clap and observe:

Medium: Teri Radichel or E-mail Checklist: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests providers by way of LinkedIn: Teri Radichel or IANS Analysis