I’ve been working with Google Cloud Privileged Access Manager at a growing scale and I’m curious how other teams are managing PAM as their entitlement footprint expands. We manage our entitlements as infrastructure as code. Every new project gets bootstrapped with a standard set of entitlements that come with rules for what services will be deployed and which groups will use the project. We’re now managing hundreds of rules spanning project, folder, and organization levels.
One thing that has stood out as we’ve grown is that the PAM API doesn’t really support a wide search operation. Both SearchEntitlements and SearchGrants require specifying a parent resource path, which makes it difficult to answer simple questions like “what entitlements are actually available to me” without iterating through multiple scopes and aggregating the results on the client side. The grant approval side has the same shape of problem, because there isn’t a single endpoint that returns all grants waiting for approval that a given user can respond to.
The other recurring theme is discoverability for end users. The web console has made some recent improvements by combining entitlements from different hierarchy levels and suggesting which ones you could request to get the privileges you need, but not all users prefer working in the web interface. The console can be slow at times, and users often run into a frustrating pattern where they visit a resource before their PAM grant is fully activated and hit a stale permission state that requires a hard refresh to resolve. For users who prefer the gcloud CLI the commands exist, but they usually require multiple steps that interrupt the workflow.
I started experimenting with a smoother terminal interface that talks to the PAM API directly and makes it easier to discover available entitlements and request them. The result so far is at GitHub - michalskalski/gpam · GitHub if you’re curious about the approach.
So what’s working for others? How do your users find and request the right entitlements? Are you using the web console, custom tooling, or something else? Is anyone building on top of the PAM API, and have you found workable patterns for cross-scope entitlement discovery, or for efficiently finding pending approvals? I’d love to hear what patterns have worked well in your environment.
Howdy @mskalski ,
Welcome on forum 
Happy to read about PAM, as this is my favourite topic to talks 
So, I’m dealing with PAM by default only either at org or folder level (rarely on project). We have dedicated function roles, like “DevOps, NetSec or OncallTeam”, which allows us to manage access in easier way ( with google workspace groups, dedicated per wider function). So we have for example bau_customer@example.com group, which is created per customer. Each group is eligible to request function entitlement, based on GWG access ( bau engineer can request 1 of 5 typical entitlements, while oncall engineer can only request oncall_entitlement). We’ve also separated NetSec entitlement only for netsec group, as this entitlement contain highly privileged roles.
Due to fact, that Google Workspace does not have built in JIT function, we’ve built Okta workflows to manage “eligibility to request” permissions. Such approach has been established due to the nature of our company (MSP with a lot of customers).
cheers,
Damian Sztankowski | GDE for Google Cloud | Google Cloud Ambassador
Hello @DamianS and thank you for your response! One reason we have entitlements per project is to give a more granular access. Our folders tends to have multiple projects. I saw a new functionality Privileged Access Manager overview | Identity and Access Management (IAM) | Google Cloud Documentation which allow to narrow the scope during the request, but for now it is not in stable API.
Could you tell me a bit more? I’m not sure I fully understood. Is the idea that the Okta workflow lets a user temporarily join the group that’s eligible to request an entitlement?
Yep. Because with PAM we want to eliminate static permissions or ghost permissions.
Best practice says to you should manage access not for single principal but for groups of principals, which in GC case can be handled by workspace groups. If we going to use PAM, we will eliminate static permissions, due to the fact that we can assign permissions with time-based approach. But what about principals which are under GW group? If you assign N principals to GW group as is, and then that group will be eligible to use PAM on GC side, you will mitigate one problem ( static permissions on IAM) but create another one (static access to eligibility). This is the reason why we are using Okta and Okta Wokflows to kinda steer who can do what and when
I’m attaching screenshot from my presentation about PAM and Okta Workflows.
Ah got it, thank you for explaining and attaching the diagrams. It is interesting usage of Okta workflows.
