Multi-party approval with JIT Access 1.2

Version 1.2 of JIT Access now supports multi-party approval: When granting eligible access, we can now decide whether to allow a user to activate the access by themselves (self-approval), or whether they need approval from another user (multi-party approval).

Eligible role bindings

JIT Access works by adding the notion of eligible role bindings to Cloud IAM. Unlike a regular IAM role binding, an eligible role binding doesn’t grant the user access to a project yet: Instead, a user first has to explicitly activate the binding by using the Just-In-Time Access application. Activation is temporary and requires the user to provide a justification (like a bug or case number).

Eligible role bindings are IAM role bindings that have a special IAM condition, has({}.jitAccessConstraint). This condition has two effects:

1. It disables role binding so that the user can’t exercise their access yet.
2. It surfaces the role binding in the JIT Access application and entitles the user to activate the role binding. Activating the role binding requires the user to provide a justification, but no additional approval.

Version 1.2 now introduces a second type of eligible role binding, MPA-eligible role bindings. These are IAM role bindings that have a slightly different IAM condition, has({}.multiPartyApprovalConstraint). This condition has the following effect:

1. It also disables role binding so that the user can’t exercise their access yet.
2. It also surfaces the role binding in the JIT Access application – but activating the role requires the user to not only provide a justification, but also to request approval from another user.

Multi-party approval (MPA) isn’t a replacement for just-in-time self-approval (JIT). Instead, it’s a complement:

• For semi-privileged roles, we can allow users self-approve access.
• For highly-privileged roles, we can require users to seek approval from another party.

Multi-party approval process

Multi-party approval is handled on a peer-to-peer basis:

• If two users are granted an MPA-eligible role binding for, say roles/compute.admin on project-1, then they can approve each other’s requests.
• When soliciting approval, a user can see the list of qualified peers, and can choose the peer(s) to request approval from. It’s sufficient to gain approval from a single peer.

The approval process is driven by email, as illustrated by the following example:

1. Alice opens the JIT Access application, chooses a role, and enters a justification for why she needs to activate that role binding (such as BUG-12345).
2. Among the lists of qualified approvers, she selects Bob and requests his approval.
3. Bob receives an email indicating that Alice seeks his approval to activate a certain role binding.
4. Following a link in the email, Bob opens the JIT Access application. He sees the resource, role, and justification provided by Alice and approves (or disregards) the request.
5. Alice receives an email confirming that her access has been approved.

Implementation

Multi-party approval is an inherently stateful use case, and the obvious way to implement it would be to let JIT Access maintain a database of approval requests and their state. However, JIT Access doesn’t have a database and doesn’t maintain any state: The application is stateless and only operates on IAM policies. This is for two reasons:

• It helps prevent a situation where compromising the database could lead to a privilege escalation.
• It keeps the application simple.

To maintain its stateless nature, JIT Access uses email in combination with a signed token (“activation token”) to pass state information between parties. The following sequence diagram illustrates how that works (with some details omitted):

1. Alice opens the JIT Access application to see all her (JIT-/MPA-) eligible roles.

   To find eligible roles, JIT Access uses the Asset Inventory analyzeIamPolicy API to search for role bindings that apply to Alice and have an IAM condition that designates them as JIT- or MPA-eligible.

2. Alice chooses a role that requires multi-party approval.

   JIT Access now uses the analyzeIamPolicy API to find other users with MPA-eligible access to the same resource and role. It returns the list of users as qualified peers.

3. Alice chooses Bob as a peer and requests to activate the role.

   JIT Access validates the request and creates an activation token. This is a JWT that:

   • Contains all details of the approval request, including the requestor (Alice), reviewer (bob), the role, resource, and justification.
   • Expires after a certain number of hours.
   • Is signed by the application’s service account’s Google-managed service account key.

   Decoded, the activation token looks like this:

   {
         "alg": "RS256",
         "kid": "dfdf92ea289752b4a04f43430f613b97e20c8cae",
         "typ": "JWT"
       }.{
         "aud": "[email protected]",
         "exp": 1672872064,
         "iss": "[email protected]",
         "jti": "mpa-okLRSysI53M73mv5",
         "beneficiary": "[email protected]",
         "reviewers": [
           "[email protected]"
         ],
         "resource": "//cloudresourcemanager.googleapis.com/projects/my-project-123",
         "role": "roles/compute.admin",
         "justification": "BUG-12345",
         "start": 1672871764,
         "end": 1672872064
       }.[Signature]
   

   The app then sends an email to Bob. This email contains a link to the JIT Access application which embeds the activation token.

4. Bob follows the link to open the JIT Access application and reviews the request.

5. Bob approves the request. The application checks that the activation token is still valid, that its embedded details are authentic, and that Bob is allowed to approve the request.

   Using the information from the token, the application then:

   • Creates a temporary role binding to let access take effect.
   • Creates an audit log record indicating that Bob approved access for Alice.
   • Sends a confirmation email to Alice.

The token- and email based approach avoids the perils of using a database and maintains the stateless nature of the application. It does however also come with a few limitations:

• Alice can’t see the status of her approval requests in the JIT Access application.
• Similarly, Bob can’t see the history of his approvals in the JIT Access application and has to refer to his emails or the audit logs instead.
• If Bob doesn’t check his email and Alice’s access request times out, Alice isn’t notified.

Deployment

For now, multi-party approval is an optional feature that’s disabled by default and requires some extra configuration to enable.

For detailed instructions on deploying JIT Access, see Manage just-in-time privileged access to projectson the Google Cloud website.

• Share this article: