Upgrade from JIT Access

If you're currently using JIT Access, you can upgrade to JIT Groups. This article describes the functional differences between JIT Groups and JIT Access, and how to perform an upgrade.

Functional changes

JIT Access has been narrowly focussed on privileged access management and the ability to activate individual IAM role bindings for short period of time (typically less than a day).

JIT Groups expands this scope to include self-service access management, or entitlement management. You can use JIT Groups not only for managing privileged access, but all types of access to Google Cloud resources.

The following table summarizes key differences between JIT Groups and JIT Access:

	JIT Groups	JIT Access
Use cases	- Entitlement management - Self-service access management - Privileged access management	Privileged access management
Entitlements being managed	Memberships to Cloud Identity security groups	IAM role bindings
Scope of configuration	JIT group, system, environment	Global only
Granularity of entitlements	Groups can "bundle" any number of roles, across one or more projects	Single IAM role
Grant access to projects
Grant access to resources (IAM conditions)
Activation without approval
Activation with peer approval
Activation with manager approval

Compatibility with JIT Access

JIT Groups supports "JIT Access-style" eligible role bindings. When you enable JIT Access compatibility, JIT Groups surfaces such eligible role bindings as a JIT Group:

• Role bindings that use the IAM condition has({}.jitAccessConstraint) are mapped to JIT Groups that permit self-approval.
• Role bindings that use the IAM condition has({}.multiPartyApprovalConstraint) are mapped to JIT Groups that require peer approval.

This compatibility is subject to the following limitations:

• The web interface lists all available projects instead of a personalized list of projects. This behavior is similar to the AssetInventory catalog.
• A small number of predefined IAM roles can't be mapped because their name exceeds the limits imposed by Cloud Identity for group names.
• Roles that use resource conditions can't be mapped.
• When requesting approval to join a group, users can't select among possible approvers. Instead, the approval request is sent to all users who are allowed to approve.
• JIT Groups doesn't support Pub/Sub notifications.

Upgrade an existing deployment

To upgrade your existing JIT Access deployment, do the following:

1. Open Cloud Shell or a local terminal.

   Open Cloud Shell

2. Set an environment variable to contain your project ID:

   gcloud config set project PROJECT_ID
   

   Replace PROJECT_ID with the ID of the project that contains your JIT Access deployment.

3. Clone the GitHub repository and switch to the jitgroups/latest branch:

   git clone https://github.com/GoogleCloudPlatform/jit-access.git
   cd jit-access/sources
   git checkout jitgroups/latest
   

4. Download the configuration file that you used previously to deploy the application and save it to a file app.yaml:

   App EngineCloud Run

   APPENGINE_VERSION=$(gcloud app versions list --service default --hide-no-traffic --format "value(version.id)")
   APPENGINE_APPYAML_URL=$(gcloud app versions describe $APPENGINE_VERSION --service default --format "value(deployment.files.'app.yaml'.sourceUrl)")
   
   curl -H "Authorization: Bearer $(gcloud auth print-access-token)" $APPENGINE_APPYAML_URL -o app.yaml
   cat app.yaml
   

   If downloading the file app.yaml fails, you can download your current configuration in the Cloud Console.

   gcloud config set run/region REGION
   gcloud run services describe jitaccess --format yaml > app.yaml
   

   Replace REGION with the region that contains your existing Cloud Run deployment.

5. Verify that you're using the AssetInventory catalog:

   grep RESOURCE_CATALOG app.yaml
   

   If you see the output RESOURCE_CATALOG: AssetInventory, then you're using the AssetInventory catalog. Otherwise, you must switch to the AssetInventory catalog first before you can proceed with the upgrade.

6. Add two environment variables to app.yaml:

   PRIMARY_DOMAIN: "DOMAIN"
   ORGANIZATION_ID: "ORG_ID"
   

   Replace the following:

   • DOMAIN: the primary domain of your Cloud Identity/Workspace account domain.
   • ORG_ID: the organization ID of your Google Cloud organization.

7. Enable the Cloud Identity and Groups Settings APIs:

   gcloud services enable cloudidentity.googleapis.com groupssettings.googleapis.com
   

8. Deploy the application:

   App EngineCloud Run

   sed -i 's/java11/java17/g' app.yaml
   gcloud app deploy --appyaml app.yaml
   

   PROJECT_ID=$(gcloud config get-value core/project)
   
   docker build -t gcr.io/$PROJECT_ID/jitaccess:latest .
   docker push gcr.io/$PROJECT_ID/jitaccess:latest
   
   IMAGE=$(docker inspect --format='{{index .RepoDigests 0}}'  gcr.io/$PROJECT_ID/jitaccess)
   sed -i "s|image:.*|image: $IMAGE|g" app.yaml
   
   gcloud run services replace app.yaml
   

To allow JIT Groups to manage Cloud Identity security groups, you must grant it the Groups Admin role in your Cloud Identity or Workspace account.

Note

For JIT Access, it was sufficient to grant the Groups Reader role because it only needed to read access to groups. JIT Groups requires the Groups Admin role so that it can create and manage security groups.

You only need to perform these steps once.

1. Open the Google Admin console and sign in as a super-admin user.

2. Go to Account > Admin Roles:

   Open Admin Roles

3. Click Groups Admin > Admins.

4. Click Assign service accounts.
5. Enter the email address of the application's service account, then click Add.
6. Click Assign role.

Test

You can now access the JIT Groups web interface:

1. Select the classic environment. This environment contains the JIT croups that correspond to your eligible role bindings.

2. Click Reconcile to let JIT Groups check for legacy roles that can't be mapped to JIT groups. This process can take a few minutes.

3. Verify the results to see if there are any groups that can't be mapped.

Roll back

If JIT Groups doesn't work as expected, you can roll back the upgrade by doing the following:

App EngineCloud Run

1. Open the Cloud Console and go to App Engine > Versions:

   Open App Engine Versions

2. Select a previous version and click Migrate traffic.

3. In the Google Admin console, revoke the Groups Admin role for the application's service account.

1. Open the Cloud Console and go to Cloud Run:

   Open Cloud Run

2. Open the details for jitaccess.

3. Select the Revisions tab.
4. Select a previous version and click ... > Manage traffic.
5. Assign 100% of traffic to the previous version and click OK.
6. In the Google Admin console, revoke the Groups Admin role for the application's service account.