Account provisioning does not work for tripple nested OUs

[jjleigh]

When you try to create an account provision using an OU that has tripple or more levels of nesting the provisioning does not work. No error no indication of failure. The messages are not enqueued but the links handler lambda is triggered.

Example structure:

• OU.1
  • Sub-OU-a
    • Sub-OU- 123
      • account 1
      • account 2
      • account 3
    • Sub-OU- 456
      • account 4
      • account 5
      • account 6
  • Sub-OU-b
    • Sub-OU- 789
      • account 7
      • account 8
      • account 9
      • account 10

If an account assignment is created for OU.1 none of the accounts nested in the grandchildren OUs will be assigned to the permission set. No error will occur.

[leelalagudu]

• @jjleigh , yep the solution does not yet cover nested OU's. For reference, we use ListAccountsForParent to discover the target AWS accounts list for provisioning account assignments, as well as rely on Move Account event for determining OU movement of accounts.
• As you can see, neither of these flows cater for nested OU's.
• We will extend the solution to first provide nested OU provisioning/de-provisioning on create/delete operations, that way when you create an account assignment for OU.1, account 10/3/6 are provisioned as well.
• We will prioritise detecting account moves within nested OU's for automated reconciliation for a later release.

Hope this helps, Leela

[jjleigh]

@leelalagudu Thank you for the update! Is it possible to have this change in before June 10?

[leelalagudu]

@jjleigh , I am aiming to push the first part of the change as part of the bug fixes for permission set schema validation. I will update in case this is changed

[leelalagudu]

@jjleigh , this is now handled with PR #89 . For reference, this is the behaviour the solution would have:

• When SupportNestedOU is set to true in your config, if an account assignment is set for OU.1, then all the 10 accounts will be provisioned with the account assignment. When the account moves anywhere under OU.1, the account assignment is still retained. When the account moves out of OU.1, then this account assignment is deleted.
• If an account assignment is set for Sub-Ou-456, then only accounts 4,5 and 6 would be provisioned. If these accounts 4,5 or 6 move into Sub-OU-123 / Sub-Ou-b/Sub-ou-a, then this account assignment is deleted.
• If you have a scenario where both these cases exist i.e. account assignment 1 is set for OU.1 and account assignment 2 is set for Sub-Ou-456, then all 10 accounts are assigned with account assignment 1. Accounts 4,5 and 6 are assigned with acount assignment 2. If accounts 4, 5 and 6 move out of Sub-ou-456 and into Sub-ou-123/Sub-ou-b/Sub-ou-a, then account assignment 2 would be removed, however account assignment 1 would still be retained. If accounts 4,5 and 6 move out of OU.1, then both account assignment 1 and 2 are removed. If account 1 moves into Sub-ou-456, then it gets added with account assignment 2 in addition to account assignment 1 that it already has.

Hope this helps with your use case, Leela