Using Session Names to Log Who Deployed What in CloudTrail

ACM.388 Refactoring my test script that will ultimately be used in EC2 Instances to run deployment jobs

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

⚙️ Check out my series on Automating Cybersecurity Metrics | Code

🔒 Related Stories: AWS Security | Secure Code

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

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

In the last post, I migrated over my existing AWS Organizations code from my proof of concept code and tested it.

It seems like I always start out with one goal in mind and I get sidetracked with something else. As I start to add additional deployment scripts to the new code repository, I realized I’m going to want to test and retest all my scripts.

I’ve also come to the conclusion that cross-region deployments are painful so I’m going to focus on single region deployments for now. I might address the cross-region deployments again in the future when I must — for anything that requires a us-east-1 deployment, for example.

I added a build and push to the top of my container since it seems like I need to do that pretty much every time I make a change:

I am going to list all the available scripts in the container and be able to select one from a list. This may be too unwieldy if I have too many scripts in the container but going to try it out. I also throw an error for an invalid selection. Note that I’m setting the username below but really the user should specify their username with their MFA token. Recall that I am forcing all MFA token names to match the username for virtual MFA tokens.

I simplified and clarified the role names. I’m not really using an ec2 role for the first role but that’s what it ultimately will be. The EC2 instance will also need the repo permissions but I’m just using a role that has access for now.

I changed the secret lookup to the EC2 role name and added some error checking:

I’m creating a profile for the deployment role that leverages the secrets we retrieved:

I set the mfadevicename to the username for clarity:

I use that CLI profile to get short term role credentials.

Note that the session name above incorporates the username, the role name, and the script.

And here’s the beautiful thing:

That session name will show up in CloudTrail and make it easier to see which user is running which script with which role.

I’ve only implemented one “job” in my container so far (deploy_organization) but here’s what that looks like:

For this reason, I’m also going to keep my deployment scripts limited to as few resources as possible so I can see what people are deploying and make sure the names accurately describe the resources. I will hopefully explain how to concatenate these scripts into a larger chain of deployments in a later post.

This only works if you enforce standard deployment mechanisms (as I have been preaching for years while some people claim it can’t be done — it can.) You also need to enforce virtual MFA devices to match user names as I’ve shown you in an earlier post and enforce MFA to assume roles (without using boolifexists as I explained in detail doesn’t really work as an enforcement mechanism in all cases.)

Hopefully you’ve been following along on email or via the email list — links at the bottom. I’m trying to consolidate the IAM related posts here:

I also cleaned up the rest of the script a bit and pass in the role name instead of the job name, as I had a typo in an earlier post. That never would have worked.

But can’t a developer just change this script when they execute it?

Yes. But if it’s inside an approved AMI when deploying to production and the developer can’t change that when running instances and deploying containers, then they can’t mess with the script during a production deployment, presuming they cannot log into the instance and it and the code it runs is immutable.

And no injection vulnerabilities exist. :-)

I still need to add a lot of validation and pentest my own code but I’m just getting it working at this point (famous last words.) This is a proof of concept at this point, not a production ready piece of code.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

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