is it common to have a policy that needs to check both tfstate and tfplan?
so far i really only see examples of tfplan imports for sentinel.
but, say I want to check for the existence of a certain type of resource always exists in my environment (a monitoring alert, for example)
I do a terraform apply, it passes my policy that checks tfplan, and the resource is created
later, i do a tf apply to add some other unrelated resource. the resource my policy checking already exists in the state, but the policy check would fail because it’s only checking tfplan.
so i would think i want a policy that checks both tfstate and tfplan for a more comprehensive view of my cloud environment, right?
Thanks for reaching out and apologies for taking so long to respond. My notifications seem to be all messed up on my end and I didn’t get an email about your post
To answer your initial question, yes it’s pretty common for users to have policies that leverage more than one import type within a policy. There are no hard and fast rules regarding which imports complement each other etc. It really just depends on the problem that you are trying to solve.
That being said, I would proceed with caution when it comes to using multiple imports and having multiple rules within a policy as this can lead to unexpected behaviour during rule evaluation.
As you are aware, a policy has a main rule which is evaluated by Sentinel based on the body of your policy. This rule has an enforcement level which can either be hard-mandatory, soft-mandatory or advisory. When evaluating tfstate you probably want to have the level of enforcement set at either soft or advisory so that you can notify the end-user of the fact that their state is not compliant and should remediate their configuration. On the other hand, if your policy is based on the tfplan import you may want to hard enforce the policy which would mean that the tfstate and tfplan cannot coexist in a harmonious fashion.
Again it all comes down to the rules and how you would like to enforce them. Enforcement is global and therefore affects main as well as any child rules that may be evaluated within main. If you are cross-referencing data between imports that should be fine but if you are writing a rule for specific import then I would consider splitting it out to a separate policy. Separating policies also makes the debugging process a bit more straight forward which is always a win in my book
