Access requests

ranting access to the resources via the requests is a basis of the Just In Time feature.

The requests are sent by the users via the Access Gateway, and an admin can accept or reject the request on Admin Panel in the Management section on the Requests tab.

Follow the steps to set up the Just In Time feature for your Safe resources:

1. Select Management > Safes tab and then select the Safe, or create a new one.
2. Check the Access request required votes option. Provide a number of the voters that will be deciding about each request to the Safe resources.

Note

Users with Admin role and users added as the Granted Users to the Safe are allowed to be the voters.

Having more than one voter, sets the request to be accepted by more than 1 authorized person. On the other hand, if one of the voters votes for rejection, the system automatically rejects the request.

3. Click Save.

All the requests are available in the Management section on the Requests tab.

Awaiting requests

Two types of requests are available for the user: immediate and scheduled.

Immediate requests can be set from now up to the next 24 hours.

When a user sends an immediate request, its access time starts when the request is accepted. Then, the user has 24 hours to start their session. When the user starts the session, the system counts the session time, which the user had requested, and terminates connection when the requested session time is over. If the user does not use the access and does not connect for 24 hours after access is granted, the access becomes expired.

For the scheduled type of requests, the user chooses a start date and an end date, which means access will be granted for a whole day from the start date till the end date.

The Awaiting tab shows a detailed list of the requests that are waiting for the decision of the currently logged in user.

In order to vote, select the RESPONSE button. Next, a modal will pop up where an admin can accept or reject the request. The Response reason field is required to activate the rejecting option.

Note

If a user is trying to connect to a server (for example, based on the SSH protocol) via the native client option, but hasn’t sent an access request, a respective message about authentication error is recorded into the Event logs: Unable to authenticate user: safe requires acceptance.

Active requests

The Active tab shows a list of two types of the requests: 1) the requests that were accepted, and their sessions are currently ongoing, and 2) the requests that are waiting for the part of the voters. The Votes column of the requests list shows a number of voters that the particular request needs to be processed. Hover on its value to see the details of who had voted.

Accepted votes can be revoked here. This option is useful when the user ended his work earlier than was expected. In order to prevent any possible misuse, any Granted User or an admin is able to revoke access with the proper reason.

Archived requests

History of the processed requests is available under the Archive tab.

The Votes column of the requests list shows a number of voters that the particular request needed to be processed. Hover on its value to see the details of who voted.

The Just in Time feature also works when there are Fudo instances connected in the cluster. Votes and requests are replicated on nodes in the cluster.

Note

If the admin voted on more than one machine in the cluster and his decisions were contradictory, it will be treated as a single rejecting vote and the accepting vote will be revoked.

Related topics:

• Creating a new safe