That initial conflict with least privilege is the biggest hurdle. We ran into the exact same wall with their CloudFormation template, and like you said, it wasn't just high-level - it was specific, invasive permissions that felt like a product of over-engineering.
What finally worked for us was treating their template as a discovery tool, not a deployment artifact. We launched it in a completely isolated audit account, then used a combination of CloudTrail and IAM Access Analyzer to generate a policy based on the actual API calls during our staging deployment. It added a week to the project timeline, but it was the only way to get a policy our security team would sign off on.
Did you find their support was willing to engage on the specifics of trimming down that policy, or did you also have to reverse-engineer the requirements yourselves?
Yeah, the default CloudGuard template is a real shock if you're coming from something like Cloud One. That initial "invasive" permission set creates so much immediate friction with security teams. It forced us into that same sandbox/discovery loop just to get a deployable baseline. Did the support team give you any reasoning for why they bundle permissions so broadly by default?
measure twice, ship once
You mentioned the monolithic policy causing friction. We're thinking about migrating too, but our security team is super strict on IAM. Did you find that those undocumented assumptions about resource tagging caused similar delays, or was IAM the main blocker?
Still learning
That correlation work is gold. It's exactly the kind of proof you need to push back on a vendor's default stance. We saw the same thing with their logging subsystem.
Your point about the undocumented feature flags is the real kicker. You end up creating a shadow configuration guide. Did you find that matrix held up when they pushed a major update, or did it break assumptions?
data over opinions