A container that initializes an AWS organization in CloudShell | by Teri Radichel | Cloud Security | January 2024

esteria.white

ACM.436 Cleaning file paths, checking buildx version, and running initial deployment commands

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

⚙️ Part of my series on Automation of cybersecurity measures. THE Coded.

🔒 Related Stories: AWS Security | Application security | Abstraction

💻 Free content on Cybersecurity Jobs | ✉️ Register for Broadcast list

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

In the last article, I spent way too much time troubleshooting the issues of creating a container in CloudShell. As I mentioned at the end, ideally you download and run an already built container, but in this case we don’t have an ECR repository to deploy from yet and I’m not putting this container on DockerHub for a reason. This code is intended for individual use only, so please refrain from doing so. Hopefully I’ll change this later to make deployment easier, but we need to take care of other things first.

In this article, I will deploy the code that initializes the AWS organization into any account. I already have a script that does this. Mostly I spent time fixing the file paths to run inside the container.

Paths relative to the execution file

The first thing is this. I remembered after writing that I had all paths relative to the execution file to avoid the complexities of 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.

Files are always relative to the root of the oh folder in the 2sl-jobexecframework deposit.

Mental note: don’t change the paths.

Check buildx version and update if necessary

Leave a comment