Support for nested OU ID-to-account mapping

[tcmnal]

trafficstars

Is your feature request related to a problem? Please describe. Requesting support for nested OUs. Control Tower supports nested OUs since November 2021. It seems however that the cfct.manifest.manifest_parser module does not support this with its resolution of accounts in an OU.

Describe the feature you'd like Consider the org structure below. Suppose NestedOU1 and NestedOU2 contain some accounts, ['Account1','Account2'] and ['Account3','Account4'], respectively:

Root 
├── Workload
│           ├── NestedOU1
│           │       ├── Account1
│           │       └── Account2
│           └── NestedOU2
│                    ├── Account3
│                    └── Account4
│

It seems when I provide OU name 'Workload' in the manifest file, it does not resolve to any accounts, since there are none directly under it, only within its children OUs. I would like OU name 'Workload' to resolve to accounts ['Account1','Account2','Account3','Account4']

Additional context I suppose this might be considered a bug instead of a feature request because there is no caveat in the documentation indicating that this would not work

[greenaussie]

The correct way to target the leaf OU is as follows:

"A complete path (excluding Root) for the nested OU is required, using a colon as the separator between OUs" See https://docs.aws.amazon.com/controltower/latest/userguide/cfct-nested-ou.html

Workload:NestedOU1 Workload:NestedOU2

[tcmnal]

@greenaussie Thanks, but I am looking to target the OU 'Workload', without having to specify the OUs under it. The same way one might use 'Root' currently, rather than enumerating all OUs under it.

I did manage to make the necessary changes in cfct.manifest.manifest_parser and cfct.aws.services.organizations to support this, but I think it would be a useful feature to include for all.

[josemiguel-almagro]

Hi @tcmnal !

Could you please post the changes you made to make this working?

BTW, I'm currently trying to modify the StackSet creation to create SERVICE_MANAGED instead SELF_MANAGED in order deploy to a specific OU instead the accounts within that OU.

[balltrev]

@tcmnal thanks for the request! I'll create a backlog with the team to discuss this enhancement.

[kb-tonyj]

Would really like to see this feature, it will solve a few scaling issues we are having. Thank you

[glb]

Would very much like to see this feature as well; my expectation having read the documentation was that any accounts "under" the OU (even nested) would be included and that I wouldn't need to explicitly list all of the OUs.

[vinelias]

Maybe a middle ground, where we could specify when the pipe should behave recursively, using the notation Workload:*.

[mcripps9]

For SCPs, making the behavior optional as per @vinelias is a MUST because we specifically target SCPs to parent OUs and do not want them to propagate to the children and/or accounts because of the ridiculous 5 SCP per-node limitation.