A Container That Initializes an AWS Organization in CloudShell

ACM.436 Cleaning up file paths, checking buildx version, and executing the initial deploy commands

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

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

🔒 Related Stories: AWS Security | Governance | Batch Jobs

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

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

In the last post I spent far too long troubleshooting issues trying to build a container in CloudShell. As I mentioned at the end, ideally you’re downloading and running an already built container, but in this case we don’t yet have an ECR repository to deploy from and I’m not putting that container on DockerHub for a reason. This code is for individual use only so please refrain from doing that. I’ll change this up later hopefully to make it easier to deploy but we have to take care of some other things first.

A Docker Container In CloudShell

ACM.435 Building and running containers in AWS CloudShell

medium.com

In this post, I’m going to deploy the code that initializes the AWS Organization in any account. I already have a script that does that. Mostly I spent time fixing the file paths to get it to execute inside the container.

Paths relative to execution file

First thing is this. I remembered after writing that I had all the paths relative to the execution file to avoid complexities with how bash handles file paths. Oh yeah.

I put the directories back where they were originally in the 2sl-jobexecframework repository and restored my paths:

/job/run.sh
/shared/
/resources/

Then my file paths work everywhere again.

The files are still relative to the root of the aws folder in the 2sl-jobexecframework repository.

Mental note: do not change the paths.

Check the buildx version and update if necessary

I added code to check the buildx version we had to update in the last post. Then I run the update if the version is the 0.0 version. Here’s what I ended up with after testing it out:

Dealing with the space issue

I added notes about the space issue in CloudShell since I hit that repeatedly. Notes are in the README.md file.

GitHub - tradichel/2sl-job-awsorginit: Initial code to run in a new AWS account

undefined

Clearing space and commands

I added some code to clear space and commands at the end of the script.

Uncomment the commands to deploy resources

Once that was resolved, I uncommented the commands to deploy the resources and tested it in my root account.

After fixing more path issues, it worked.

Next step

I added comments to explain the next step to run to deploy the job execution framework. These resources are deployed in a series of steps to establish a hierarchy that limits the blast radius as you move further and further down the chain. The credentials at the top should rarely be used whereas credentials further down the chain are used more frequently. More on that in later posts.

Follow for updates.

ACM.437 Initializing a 2nd Sight Lab job execution environment with the minimum resources required to run jobs