Locking Down An SCP to Only Allow Modifications From the Management Account— Dynamically

ACM.401 Overcoming CloudFormation limitations for dynamic SCPs and challenges with delegated admins with IAM Permissions

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

⚙️ 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 paused to write about some code I’m using to generate code — without generative AI :) It was my 400th post in this particular series and I thought this was kind of cool and a special post for this monumental number.

My goal throughout this series has been to minimize the time I have to spend writing code to deploy new resources and I am getting closer and closer to that objective — while implementing a governed infrastructure to help limit misconfigurations and unauthorized access. Ultimately, I want to report on my own infrastructure and configurations.

Before that, I wrote about the conundrum of limiting access to change a single service control policy using the SCP itself or predicting the ARN — and it doesn’t appear you can do either.

In this post I aim to fix that. Kind of. I want to write a script that dynamically writes a template for this policy that will run in any account. It won’t work if I have to hard code a policy ARN.

Since I can’t seem to create dynamic SCPs using CloudFormation, I’ll have to dynamically write the file before it is accessed by CloudFormation.

Also note that if you give someone delegated administrator access for organizations there are a lot of opportunities for them to bypass controls on SCPS you applied to the root. Think about all the ways they can create a new user or assume a role or modify SCPs or policies to bypass any restrictions you create.

Create the Service Control Policy that I want to restrict access to change — administratorpolicy.yaml

I created a service control policy in the last post. It’s not the final policy I want but we’ll start with that SCP to see if we can make this work. Note that I changed the outputs to include arn and id for the resource created in the template.

Now I can use the output to create the second policy.

The problem locking that policy down from edits by particular users or roles and using dynamic parameters

I couldn’t find a way to use a parameter in a policy document for an SCP. Maybe I’m doing something wrong but this error message wasn’t very helpful as far as telling me what that was.

I tried numerous variations and searched around and gave up. Until if and when I figure out how to do it with CloudFormation, what I am about to do will be faster for me.

Also, if you give a user IAM and Organizations access it’s difficult to prevent them from changing the SCP using the SCP itself. I explained that in a prior post. So I’m going to two SCPs and make multiple updates.

I hope AWS will allow for dynamic generation of templates (or clarifies the error messages and documentation) and supports YAML for Policy Documents in SCPs soon.

Test the hard coded template: administratorpolicylockdown.yaml

First I create a hardcoded version of the final template I want to deploy and test it and make sure this works at all.

I deployed that and it worked.

Add a lockdown policy and placeholders for policy ARNs

Next I alter my templates to add a placeholder for the value I want to replace using the same method I used in the last post to replace placeholders in templates.

Administrator policy:

Administrator lockdown policy:

Now in my deploy script I’m going to call a new function called deploy_administrator_scps in my policy_functions.sh file.

In this function I take the following actions:

• Copy the two templates to the tmp directory.
• Deploy the admin policy, replacing the resource placeholder with *.
• Get the ARN of the admin policy.
• Deploy the lockdown policy, replacing the resource placeholder with the ARN of the admin policy.
• Get the ARN of the lockdown policy.
• Re-deploy the admin policy but this time replace the resource placeholder with the ARN of the lockdown policy.

I explained how I replaced values using sed in the last post and I have some useful sed commands here:

Now I can test out my deployment.

Here’s where I had all kinds of strange issues passing a ‘*’ or “*” into my functions that replaces the variables. I guess that expands to something else. I ended up having to pass in the value like this to get it to work:

value="\"*\""

The most unexpected things slow me down…

I also had to fiddle with this function to replace the values in template files I copied to the /tmp directory for a while. This function is in my deploy/shared/functions.sh file.

The last thing I had to do was make sure I was passing the template along through all the intermediary functions to get the deployment function, and adjust the template variable code to accommodate a different file path, if the template variable has a path in it.

After much tweaking, success!

I only have two stacks because I deployed one stack twice, and I can see the correct policy ARNs in the template for both stacks.

I can also check the SCPs in the Organizations dashboard and see that they are correct there as well.

The root account will never be locked out because Service Control Policies don’t apply to it. However, Organizations actions are denied to any other account for these particular ARNs.

I’ll test these policies in a later post. Presuming the new user I setup cannot change the SCPs, even with full IAM and Organizations access in an account set up as a delegated administrator for AWS Organizations, then I will proceed with adding the code to limit users to changing their own credentials.

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