Create an IAM role for a Batch Job
ACM.16 Using CloudFormation to deploy an IAM Role and AssumeRolePolicyDocument
This is a continuation of my series on Automating Cybersecurity Metrics.
In the last post we looked at how to create a user with CloudFormation.
Create an IAM User with CloudFormation
ACM.15 Creating Batch job administrators to kick of AWS Batch jobs
Now we’ll look at how to create an IAM Role.
Creating an IAM Role using CloudFormation
In the last post we create an IAM user with CloudFormation to execute the batch jobs we are creating in this series of blog post.
We will also need an IAM role that can do specifically what each batch job is allowed to do and a policy for this role. Initially we are just going to test assuming a role that requires MFA using STS, so we won’t assign any permissions to the role in this post. We will add that later.
Creates a new role for your AWS account. For more information about roles, see IAM roles. For information about quotas…
Trust Policy and Principals
A trust policy defines who can assume a role. The documentation below explains which principles you can allow to assume a role. Unfortunately we cannot allow a group to assume a role which is inconvenient. I’d like to be able to say everyone in our BatchAdminsGroup created in the last blog post can assume the role but that is not possible.
AWS JSON policy elements: Principal
Use the Principal element in a resource-based JSON policy to specify the principal that is allowed or denied access to…
We could allow a role to assume another role, but then we’d ultimately have assign each user we want to assume the original role in a trust policy so that doesn’t really help us.
We can also allow all the users in an account to assume the role but that’s not what we want either. We may have others performing tasks within the account besides the batch administrators that we do not want to grant access to assume the role For example, an organization could have security people reviewing logs or configurations who should not be able to assume the role.
It appears that we will need to add each individual user to the trust policy from the batch admin group if we add new users.
Directory Structure and Abstraction of Common Code
I want to use common code wherever possible to leverage the principle of abstraction I wrote about in these blog posts so we don’t have to repeat code and inadvertently introduce bugs. We can also update our global role template in one place.
Every Line of Code is a Potential Bug
How to reduce the chances of a security flaw in your application with the principle of abstraction
Abstraction and MITRE ATT&CK
Leveraging abstraction to come up with primary points of attack
We can put our individual batch job policy documents in a directory specific to that batch job, plus a deployment script which uses the global role template and the local policy document to create the role for the batch job. If we name all of our batch job policy documents policy_document.yaml then we can use a single deploy script and pass in the batch job name as a parameter.
The first batch job I’m going to deploy will be named poc (proof of concept) so I’ll create a poc directory, a cfn directory inside that, and put our policy document CloudFormation template in the cfn directory.
As with the last post we’ll be using outputs. We’ll use the user output from our user template in the last post as an input to our trust policy to allow that user to assume our new role. Refer to the last post for more about outputs and anything you’re not familiar with in this post’s code.
Using the Sub function with ImportValue and PseudoParameters
If you’re trying to understand the line with the Sub, ImportValue and PseudoParameters I wrote more about that here when I was facing some syntax errors:
(Service: AmazonIdentityManagement; Status Code: 400; Error Code: MalformedPolicyDocument; Request…
Error trying to assign a user as the Principal in AWS AssumeRolePolicyDocument
We want to create an AssumeRolePolicyDocument, also known as a trust policy, that only allows our batch job admin user created in the last lab to assume this role. We construct the role from the current account number and the username output from the batch job admin user CloudFormation stack.
We could have also output the user ARN from the user stack, but writing the template this way ensures the user ARN for the user allowed to assume this role is in the current account. You may or may not need or want that restriction.
As before you can find the code in this GitHub repository:
GitHub - tradichel/SecurityMetricsAutomation
This code is associated with a series of blog posts. Please refer to these posts for more information: Automating…
Note: These templates moved to the iam directory of this repository in a later post.
IAM Role template:
Deployment script for our IAM role:
As explained in the last post, make sure you have the proper credentials configured in your environment, navigate to the jobs directory, and run this command. POC is the name of the first batch job we’re going to create, and coincidentally matches the name of the batch job folder in the above directory structure. If you hadn’t guessed, that is by design.
Right now the name of the batch job passed into the deploy script is used to create the role name but in the future we’ll use it for more than that.
Once your script completes you should have a new role for your batch job. As noted in the last post we’re not assigning any permissions yet because we first need to create the resources that we’ll allow our batch job to access, use, and operate on.
Verify your role got created successfully
Navigate to the IAM console and click on Roles. Search for your batch job role. Notice that the name you passed in got added to the end of the role name. We can use this script for all our batch jobs instead of writing a new script for each one.
Click on the role and notice it has no permissions. That is expected. I’ll show you how to add those in an upcoming post. For now we want to test out something else.
Click on Trust relationships. Verify that the trust policy (what was called AssumeRolePolicy Document in CloudFormation for some reason) looks correct. You should find the ARN for the batch job administrator here and permission to assume the role.
We’ll add more onto this in the upcoming posts. One of the best ways to make write code is in small pieces at a time so you can validate each piece works.
Next up, we’ll work on creating and securely storing the credentials of our batch job administrator so we can use those credentials to run a process and assume a role.
Follow me for updates.
If you liked this story please clap and follow:
Medium: Teri Radichel or Email List: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests services via LinkedIn: Teri Radichel or IANS Research
© 2nd Sight Lab 2022
All the posts in this series:
Automating Cybersecurity Metrics
A series of blog posts on cybersecurity metrics and security automation
Need Cloud Security Training? 2nd Sight Lab Cloud Security Training
Cybersecurity & Cloud Security Resources by Teri Radichel: Cybersecurity and Cloud security classes, articles, white papers, presentations, and podcasts