Allow an Administrator to choose different client_idle_timeout values instead of applying only the most restrictive setting.
This request should be feasible without breaking backwards compatibility. The request is not asking to break existing users that depend on the current behavior.
What problem does this solve?
Currently, the most restrictive client_idle_timeout value is enforced when a user has multiple roles with differing timeout settings. This behavior is problematic for scenarios where different servers necessitate different timeout policies based on the role used to access them. For instance:
Users need to access some servers without any timeout.
Other servers require a 15-minute timeout for security compliance.
If a workaround exists, please include it.
A potential workaround is to use access requests, requiring users to request and assume a role for sessions needing a different timeout policy.
Another alternate workflow would be to use trusted clusters. A role on the root cluster could map to a role on a leaf that has the more restrictive policies implemented.
However, both of these add operational overhead, and are not as seamless as having role-specific timeouts directly enforced.
What would you like Teleport to do?
Allow an Administrator to choose different
client_idle_timeout
values instead of applying only the most restrictive setting.This request should be feasible without breaking backwards compatibility. The request is not asking to break existing users that depend on the current behavior.
What problem does this solve?
Currently, the most restrictive
client_idle_timeout
value is enforced when a user has multiple roles with differing timeout settings. This behavior is problematic for scenarios where different servers necessitate different timeout policies based on the role used to access them. For instance:If a workaround exists, please include it.
A potential workaround is to use access requests, requiring users to request and assume a role for sessions needing a different timeout policy.
Another alternate workflow would be to use trusted clusters. A role on the root cluster could map to a role on a leaf that has the more restrictive policies implemented.
However, both of these add operational overhead, and are not as seamless as having role-specific timeouts directly enforced.