search

gravitational / teleport

The easiest, and most secure way to access and protect all of your infrastructure.
https://goteleport.com
GNU Affero General Public License v3.0
17.37k stars 1.74k forks source link

Improve access request creation UX #46001

Open r0mant opened 3 weeks ago

r0mant commented 3 weeks ago

The access request creation dialog needs to accommodate two major enhancements:

1. Enable long-term access requests

Problem: Request creation only allows for short-term access requests, and requesting users don't know long-term access is an option

The interface does not make it clear to users that they can request long-term access via access lists (if a suitable access list is available) and they get confused. We retro-fitted long-term requests into existing system by giving reviewers ability to "promote" a request to an access list but didn't give ability to requesters to request long-term access.

2. Improve UX of requests with future start date

Problem: Future request start time behavior is confusing

The interaction between "start date", "access duration" and "request TTL" remains very confusing mostly due to the fact that the single "max_duration" role configuration option controls the entire request lifetime and there's no way to schedule the request at arbitrary point in the future while limiting its effective duration ("I want the request to be valid for 8 hours starting 8AM next Friday") because the request will remain valid and assumable until its "max_duration" expires (which has to be long to be able to set future start dates).

Screenshot 2024-08-28 at 3 44 55 PM
roraback commented 1 week ago

Use cases to consider:

Also keep in mind standard Enterprise users only get 1 access list and 5 resource access requests/month

r0mant commented 1 week ago

Similar feedback from a customer who can't use existing future start time due to its limitations. @roraback @samratambadekar

We have a requirement where our engineers need elevated access outside of working hours for maintenance tasks. For this, we were going through the start date option in the access request UI, but it seems that this doesn't entirely meet our requirements.

This is because the current logic of assume-start-time is bound to the max_duration time logic.

  1. Future start time options depend on the max_duration time defined for the role. For example, if the max_duration time is defined as 8 hours then you can only pick start times until 8 hours from the time the access request is submitted.
  2. Also we noticed that with the current behavior, the later the time slot you pick the lesser the access duration you will get. Maximum access duration can be achieved only if the first start time option is selected.

Our requirement is to be able to submit an access request that will come into effect at a future time with an access duration that the user selected. For example, an engineer should be able to submit an access request at 5.00 p.m. on a Friday for his access to be effective on Sunday at 8.00 a.m. and last for 8 hours.

programmerq commented 6 days ago

Follow-up from that same customer with regard to the default values in the Web UI:

is it possible to configure a default value for the access duration options? Let's say we configure the max_duration for 2 days, and it will provide options ranging from 1 hour to 2 days. In the access duration drop-down menu, the default option will be 2 days. Is there a way to change the default option in this drop-down menu to a different option, for example, 8 hours