Adding a Batch Job Configuration SSM Parameter For The 2SL Job Execution Framework

ACM.439 Deploy a 2SL Job Execution Environment — Step 2— Adding a job configuration parameter to deploy a single resource

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

⚙️ Part of my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: AWS Security | Application Security | Batch Jobs

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

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

In the last post, I created a new batch job type for my job execution framework by adding a new repository, Dockerfile, and execution.sh file.

In this post I want to define an SSM Parameter with configuration for my batch job so I can use the value in that parameter for CloudFormation template parameters and job execution environment arguments.

TLDR; 
Add a job configuration parameter SSM that looks like this:

Name: 
/job/awsenvinit/root-admin/organizations-organizationalunit-dev

Value:
env=dev
region=us-east-2
cfparamParentid=:get_id:organization:organizationalunit:root

Add this command to execute.sh in your job:
deploy /job/awsenvinit/root-admin/organizations-organizationalunit-dev

Future: just pass that above job parameter name into the awsdeploy container

The 2nd Sight Lab Job Execution Framework does the rest.

SSM Parameters for Job Configurations Revisited

I already explained how to use SSM parameters for a job configuration here.

There were a few things I didn’t like about that approach. One is that the job configuration was limited to a particular format if I parse it in run.sh.

Each batch job could potentially have a different configuration format in the SSM Parameter if I let the job handle parsing the configuration. one might use XML or JSON or Yaml, or something completely different, like I might do.

Blindly passing the value of whatever is in the parameter to the job might lead to injection attacks. Each job needs to validate the value of the parameter carefully. But I can eliminate the chance of that affecting the job execution framework itself if I avoid pulling in the parameter value into the run.sh file itself. That file is just going to pass along the parameter name to the job.

The job runs in a container. If our container is sufficiently locked down (which it is not yet!) then code hopefully can’t escape to the host running it which has a role that can access all our credential secrets. You could create multiple ec2jobexecution roles if you want to further limit that blast radius.

Although I want to get the code parsing parameters out of run.sh, I want to leverage reusable code for parsing parameters, because that might be used in different jobs. I’m going to add my parameter parsing code to a shared functions file in the job execution framework so I’m not repeating that in every job. I’m once again following the DRY principle and trying to limit code duplication.

SSM job configuration parameter name — recap

One thing I do want to do is limit the format of the job parameter name in the run.sh file.

Recall that I refined the job names here:

I went on to refine the naming conventions for parameters in this post so we can leverage the name in policies and getting a list of jobs a role can execute:

The format:

/job/[container image]/[job execution role]/[job name]

The job name defines the resource deployed in a format that matches the naming convention in the resulting CloudFormation stack:

[resource category]-[resource type]-[resource name]

That way it’s easy to find the parameters passed into a given stack, though you can also find those in CloudFormation. The thing an SSM Parameter might buy you is versioning to see how parameters changed over time.

Of course, it doesn’t help if you give everyone permission to delete versions.

Validating the job config parameter name

I can validate that the parameter name is a valid format and that the parameter exists in run.sh before passing it along.

• Starts with /job/
• Only four slashes (/) in the name
• The values between the slashes should only have alphanumeric or dash characters

Here’s what I came up with and tested with a couple of values:

It’s probably not perfect but better than nothing at this point.

Now I can add that check to the run.sh file:

A job configuration parameter to deploy the dev OU

Let’s create a parameter for the first resource we need to deploy — the dev OU:

Here’s the parameter name based on the naming convention above and our hierarchy of AWS resources and categories:

/job/awsenvinit/root-admin/organizations-organizationalunit-dev

The resource hierarchy was explained here:

As described in the prior post on how I formulate the parameters, the value for my parameter would be:

env=dev
region=us-east-2

Recall that role, container image, category type, resource type, and resource name get parsed out of the parameter name.

The region is used by the CLI command and where the CloudFormation stack will end up, if not required for global resources.

The env value is the environment in which the resource will be deployed and is prepended to the name (or in this case it is the name).

I also need to pass in CloudFormation parameters with a defined prefix so we can easily parse out those parameters and pass them to a CloudFormation template.

I can’t remember if I wrote about this already or not. I’m going to rename all my parameters to start with:

cf_param_

So my organizational unit template becomes:

OK. Except AWS naming inconsistencies strike again.

I can only use alphanumeric so I’m going to have to use this format:

I’m going to pass in those parameters in my configuration like this:

env=dev
region=us-east-2
cfparamName=dev
cfparamParentid=[hold this thought...]

In fact we don’t need the name because it’s in our parameter name so:

env=dev
region=us-east-2
cfparamParentid=[hold this thought...]

Pretty much every resource is going to have a cfparamName parameter.

Eliminating repetitive code

Now I can parse through all the parameters that start with that prefix and add them to the parameter list I’m creating over and over again in my deploy functions:

While we are at it, we can get rid of some hard coded values that are derived from the job config parameter name and value:

We can probably validate the values of our parameters in our common parameter parsing routine, or worse case it’s validated by CloudFormation:

In fact, we can pretty much eliminate this function altogether and use a common function to deploy this resource.

Almost. I need to deal with that parent ID value.

Dynamically retrieve ids based on type and name

What about that root ID for the OU parent?

In some cases we need to pass in IDs to CloudFormation templates. The IDs might be different in different environments while the names will be the same.

