Control Tower's ProActive Controls are implemented using cfn-guard and CloudFormation hooks. It would be great if pro-active could also be "while writing templates"
Use Case
Organizations enabling proactive controls within Control Tower would be able to verify their templates before deploying
Proposed Solution
using the same rule files and numbers (they're documented and available in the Control Tower console) would be a nice way to work with this. This might mean a second folder under rules (instead of rules/aws it could be rules/aws-ct)
Rule sets could use the frameworks from the Control Tower console (they're not in the documentation), possibly prefixed with CT_ so customers can decide if they want to use the current set of rules, or explicitly check against the Control Tower rules.
Other information
The current rule files do not allow suppressing the rules using the metadata section (instead you disable the guard rail in control tower). Keeping them exactly the same is a decent trade-off.
This would probably mean that customers will create there own rule sets, to match their Control Tower configuration. It might be worth investigating a way to make that easier (eg. a way to generate rule sets at run time)
I could technically create these rules myself, but I assume they are available internally in a way that does not require me to copy-paste from a website
Acknowledge
[ ] I may be able to implement this feature request
Description
Control Tower's ProActive Controls are implemented using cfn-guard and CloudFormation hooks. It would be great if pro-active could also be "while writing templates"
Use Case
Organizations enabling proactive controls within Control Tower would be able to verify their templates before deploying
Proposed Solution
using the same rule files and numbers (they're documented and available in the Control Tower console) would be a nice way to work with this. This might mean a second folder under rules (instead of rules/aws it could be rules/aws-ct)
Rule sets could use the frameworks from the Control Tower console (they're not in the documentation), possibly prefixed with CT_ so customers can decide if they want to use the current set of rules, or explicitly check against the Control Tower rules.
Other information
The current rule files do not allow suppressing the rules using the metadata section (instead you disable the guard rail in control tower). Keeping them exactly the same is a decent trade-off.
This would probably mean that customers will create there own rule sets, to match their Control Tower configuration. It might be worth investigating a way to make that easier (eg. a way to generate rule sets at run time)
I could technically create these rules myself, but I assume they are available internally in a way that does not require me to copy-paste from a website
Acknowledge