ACM.433 Revisiting catch-22 for deployments from root account
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~ ~~~~~~
⚙️ 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 created a common task execution container to run tasks in batches.
As I started working on the next script, I encountered this problem. The task execution role must access SSM settings and therefore must be in the same account in which the role was created.
Then I decided that the settings needed to be in the same account as the EC2 execution role so that it could pull the list of settings and secrets etc. But I forgot about my previous dilemma and was trying to use a role from a different account to run the job.
Ultimately, the simplest solution (and least complex to avoid misconfigurations or security issues) is to ensure that the EC2 instance, EC2 instance role, settings, secrets, and the job execution role are all in the same account.
This got me thinking about which accounts I wanted this task execution framework to exist in.
Components of our task execution framework
Based on the last post, here are the components we need to deploy resources using the task execution framework I’m creating.
- An EC2 instance
- An EC2 instance role
- SSM task configuration settings
- A user who can perform tasks with an MFA device
- Secrets with credentials associated with the user
- A role that can perform work
So I will need to deploy the above to any account I want to run tasks on.