For example, if a bunch of people want to use this code in their AWS accounts they might leave the name of the OU the same (dev) but the underlying OU id after they create the OU will be different. Also their root id is not going to match my root id, so if I put my root id hard coded into my repository the code isn’t going to work for them.

Also, we might not want to expose the IDs. Although account IDs are not meant to be secrets according to AWS, knowledge of accounts does make certain things easier for attackers. I just saw someone posting some research about that on X. So we may not want to expose IDs in code either.

For this resource, we need to pass in a parent ID which is either going to be the organizational root ID or another organizational unit ID. I already have a function to look up an OU ID by name in my organization_functions.sh file:

What if I include the related functions file in my generic function for any resource I’m deploying. Then I make it such that I can call any function in that file and pass in a value from my job config. That gives us a lot of flexibility to come up with the necessary values to complete the task at hand. So like this:

#THIS IS BAD CODE. DON'T DO THIS.

env=dev
region=us-east-2
cfparamParentid=$(get_id_from_name "root")

WARNING: The above has some serious security ramifications. We’d be passing executable code through and any matching function in any included file could be called if we add it to the configuration.

If I was penetration testing the above code, I’d try to pass in all sorts of bash scripts and try to call other functions to try to make this code do bad things.

I might create a parameter value like this to see if that would execute and I could get the password file and then crack other passwords on the system, for example:

#yikes!
env=dev
region=us-east-2
cfparamParentid=$(cat /etc/passwd)

Or since this is running on AWS I might try to pass in a curl command to see if I could get credentials from the AWS metadata service.

Well, that’s not good.

Here’s what I am going to do instead. We are only going to allow one specific function to be called for any resource: get_id.

I have already started renaming any functions that get an id based on a resource name to get_id in all my functions files for consistency. Any other function name will be rejected.

We may be able to take some additional validation steps to ensure the get_id function is only called for the specified type by adding the resource category and type.

So get_id is the only function that can be called here and I change the format so it is not passed in as an executable string but rather a static value parsed to determine the action to take:

env=dev
region=us-east-2
cfparamParentid=:get_id:organization:organizationalunit:root

With the above directive we know that because it starts with :get_id: we’re going to use the get_id function and we know from which file based on the category and type due to our naming convention, and the last value is the name. We can write a common function to use that information to include the correct functions file and return the specified value.

Here’s my function to process the id:

I ended up putting that in a new shared file because I ran into conflicts when I sourced the file from the functions file that the file I’m sourcing in turns sources. This creates a kind of circular dependency.

shared/parse_config.sh

I tested that by setting a CLI profile that had access to AWS organizations and calling the function like this at the bottom of the file:

I executed the file:

./shared/parse_config.sh 

That successfully gave me the root id of my organization. So now I can call that function and pass in a configuration value to get back an ID. Woot!

I removed the two test lines above.

Add the configuration to the job config repository

I added the configuration to my 2sl-jobconfig-awsdeploy repository.

Although this technically is not a configuration for the awsdeploy job I don’t want to create a whole repository for one file.

I made a note of this in the README of my job repository:

Back in the 2sl-jobconfig-awsdeploy repository…

I crafted this file path and navigated into the aws-root folder:

/job/awsenvinit/aws-root/

I edited the job config file:

vi organizations-organizationalunit-dev

Save it.

Deploy the job configuration into an AWS SSM Parameter

To deploy the job configuration parameter in our init script I made a couple of changes.

I put the function to deploy a job parameter into the job config repository:

In a file named:

job_parameter_functions.sh

I made the profile optional since we don’t have a profile in CloudShell.

I clone the repository and deploy the parameter in my init.sh script and create the parameter with the code below:

I verify the parameter is created with the correct name:

And has the correct value:

A generic function to deploy resources based on a job configuration

Now that we have a parameter we need a generic function that can parse the parameter and deploy our resource.

I’m also going to add this common function to shared/parse_config.sh.

Here’s what it is going to do:

* Receive the parameter name as an argument.
* Parse out the name, resource, and category from the parameter name.
* Read the value or the parameter.
* Parse each line
* If env then prepend name to env unless env is the name and set env value.
* If region then set the region var
* If the line contains a cfparam:
*** If value starts with :get_id: then resolve id.
*** Add parameter and value to the parameter list.
* Call the deploy stack function.

Here’s the generic function I ended up with:

I did some testing but the deploy_stack function needs a profile which we don’t have in AWS CloudShell so I tested the remainer in the job container that obtains a profile before running the job.

Run the job

Now when the job runs it needs to pick up the parameter value. In future jobs I will pass the parameter in but this job has a specific use case and I’m just performing an initial test. Heads up, this is going to change but I need to make sure this use case works first.

I source my new parse_config.sh file in the execute.sh file.

I’m add a call to the deploy function and pass in the parameter name.

deploy_config "/job/awsenvinit/root-admin/organizations-organizationalunit-dev"

Check the CloudFormation stacks to make sure that worked.

What if I wanted to deploy another resource?

Well, I could add another parameter to SSM Parameter Store.

Then I could call the deploy command again.

That works but then I have a whole bunch of parameters. I will explore some other options in the next post that perhaps can limit the number of parameters we need to create.

I had to fix a few typos along the way but the latest code with any fixes should be in GitHub. As always if you hit an issue submit it in the GitHub repo. I’ll fix it when I can.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2024

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