Just-in-time approvals

Just-in-time (JIT) access expires on its own. A user asks for access, an approver approves it, and Trustle removes it when the time runs out. The approval policy on an entitlement controls who must approve a request and the longest duration a user can ask for.

How it works

An approval policy exists at three levels:

1. The organization default. Admins edit it on the Policies page, if your organization has it enabled.
2. The connection policy, on the connection’s Approval Policies tab.
3. The entitlement policy, on the entitlement’s Approval Policies tab.

Trustle merges the levels one setting at a time. For each setting, the lowest level that sets it wins. An entitlement with no policy of its own uses its connection’s policy.

When an approver acts on a request, Trustle checks it in this order:

1. If an admin approves with admin override, and the policy allows admin override, the request is approved. The duration must still be within the policy maximum.
2. The duration must be within the Maximum Request Duration. Trustle rejects a request that asks for more.
3. The approval routing decides who must approve. If the user has a live self-provisioning eligibility for the entitlement, Trustle approves the request automatically. A request to extend the eligibility itself is the exception: it always goes to an approver.

By default, an approver can approve their own request. For example, a user who is a designated approver for an entitlement can request it and approve it. The policy setting that blocks this has no control in the UI.

Durations follow these rules:

• Trustle accepts any duration from 1 minute to 730 days, within the policy maximum.
• A week is 7 days, a month is 30 days, and a year is 365 days.
• A request that nobody approves or denies within 7 days shows Expired. The user can submit a new request.

When access expires, Trustle removes it from the connected system. For a role elevation, such as a higher role on a GitHub repository, Trustle returns the user to the role they held before. It does not remove the user.

Note

Break-glass access is a separate policy option. It approves requests automatically for users who are on call in a connected on-call provider. This page does not cover it.

Before you start

• You need the Trustle admin role. Only admins can open Settings and change policies.
• Connect the system that holds the entitlement. See the page for your system under Integrations.
• Decide who approves requests for the entitlement: the requestor’s manager, a list of users, or both.

Configure just-in-time approvals

Step 1: Set the durations that users can pick

1. In the sidebar, click Settings.
2. Find the Access Request Durations card. These durations appear in the access request pickers.
3. To add a duration, enter a number in Duration, select a Unit (Minutes, Hours, Days, or Weeks), and click Add. For example, enter 4 and select Hours.
4. To remove a duration, click the remove icon next to it.
5. Click Save Changes.

The default list is 1 hour, 1 day, 1 week, 1 month, 3 months, and 1 year. The list holds 1 to 20 durations. Each duration must be between 1 minute and 730 days.

The list controls only what the pickers show. Trustle also accepts other durations within the limits above. A picker does not show a duration longer than the entitlement’s maximum.

Step 2: Customize the entitlement policy

1. In the sidebar, under Govern, click Connections, then open the connection and the entitlement.
2. Click the Approval Policies tab. The Approval Policy card shows the policy that the entitlement inherits.
3. Click Customize Policy. Trustle copies the connection policy to the entitlement so that you can edit it. A later change to the connection policy does not change the copy.

To go back to the connection policy, click Reset to <connection> Defaults, then click Reset Policy.

Step 3: Set the maximum request duration

In Maximum Request Duration, select the longest time that a user can request: 1 Hour, 1 Day, 1 Week, 1 Month, 3 Months, or 1 Year.

A policy with no maximum shows Unlimited. For JIT access, select a short maximum, such as 1 Day.

Step 4: Select the approval routing

In Approval Routing, select who must approve requests for this entitlement:

Option	Who approves
Manager	The requestor’s manager.
Single Approval	Any 1 of the Designated Approvers. The first approval completes the request.
Quorum Approval	At least the Quorum Size number of the Designated Approvers. The quorum size cannot be more than the number of approvers.
Two-Level Approval	One approver from First-Level Approval, then one approver from Second-Level Approval.

A policy can also carry Department-Based Routing, which approves requests from members of named departments automatically. The form shows it but cannot create or edit it. To replace it, select another routing.

For Two-Level Approval, set each level to Designated Approvers or Requestor’s Manager. Both levels cannot be Requestor’s Manager. The same user cannot be in both levels.

If a level uses Requestor’s Manager and the requestor has no manager, Trustle denies the request. If admin override is on, the request stays pending so that an admin can approve it.

Step 5: Set admin override

Turn on Allow Admin Override to let Trustle admins approve or deny requests before the designated approvers. If no policy level sets this option, admin override is on.

Step 6: Set escalation (optional)

1. Turn on Escalate Unanswered Requests. When nobody acts on a request within the delay, Trustle adds the escalation approvers to the request and notifies them.
2. In Escalate After, select a delay, such as 4 Hours. The delay must be at least 1 minute and less than 7 days.
3. In Escalation Approvers, select one or more users.

The original approvers stay on the request. One escalation approver can approve the request alone, even when the policy requires two levels or a quorum. Trustle escalates a request one time only.

Step 7: Save the policy

Click Save Changes.

To let a user turn the access on again without a new approval, turn on Self-Provisioning. See Self-provisioning.

What users see

A requestor selects the entitlement, selects a duration, and submits the request. The picker shows only durations up to the entitlement’s maximum.

Approvers get a notification in Slack, Teams, or email, based on the organization’s configuration. The email has a Review Request button that opens the request. An approver approves or denies the request there, or from their Inbox. Admins also see every request on the Requests page under Govern. A pack or basket request is decided on the Requests page, which the Inbox link opens for approvers too.

Before an approver decides, the approver can change the duration or the role of the request, or move the request to a different entitlement on the same connection. After one required approver approves, these changes are not available. A new duration must be within the policy maximum. The request history records each change.

A user can extend access before it expires. Trustle adds the new duration to the current end date. Each extension must be within the maximum, but the total can be longer.

For a role elevation, the user sees the elevated role and the role they return to. For example, a user with the write role on a GitHub repository requests the admin role for 1 week. The grant message says that the role is elevated to admin and reverts to write on expiry. A reminder before expiry says that the role will revert. After expiry, a message confirms that the role reverted and that the user still has that access. An elevation cannot last longer than the access the user held before it.

Related

• Self-provisioning
• Expiration notifications
• Privilege packs
• GitHub
• Glossary