Bug: Powerpipe Azure Compliance Mod benchmark run where query for tag service=Azure/ActiveDirectory not working

[sfunkernw]

Describe the bug

In the past I could run compliance mods, such as the Azure compliance mod and use the where filter to skip checks for services I don't have permission, e.g. ActiveDirectory checks as follows:

steampipe check azure_compliance.benchmark.cis_v150 \
        --where "tags->>'service' != 'Azure/ActiveDirectory'"

This had performed the Azure CIS v1.5.0 benchmark, but without the AzureAD checks (which I have often not permission to do and I also want to avoid the long running guest user queries).

When I try the same with powerpipe in the analog ways, the AzureAD CIS checks are not skipped:

powerpipe benchmark run "azure_compliance.benchmark.cis_v300" \
        --where "tags->>'service' != 'Azure/ActiveDirectory'"

powerpipe benchmark run azure_compliance.benchmark.cis_v300 \
  --where "tags->>'service' not in ('Azure/EntraID','Azure/ActiveDirectory')"

Steampipe version (steampipe -v): v1.0.3
Steampipe Azure plugin version:

• hub.steampipe.io/plugins/turbot/azure@latest 1.2.0
• hub.steampipe.io/plugins/turbot/azuread@latest 1.0.0
  Powerpipe version (powerpipe -v): v1.2.2
  Azure Compliance Mod version (powerpipe mod list): github.com/turbot/steampipe-mod-azure-compliance@v1.2.0

Expected behavior

I expect that all CIS benchmark controls that have the tag service = Azure/ActiveDirectory (see a list of them here), are not executed in the benchmark run with the --where "tags->>'service' != 'Azure/ActiveDirectory'" filter.

Please note, the service tag is correctly set in the newer CIS v3.0.0 benchmark description under https://hub.powerpipe.io/mods/turbot/steampipe-mod-azure-compliance/benchmarks/control.cis_v300_2_11?context=benchmark.cis_v300/benchmark.cis_v300_2#tags could it be that the service tag is somehow not propagated to the control table? If that would be the case, it would be rather an issue of the Mod instead of Powerpipe itself.

Further, this issue seems to be related to the stale-closed issue #492 .

[pskrbasu]

Apologies @sfunkernw, this does look like a serious issue. I will take a look and keep this thread updated.