Why I Am Not Using AWS Organizational Unit for My Environment Name

ACM.363 Complications querying organizational data from AWS child accounts

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

⚙️ Part of my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: AWS Security | AWS Organizations

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

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

In the last post I created a directory structure for CloudFormation templates based on the CloudFormation documentation.

Generating A Directory Structure For CloudFormation Templates

ACM.362 Leveraging the AWS documentation to create a directory structure for CloudFormation templates

medium.com

In this post I am thinking about moving my templates around to deploy SSM parameters, but first I am going to explain how I would rather implement my environment and organization name, if I could.

Recall that I want to create environments and each account in the environment is going to have three SSM parameters:

org
env
adminaccount

I started thinking about this a bit more and really the environment is the OU name. For my example accounts I’ve been working with, the environment name is sandbox and I put the accounts in a sandbox OU. The OU name is [org]-[ouname]. So right now I’m thinking I could just allow roles to query their own OU to get those values. To get the parents for an ID we can use the list-parents command.

list-parents - AWS CLI 1.29.71 Command Reference

undefined

But when you run that command you get back something like this without a name which is not ideal. It would be easier if this returned a name instead.

In order to get the name we have to run a second command:

The other thing I have to do if I wanted to use this option is create a cross-account role to the account where the OUs get created. This poses some risks and more work than I really want to do, so I’m just going to populate these values in SSM parameters each time I deploy an account.

I wonder how much risk it would pose to list a customer-defined organization ID and the OU name when someone calls sts get-caller-identity. This is where I would ideally pull that information.

Either that or make it part of the account function, or both.

If I could easily grab the OU name and an organization ID (one I could define, not the AWS ID) then I could use those. But due to the complications above, I am just going to populate parameters in SSM for each account for now.

The ability to easy query a customer defined organization id and environment name from a child account is on my #awswishlist!

Update: As I morph my way through what I’m building — like pushing paint around on a canvas the way I used to do oil painting, as I’ve explained before — I’ve come around to using one top level OU for an environment. Check the blog home page for the latest and greatest, or the link to the code at the top of this post.

Cloud Security

Cybersecurity in a Cloudy World