Let me guess. You followed the official Palo Alto deployment guide for GCP, used the provided Terraform or deployment manager script, and now you're staring at a dashboard full of errors or, more likely, a completely empty inventory. The "access denied" messages are piling up, and the Prisma Cloud documentation's circular advice of "ensure the service account has the necessary permissions" is about as helpful as a screen door on a submarine.
This isn't your fault. This is the classic Prisma Cloud onboarding ritual, a rite of passage where you learn that their "least privilege" IAM role recommendations are often incomplete or contextually wrong depending on what GCP services you actually use. The bundled roles like `roles/viewer` and `roles/cloudasset.viewer` are a decent start, but they are nowhere near sufficient for a full inventory, let alone for any of the security or compliance scanning features. If you want container registry scanning, Kubernetes Engine assessment, or even basic Service Account key discovery, you'll be met with a wall of silent failures.
The real problem is that Prisma's model assumes a level of access that borders on `roles/owner`, but they can't admit that in the sales cycle because it violates every security principle they claim to uphold. So they give you a minimal set, let you fail, and then you have to engage their professional services or spend days in trial-and-error, expanding the permissions until the errors stop. You're essentially performing your own security audit on their product's requirements.
Start by checking the Prisma Cloud Activity Log for the specific error details; they are slightly more descriptive than the UI alerts. Then, brace yourself for the real list. Beyond the basics, you will likely need to add permissions for:
- `cloudasset.assets.list` (with broader resource scope)
- `container.*.get` and `list` for GKE
- `storage.buckets.get` and `objects.list` for Cloud Storage
- `serviceaccount.keys.list` (which is a massive permission, by the way)
Each one of these opens a new vector and increases your TCO through increased security review overhead. You are now building a custom, highly privileged service account for a closed-source SaaS product that cannot function without peering into every corner of your project. Consider the irony of using a tool for cloud security posture management that itself requires a dangerously permissive posture to operate.
My suggestion? Before you go adding `roles/editor` just to make the noise stop, document every single permission you add beyond their initial set. Then ask your Palo Alto account team to justify why each one is necessary for the features you purchased, and get it in writing. This will become invaluable later when you're negotiating your renewal or assessing the migration cost to a more transparent or open-source agent-based alternative.
Just my two cents
Skeptic by default
You're absolutely right about it feeling like a rite of passage. I've been there, and the frustration is real. It gets worse when you start enabling specific modules, like BigQuery scanning or Cloud SQL vulnerability assessments. Each one seems to require a separate, obscure permission that wasn't in any of the "getting started" guides.
My workaround, which is terrible but effective, was to temporarily assign the service account the `roles/editor` role on the entire project, just to get Prisma Cloud to actually pull *something* in. Once I saw data flowing, I used the GCP console's "Check my permissions" tool on the service account while triggering different Prisma scans. This let me see the exact API calls that were failing, and I could then build a custom role piece by piece. It's a huge hassle, but it got me closer to actual least privilege than their documentation ever could.
Honestly, their permissions model feels like it was built for a GCP that existed five years ago.
Automate the boring stuff.