What Happens When You Change the Parent ID for an Organizational Unit CloudFormation stack?

ACM.410 Exploring the implementation of the AWS Organizations organizational unit hierarchy — do your service control policies still apply?

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

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

🔒 Related Stories: AWS Organizations | IAM | Deploying a Static Website

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

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

My last post demonstrates how to recursively query for the ID associated with an AWS Organizational Unit.

In this post I want to take a look at an issue that can occur in your account when deploying Organizational Units with CloudFormation stacks.

Recall this is the OU structure I wanted to create:

But it looks like I made a mistake because nonprod should be under deploy and it ended up one level up under orgadmin.

So how can I fix that?

Well, what if I simply redeploy the resource after fixing the deployment script to pass in the correct parent name? What will that do?

I fix the name of the parent OU in the nonprod deployment script:

Now instead of redeploying all my OUs with my all script, I can deploy just that single OU.

That’s the beauty of micro-templates.

I redeploy my nonprod OU:

While I’m here I replace this ugly code:

With this call to my new function from the last post:

I redeploy that OU. What happens?

A NEW OU gets deployed according to the above specifications, but the old OU still exists in the wrong place, along with all the child accounts under it.

So now I have two organizational units named nonprod in two places in the organizational hierarchy from one template and what seems like it should be one stack. In other words, I can’t use CloudFormation to update the parent ID for an OU.

The way CloudFormation and Organizations teams implemented Organizational Units does not update an Organizational Unit when the related stack parent ID changes. I can imagine why — they are using both the organizational unit and the parent as some kind of ID, but that does not seem like how it should have been implemented.

It seems like pointers for parent IDs would better solve this problem. There should be a one to one relationship between an OU ID and a parent ID but you should be able to easily change the parent ID.

Here’s what I mean.

Perhaps this is what someone did something like this, thinking that they needed to have the OU ID plus Parent ID for the primary key in some table to allow the same OU name to be created under multiple parent OUs. This is not correct. There should be two different nonprod OU IDs. It does appear that all the OU ids are unique in AWS.

You don’t need the Governance-Id as part of the key. (Again, only speculating. Either that or the implementation is outside the database in the code that is making the updates.)

The above causes problems when I tried to move my nonprod OU under the deployment OU. In order to do that I would have to create a new resource with a new ID. Let’s say the Nonprod OU has a bunch of children. All those children are referencing the parent id of the first nonprod OU and when the new record moves all the child OUs will be pointing to the wrong place. So I would have to update all their IDs as well.

What if there are SCPs linked to those IDs? Well are all the SCPs no longer pointing to the right place? Are they pointing to Nonprod-Id + Governance-Id but now I have this new resource — Nonprod-Id + Deployment-Id so they are no longer linked? I’m not sure what happens in that case to be honest. I didn’t get that far. The implementation just seems like it has some logic flaws and needs to be fixed in any case.

What should be happening is that the OU ID alone is the identifier. If you have two OUs named prod, then they have two separate IDs (and they do.)

There should be a database constraint or a secondary index, not a primary key on the above table to enforce any additional uniqueness in the data.

Let’s say I have this structure and I want to move my OU below with ID 2.

I should be able to simply update the parent ID in the underlying data store for a particular OU. None of the child IDs need to change, and yet they all show up in the right place in the tree. That is what should be happening when I update the parent ID for an OU in CloudFormation.

Or in other words, instead of adding a new row, the table should now look like this:

And if you can’t do that, perhaps you’ve selected the wrong type of data store to solve the problem that doesn’t support the data structure you need.

When I update the parent ID of the OU above, I’m not changing my underlying CloudFormation template in any way. I would expect property changes to update the resources deployed by that stack. The logical ID of the original resource should remain unchanged but the attributes should be changing. I know there are cases where changing a name creates a new resource but that should also create a new stack. I didn’t change the name of my resource.

The above design also ensures that when you have SCPs assigned to an OU ID like this:

That all the relationships remain in tact when you update a parent ID in a CloudFormation stack:

The only thing that changed in the above template was the parent ID (4) for OU with ID 2.

I can’t see the actual code so some of the above is speculation as mentioned but in any case, something doesn’t seem to be working the way it would be under ideal circumstances.

In any case, you should be aware of how AWS Organizational Unit CloudFormation templates work and any time you make changes, make sure you have all the correct parent-child relationships in your hierarchy and that all the OUs you have in place are still applied the way you expect.

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