Skip to content

Concepts

This articles explains JIT groups and Environments, two key concepts used by JIT Groups.

JIT group

A JIT group represents a job function or role, for example Prod-Server-Admins or Finance-Datamart-Readers. The group bundles the IAM role bindings that users need to perform this job function or role, and defines the subset of users that are allowed to join the group.

As their name indicates, JIT groups are intended to be joined just-in-time:

  • As an administrator, you don't add members to JIT groups in advance, just because users might need certain access.
  • Instead, you entitle users to join the group just-in-time, when they need it.

Membership if a JIT group is always time-bound:

  • Each group defines an expiry, for example 90 days. After joining a JIT group, users remain a member, and retain access for this time period. Once the time period expires, they're automatically removed from the group.
  • Within the expiry period, users can keep extending their access.

By making all memberships time-bound, JIT Groups helps set the right incentives:

  • Without JIT Groups, users are incentivized to accumulate access, because giving up access incurs friction.
  • With JIT Groups, users are dis-incentivized to accumulate access: Retaining access incurs friction because users have to explicitly extend their access, while giving up access happens automatically.

Policy

JIT groups are defined in code, and a simple JIT group policy might look like the following:

- name: "Prod-Server-Admins"
  description: "Admin-level access to servers"

  # Who can view, join, approve?
  access:
    # Ann can join and doesn't need approval from anyone
    - principal: "user:ann@example.com"
      allow: "JOIN, APPROVE_SELF"

    # Ben can also join, but needs approval from someone else
    - principal: "user:ben@example.com"
      allow: "JOIN"

    # Everybody in the managers group can approve requests, but can't join themselves
    - principal: "group:managers@example.com"
      allow: "APPROVE_OTHERS"

  # Which constraints apply when joining this group?
  constraints:
    join:
      # Let users chose an expiry between 1 and 24 hours
      - type: "expiry"
        min: "PT1H"
        max: "PT24H"

  # What does the group grant access to?
  privileges:
    iam:
      # Some roles on sample-project-1
      - project: "sample-project-1"
        role: "roles/compute.osAdminLogin"
      - project: "sample-project-1"
        role: "roles/iap.tunnelResourceAccessor"
      - project: "sample-project-1"
        role: "roles/compute.instanceAdmin.v1"

      # A few more roles on sample-project-2
      - project: "sample-project-2"
        role: "roles/iap.tunnelResourceAccessor"
      - project: "sample-project-2"
        role: "roles/compute.instanceAdmin.v1"
  • The access section contains an access control list that defines who is allowed to join the group, and whether they need approval to do so.
  • The constraints section defines what additional constraints apply when users join the group. In addition to defining an expiry, you could require users to provide a justification, enter a ticket number, or check for other attributes.
  • The privileges section defines what access members of the groups are granted.

Provisioning

The first time a user joins a JIT group, the application provisions the following resources:

  • A Cloud Identity security group that corresponds to the JIT group.
  • IAM role bindings that grant the Cloud Identity security group access to Cloud resources, based on what's defined in the policy document.
  • A time-bound membership for the user.

As an administrator, you can see these groups in the Admin Console, and you can identify them based on their jit. prefix.

Environment

JIT groups and their policies aren't managed in isolation. Instead, each JIT group belongs to an environment.

An environment represents a segment of your Google Cloud organizational hierarchy. You can use a single environment for all your Google Cloud projects, but especially in larger organizations, it can be better to have multiple environments and delegate the management of each environment to different teams or business units.

For each environment, JIT Access maintains:

  • A policy document that defines the groups for this environment, stored in a Secret Manger secret.
  • A service account that's used to provision IAM bindings for resources in this environment.

To access the policy document, JIT Groups first impersonates the environment's service account, and then reads the document from the environment's Secret Manger secret.

Similarly, to provision IAM bindings for the environment, JIT Groups impersonates the environment's service account, and then uses that service account's identity to modify the IAM bindings.

Example with 3 environments

Using different service accounts for each environment helps isolate environments from another, and helps ensure that no single service account has direct access to all resources.

Policy document

To add or change the configuration of a JIT group, you modify the policy document that's stored in the Secret Manger secret. The changes then take effect with a short delay, typically less than a minute.

Because policy documents are YAML files, they're well suited to be managed using a GitOps workflow where you do the following:

  • You store the policy document in a Git repository.
  • You use a code review process for all proposed policy changes.
  • You let a CI/CD system (such as GitHub Actions) apply change by updating the Secret Manager secret.

Reconciliation

Over time, the policy document, the Cloud Identity security groups, and their IAM bindings might go out of sync. JIT Groups deals with this challenge as follows:

  • Whenever a user joins a JIT group, the application checks whether the privileges section of the group's policy has changed, and updates IAM bindings if necessary.
  • At any point in time, administrators (that is, users with RECONCILE access to the environment) can use the web interface to reconcile the policy.

On reconciliation, JIT Groups performs the following:

  • Find Cloud Identity groups that are no longer covered by the policy
  • Update IAM policy bindings if the privileges section of the policy has changed
  • Detect legacy roles that can't be mapped to JIT groups

The application reports any issues it encounters so that you can take action manually.

What's next

Deploy JIT Groups