CAF_EnvironmentTag tag key should be mandatory

[ReneRebsdorf]

Correct me if I am wrong, but when reading PSRule.Rules.CAF: If a resource is missing the Environment tag as per CAF_EnvironmentTag, then it is not checked.

E.g. if CAF_Environments is "dev" and "prod", but "Environment" is not set, there is no failure in tests for the missing "Env: dev" or "Env: prod".

On the topic of tags, CAF has this to say none of 'Minimum suggested tags' are referenced here

Is this by design?

[BernieWhite]

@ReneRebsdorf It's a fair comment, and maybe the rule should be like that. Currently it validates the environments used.

So you'd need to combine it with CAF.Tag.ResourceGroup or CAF.Tag.Resource or both depending on your specific requirements.

i.e. If you have Azure Policy applying the tag from the resource group to all child resources, you may not require tags on IaC resources only resource groups.

Does that make sense or do you still feel there is a strong case for simplification such as you have suggested?

[ReneRebsdorf]

I see where you are coming from, and I agree to your solution from a technical point of view.

However, when I first started using PSRule.Rules.CAF and PSRule.Rules.Azure, the sole purpose was to ensure we were compliant with best practices as early as possible, and to automatically be made aware of updates/changes, so we can either resolve immediately, or backlog it with a suppression. I.e. "shift-left".

These "linters" should in my opinion come with a default configuration which adheres to the exact recommendations from CAF, without the users having to modify the configuration file(s).

But if this is not desired I can understand that, but in that case discrepancies with suggested resolutions should probably be described in the README?

Just my 2 cents

[BernieWhite]

Thanks for your perspective @ReneRebsdorf. I think we can achieve that by updating the strict baseline to model the current state of CAF.

[ReneRebsdorf]

Thanks for your perspective @ReneRebsdorf. I think we can achieve that by updating the strict baseline to model the current state of CAF.

Sounds like the perfect way to implement it, not sure why we aren't using strict at the moment to be honest.