[Enhancement] Support including/import a guard file from another guard file.

[fabiodouek]

Is your feature request related to a problem? Please describe.

I currently have variables defined in cfn-guard which I would like to be able to import into multiple guard files. These variables contain list of AWS Account, OrgId, OrgPaths and there are also common guard functions which I would like to share across multiple guard files.

Describe the solution you'd like

One of the two options: 1) Ability to include a guard file 2) Ability to define global scope variables and functions. Then I could simply invoke a list of guard files and the ones with global scope would be available in the context.

Describe alternatives you've considered

At the moment I'm considering to generate guard rules on the fly, by merging multiple files prior to the execution.

[akshayrane]

Hi @fabiodouek

This looks like an interesting enhancement in terms of extending rules and eliminating some of the redundancy that we would otherwise have.

The first requirement seems very clear, however with the second one, are you hoping to use multiple scopes of variables and functions that when invoked in a context of a directory or multiple rules would still persist? Could you please provide a detailed example of the use-case for us to better understand the ask? Is it an alternative to including other guard files holding these variables and functions?

Ability to define global scope variables and functions. Then I could simply invoke a list of guard files and the ones with global scope would be available in the context.

HTH, Akshay

[fabiodouek]

Hi @akshayrane ,

The first option is preferable as it's more flexible and clean. The second option is an implementation alternative. Today multiple rules are loaded in its own context. This option would not require the ability to import rules, but instead when defining the scope as global (either for a function or variable), then would be set in the context of all rules. The downside is that will apply to all of them, while the first option you will have the choice of define at a more granular level.

The use case here for either scenarios is for Resource Policies, where we define specific service rules with a wrapper, and then parameterized rules in the core, with most of the logic, which can be re-used.

[razcloud]

Thank you for clarifying @fabiodouek. Will discuss this with the team and report back on this Issue.