Feature | project.yml definition checks and validations

[exequielrafaela]

What?

• ✅ Since our recommended use case for the Multi-Account reference architecture under the Well-Architected framework implies that we have default OUs and SCPs. We will need to add some validation scheme for our project.yml, probably some check before rendering the templates.
• ✅ It could be a list of rules that the project.yaml has to comply with and reflect this in warnings or errors.
• ✅ 1st Vaidation: Check that the OUs definition is not empty; later we can keep adding checks and conditions that will rise as necessary. Hence OUs section must exist and not be empty is a good start.

📒 CONSIDERATION: Can OUs and SCPs be left as optional? But with a big WARNING message stating that it is a bad practice. May be the user want to remove them, but it wouldn't be following best practice.

Why?

• If we get a malformed project.yaml the rendering of the templates will failt with very little grace.

Concern

• We should always have AWS Organizations OUs as best practice.
  • Would we then be leaving this to user preference?
  • What if the user want to dismiss account's OUs?
• Just because by not creating OUs we would lose the SCPs and their default association to OUs to limit permissions. This should (must) be a must considering security by design. Although it is not (completely) wrong to make it optional, but then the user could disregard best practices if it undercuts OUs and SCPs.

[angelofenoglio]

Additional checks to consider:

• Make sure the email addresses used to create the project are different from the default/example ones (maybe mark them with a special character?)
• Check for other values that may create conflict down the line either from a project rendering standpoint or a architecture deployment standpoint.