Open programmerq opened 1 year ago
See also #7560 and #11504.
We don't see much value in making the reason required, because the reviewer still has to determine if the reason is valid.
Entering a reason of .
is basically equivalent to not specifying a reason, so this requirement can be trivially bypassed.
+1 to the request for audit purposes. User plans to follow up manually and review the reasons were valid and take corrective action from there
+1 for making this option available.
I'm unclear on why teleport would care what the "valid reason" is? Since it's being reviewed by a person for approval, that would be on us to determine if it's a real reason or a .
? Having the ability to require a reason would be one step in ensuring there's an initial valid reason upon the request being submitted vs a blank entry.
Having the ability to require the reason is a good thing - certainly people can just put in a "." , but then you can go train and weed out the bad actors that are not following the procedure.
+1 as sometimes users just forget to put a reason, putting a "." is different as the user just doesn't want to follow the procedure
Making the reason mandatory field can force the user to think about it at least ... there are cases where users don't write anything just because they forget.
It may be up to the approver to decide, but the reason field is also useful when you look back all requests and try to understand why they were needed.
+1 on allowed us to make it required. We also require a reason for auto approval based on if you're on call in pagerduty, so if you forget to enter a reason in the heat of an incident, auto approval doesn't go through.
The ability to set a regex for validation of the reason would also work around the .
issue. Nothing is going to be perfect, but requiring a reason that matches a pattern would be vastly preferable to the status quo.
Making the reason field mandatory on Access Requests would be useful, I agree with many of the points above.
What would you like Teleport to do?
Add the ability to set a policy to make a reason required for an access request to be submitted.
What problem does this solve?
Improves user experience for environments with audit/compliance policies that require a reason. Currently, an explicit denial process is required to ensure this requirement. Adding the ability to mark a reason as required would allow both tsh and the web UI to prompt for a reason without the end user needing to remember that it's required.
This is separate from the forced access request feature that can prompt for a reason. This is meant for a team that only occasionally needs access to privileged resources, and they don't need to do access requests for their day-to-day work.
If a workaround exists, please include it.