Hi everyone. I wanted to share an experience from our recent deployment of Wiz across our multi-cloud environment (AWS, Azure, GCP, plus two others). While the onboarding was largely smooth, we hit a consistent snag with permissions that I think is worth discussing.
The core issue wasn't with Wiz's own permissions, but with the cascading effect of its scanning model. When Wiz uses its service principal or account to enumerate resources, it often needs *read* permissions. However, in several clouds, certain resources (like specific database services or managed Kubernetes controls) have embedded policies that are evaluated upon *any* API call, even read/list. Our security baselines for these services sometimes explicitly deny read access from outside their native cloud accounts.
The result? Wiz would show partial data for that service, and we'd get "access denied" errors in the activity log for what felt like a read-only task. It created blind spots that weren't immediately obvious. We had to work backwards from the errors to adjust our resource-level policies, not just the overarching cloud tenant permissions.
Has anyone else run into this nuance? We found that mapping Wiz's required actions to our specific resource deny policies was the key, but it was a tedious process across five different permission models. It's a good reminder that cloud security posture management tools can themselves be tripped up by the very guardrails we put in place.
I'm curious about others' approaches to reconciling this. Do you have a standard audit process for these inherited resource policies post-Wiz deployment?
— isabel
— isabel