JIT Access 1.1 now supports inherited roles and has a new UI
With Just-in-Time Access, we can implement just-in-time privileged access management on Google Cloud by allowing users to temporarily elevate their access to certain projects.
The application relies on the notion of eligible role bindings: These are role bindings with a
special IAM condition, has({}.jitAccessConstraint). Once we grant a user such an eligible role binding,
that role starts to show up in the JIT Access application, and the user can request to activate the role temporarily.
But a key limitation of the initial release of JIT Access was that it didn’t support inherited role bindings: If we wanted to grant a user eligible access to all projects in a folder, we couldn’t create the eligible role binding on the folder level: Instead, we had to create eligible role bindings for each project individually.
With JIT Access 1.1, this limitation no longer applies, and we can now grant eligible access on the level of projects, folders, or even entire organizations.
AnalyzeIamPolicy and resource expansion
The reason why the previous version didn’t support inherited role bindings had to do with the Asset Inventory
analyzeIamPolicy API:
JIT Access 1.0 performed a single query to find all role bindings (across all projects) for a user,
and then analyzed the result to identifiy eligible role bindings.
For each role binding that analyzeIamPolicy finds, it returns information about the
binding and the resource it’s attached to. Optionally, it can also “expand” all the (descendent)
resources that the binding applies to by inheritance.
The problem with resource expansion is that the list of resources can grow very large, and at some point, analyzeIamPolicy
(unlike analyzeIamPolicyLongrunning)
starts truncating the results. Relying on resource expansion to find inherited role bindings therefore proved unreliable for JIT Access and
the result was that inherited role bindings weren’t supported.
JIT Access 1.1 takes a slightly different approach to using the analyzeIamPolicy API:
Instead of trying to do everying in a single call, the application now performs two calls:
- In a first
analyzeIamPolicycall, JIT Access only searches for projects that a user can access. This call uses resource expansion – but it’s limited to checking a single permission only, making the call unlikely to hit the resource expansion limits. - In a second
analyzeIamPolicycall, JIT Access then searches for eligible role bindings. This call is scoped to a single project and doesn’t need to use resource expansion at all.
And this brings us to…
A new user interface
JIT Access 1.1 now features a new UI that uses a 3-step wizard to find and activate eligible roles:
This UI not looks a bit more sophisticated – but more importantly, it accomodates the new two-step approach of using the analyzeIamPolicy API.
Using REST instead of gRPC
A less visible change is that JIT Access now uses REST instead of gRPC to call Google APIs. This change helped shed a number of dependencies and bring the size of the JAR from 57 MB down to 26 MB. And as an added benefit, it’s now much easier to trace and debug calls using tools like Fiddler.
For detailed instructions on deploying Just-In-Time Access, see Manage just-in-time privileged access to projects on the Google Cloud website.