Creating Batch job directors to kick of AWS Batch jobs
This can be a continuation of my collection of posts on Automating Cybersecurity Metrics.
The previous few posts coated the reasoning behind a number of the architectural decisions up up to now for the batch job structure we’re constructing to automate some safety duties. We’ve determined to make use of an IAM consumer with digital MFA to kick off batch jobs and an IAM position for the actions taken by a selected batch job. Let’s evaluate our necessities for the consumer I’m calling our batch job administrator.
Batch Job Person Necessities
- I’ll use a separate consumer for this goal from my administrative consumer account which has too many permissions.
- I can not use an IAM position to kick off the roles as a result of I wish to use MFA and you can not use MFA with an AWS IAM Position alone. An MFA serial quantity is related to a consumer.
- I don’t wish to use AWS SSO (now AWS Id Middle) as a result of I don’t just like the configuration that features the URL to my login portal or the browser interplay. I’m not even positive that may work with what I’m hoping to implement.
- I’m going to make use of STS and go in credentials and an MFA token.
- I don’t wish to use a Yubikey as a result of I’d have to put in the Yubico CLI on my laptop computer, so I’ll use digital MFA for this consumer.
- This consumer doesn’t want entry to the AWS Console. This consumer is required solely to acquire an MFA code to kick off a job and to imagine a job.
- I’ll be leveraging an AWS Entry Key and Secret Key related to the IAM consumer however I don’t have anyplace safe to place these simply but so I’ll create them later.
- This consumer is not going to be allowed to change it’s personal password or MFA. An administrator must try this.
- I’m going to run my batch jobs in a separate, locked down account in my AWS group. I’ll create the consumer in that account.
- The one required permissions from my batch job administrator appears to be STS to imagine the roles I create for my batch jobs in that account.
- I could wish to assign the permissions to kick off batch jobs to different customers sooner or later, so I’ll assign the permissions to a group, not a consumer. That’s an AWS safety greatest follow.
IAM Position Necessities
- I’ll create a separate position for every batch jobs with permissions restricted to precisely what that batch job must do.
- We’ll restrict entry to assets to this position solely except MFA is current for the explanations mentioned within the final put up.
- We’ll add permissions to this position later once we arrange the assets it wants to make use of and entry.
Devoted AWS Account
I’ve already written about automating AWS account creation with a safe baseline utilizing AWS Management Tower. Although I may add some further details about securing this Lambda operate, it will get you began if you wish to automate creation of latest accounts. Account creation could possibly be moved to a batch job as soon as we’ve our infrastructure arrange.
Creating an AWS IAM Person with CloudFormation
I’m going to create my batch job administrator consumer with AWS CloudFormation. If you happen to’re not conversant in or don’t like CloudFormation, this put up could assist:
We’ll have to create the next IAM assets with our CloudFormation templates and script:
An IAM Person (a batch job administrator)
That is the id that may kick off batch jobs and has the related MFA system used to generate MFA tokens.
An IAM Coverage (for batch job directors)
Word that this isn’t a “Person Coverage” which is a coverage written and related to a single consumer. We wish to create a stand alone coverage within the account that we will affiliate with different customers and teams sooner or later. This coverage is barely used to begin batch jobs, and doesn’t embody the permissions for the actions taken by batch jobs.
An IAM Person Coverage Doc (permission to begin a batch job)
Coverage paperwork outline the permissions {that a} coverage grants to an id and to which assets the coverage.
An IAM Group (batch job directors)
We’ll assign the permissions to a bunch after which add our IAM consumer to that group.
Operating the CloudFormation Script
One other query to contemplate moreover simply writing the CloudFormation script is the place and the way we are going to run this script. For the needs of those proof-of-concept (POC) I’m working as if I’m in a improvement surroundings, testing issues out. I’m going to be testing my batch job regionally and utilizing IAM to deploy it with a manually executed script.
Particularly we are going to use the deploy command as a result of it should create a brand new stack if it doesn’t exist or replace an current stack. That’s significantly better than the times once you had to determine your self which motion wanted to happen and name two separate instructions.
I typically advocate an automatic CI/CD pipeline or purchasers I communicate to on consulting calls by way of IANS Analysis when shifting code from Dev to QA to Manufacturing. To create this automated pipeline, we may use batch jobs sooner or later to run these scripts or Lambda capabilities such because the one I wrote to create a brand new AWS account. Your staff would possibly use a software like Jenkins to run jobs that execute deployment scripts or leverage AWS Service Catalog. Making a safe deployment pipeline is a subject for one more day (or one other e-book!)
GitHub Repo and Listing Construction
I created a brand new GitHub repository for this POC. Right here is the construction for the recordsdata related to this weblog put up:
- I count on that I’ll have to deploy and re-deploy batch job directors at totally different instances than the batch jobs themselves so I’ll put that code in a separate listing known as batch_job_admins in my GitHub repo.
- I’ll add a deploy.sh within the listing containing the scripts to deploy my batch job admins.
- I typically put every useful resource in it’s personal file so it’s straightforward to search out the code once I wish to edit it. I can even redeploy particular person assets individually.
To start out the directories will appear like this:
/batch_job_admins
/cfn
policy_batch_job_admins.yaml
group_batch_job_admins.yaml
user_batch_job_admins.yaml
deploy.sh
CloudFormation Parameters
Word that I’m making use of CloudFormation Parameters in these templates. That approach, they are going to be reusable as a result of folks can go in no matter parameters work in their very own surroundings. For instance, maybe you have already got am IAM group named batch_job_admins which I take advantage of in my script. You may override the group title in deploy.sh with no matter title you need.
CloudFormation Outputs
The templates additionally use CloudFormation outputs. After a template executes it may retailer references to assets it created in outputs. We’ll want the outputs from one template to make use of within the subsequent. For instance, we’ll create an IAM Coverage with the permission for our batch job admins. Then we’ll use the output from that template in our IAM group template to assign that coverage to our new group.
ImportValue
We’re going to make use of the ImportValue operate to reference the outputs from one stack in one other. For instance, the cloud formation template that creates and AWS IAM group outputs the group reference. The coverage CloudFormation makes use of that output worth to use the brand new coverage it’s creating to the required group.
Pseudo Parameter — AWS::AccountId
We’ll be utilizing a pseudo parameter (AWS:AccountId) that insert the account ID for the account during which the script is getting executed into the code. That approach we don’t must exhausting code account numbers, put them in supply management, and the script will work in any account the place it will get executed.
Sub
We’ll use the Sub operate to substitute the AWS::AccountID with the precise account ID of the account during which the script is executing. You’ll see the sub operate on this line of our coverage CloudFormation template:
Useful resource: !Sub 'arn:aws:iam::${AWS::AccountId}:position/batch_*'
CLI profile
The bash script lets you go in a CLI profile in case you have one configured, in any other case it makes use of the default profile. You may configure a number of CLI profiles so you’ll be able to run scripts with totally different credentials and in numerous accounts.
The code
You’ll find the code on this GitHub repo:
No warranties on any code and please don’t run it in a manufacturing surroundings with out completely testing it. As I discussed earlier than I already had somebody insert a “particular character” into a few of my class code. Issues occur. Do your due diligence.
Simply in case you’re unfamiliar with GitHub, first set up git.
Then you’ll be able to execute this command to acquire the code on this repo:
git clone https://github.com/tradichel/SecurityMetricsAutomation.git
These are the recordsdata associated to this weblog put up within the GitHub repository:
Group CloudFormation (group_batch_job_admins.yaml)
#group_batch_job_admins.yaml
https://github.com/tradichel/SecurityMetricsAutomation/blob/important/batch_job_admins/cfn/group_batch_job_admins.yaml
Coverage CloudFormation (policy_batch_job_admins.yaml)
#policy_batch_job_admins.yaml
https://github.com/tradichel/SecurityMetricsAutomation/blob/important/batch_job_admins/cfn/policy_batch_job_admins.yaml
You’ll discover within the coverage above that I’ve an asterisk (*) within the useful resource title for the roles that my consumer can assume. That’s as a result of we’re going to title all our batch job roles BatchRole[name of batch job]. The worth of ${AWS::AccountId} can be changed with the account ID of the account the place the script is executed. Which means the Useful resource can be an ARN for any position in that account that has a reputation beginning with BatchRole. So any consumer within the group to which we’re assigning this coverage will be capable to assume any position within the account that begins with BatchRole.
Risk Modeling our Coverage
We nonetheless do have a few safety issues with this design. We have to ensure that nobody can add a brand new position beginning with BatchRole to assign permissions larger than they’ve themselves and execute a batch job to raise their very own privileges. It might be a good suggestion to separate the permissions between the individuals who can create and modify jobs from those that can begin jobs. You’ll additionally need a safe deployment course of as talked about earlier.
We additionally have to ensure that somebody who just isn’t speculated to be allowed to begin batch jobs will get added to the Batch Job administrator group. I often advocate that organizations have a separate IAM staff so the individuals who give and use the permissions are usually not one and the identical. This will get tough with regards to purposes, and you should utilize permission boundaries to restrict the permissions customers may give to purposes or use an AWS account.
One other concern can be that somebody may begin an EC2 occasion or different compute useful resource, add an current position to it, and use these permissions to do one thing they aren’t speculated to do. This once more comes down your IAM staff, permissions boundaries, and presumably including some service management insurance policies to restrict permissions. You may also increase alerts in response to delicate or surprising actions in an account.
Person CloudFormation (user_batch_job_admin.yaml)
#user_batch_job_admin.yaml
https://github.com/tradichel/SecurityMetricsAutomation/blob/important/batch_job_admins/cfn/user_batch_job_admin.yaml
Bash file to deploy our CloudFormation Templates
#deploy.sh
https://github.com/tradichel/SecurityMetricsAutomation/blob/important/batch_job_admins/deploy.sh
Permissions to run the code
It’s often not a good suggestion to place credentials on an EC2 occasion. I can be utilizing credentials later on this collection, saved in secrets and techniques supervisor. To run the code on this put up, I used an EC2 occasion with the mandatory occasion profile (IAM position) assigned to it.
If you happen to’re including credentials to EC2 cases please cease. Go create a job that your EC2 occasion can use that has the required permissions. Add the position to your EC2 occasion. Disable or delete your current credentials and create new ones.
By the best way, if you happen to don’t have long-lived credentials in your laptop computer, malware that features entry by way of a phishing assault (one of many prime sources of cloud safety breaches) can not steal them. Although I did clarify how credentials on EC2 cases may be abused on this weblog put up, it’s more durable, and I supplied some suggestions to mitigate that danger on this put up as effectively.
Execute the deployment script:
./deploy.sh
Watch the output of the script for any errors:
You may see I acquired an error that the top.
Navigate to CloudFormation within the AWS Console each to confirm the stacks accomplished efficiently or verify for any errors. You may see right here I’ve an error and the script rolled again. Click on on the title of the script.
Click on on Occasions:
Right here I can see that the of the export I referenced just isn’t appropriate. It doesn’t match the title within the unique template the place I created the export, so I’ll repair that. I occur to know that export is in my group template. As you’ll be able to see under the export title is groupbatchjobadmins not batchjobadminsgroup. I don’t wish to change this file since this useful resource is already deployed so I’ll repair the consumer template as a substitute.
I’ll change this:
To this:
Earlier than I redeploy I might want to delete the prevailing failed stack because it’s by no means absolutely deployed efficiently. Return to your stack in CloudFormation and click on Delete.
Confirm the stack acquired deleted out of your checklist and run the deploy.sh script once more.
As soon as all of the stacks full efficiently it’s best to see them in CloudFormation:
You may navigate to AWS IAM and make sure the assets exist there as effectively.
Right here’s my Person Group:
After I click on on it I can see my consumer within the group:
After I click on on Permissions I can see the coverage:
After I click on on the coverage after which JSON I can see the contents of the coverage, and that I’ve one error:
The issue above is that useful resource ARNs ought to have an account Id in them and this pattern ARN had a placeholder worth the place the account ID ought to go. I corrected that drawback by utilizing a pseudo parameter as defined above:
If I return to customers and click on on the BatchJobAdmin consumer after which safety credentials, I can see that the consumer accurately has the console password disabled.
No MFA system is assigned right here. You may go forward and add that now. Click on Managed and comply with the steps so as to add your digital MFA system.
Scroll down and you’ll see that this consumer has not AWS Entry Key or Secret Key to carry out programmatic actions, so basically this consumer has no skill to do something in our AWS account within the second, which is what we wish.
I’ll publish the code for the job position and job within the subsequent put up. Observe me for updates.
Teri Radichel
If you happen to preferred this story please clap and comply with:
Medium: Teri Radichel or E mail Record: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests providers by way of LinkedIn: Teri Radichel or IANS Analysis
© 2nd Sight Lab 2022
All of the posts on this collection:
____________________________________________
Creator:
Cybersecurity for Executives within the Age of Cloud on Amazon
Want Cloud Safety Coaching? 2nd Sight Lab Cloud Safety Coaching
Is your cloud safe? Rent 2nd Sight Lab for a penetration take a look at or safety evaluation.
Have a Cybersecurity or Cloud Safety Query? Ask Teri Radichel by scheduling a name with IANS Analysis.
Cybersecurity & Cloud Safety Sources by Teri Radichel: Cybersecurity and Cloud safety courses, articles, white papers, shows, and podcasts