Request for `tsh request drop` to Restore the Original Certificate TTL

programmerq commented 7 months ago

What would you like Teleport to do?

Implement a feature or method to allow Teleport (tsh) to restore the original long-term certificate TTL after dropping a role with a shorter-term TTL certificate.

What problem does this solve?

Currently, after a user assumes a role with a TTL shorter than the original certificate, running tsh request drop does not restore the original certificate TTL. It seems to generate a new cert that omits the request, but leaves the user with the shorter TTL from the earlier operation.

This behavior is problematic when users need to switch between multiple roles with varying TTLs. It effectively forces the user to have a lower TTL, hindering their workflow after dropping the short-lived role.

For example, a user logs in with a 12-hour TTL certificate, then assumes a role with a 55-minute TTL. After dropping the role, the user expects to revert to the original 12-hour TTL but is left with the remaining time from the assumed role's certificate, which can be seen in the provided tsh status output before and after running tsh request drop.

An example feature such as tsh request drop --refresh-certs could provide the desired certificate restoration behavior.

If a workaround exists, please include it.

The current workaround is to manually request a new certificate after dropping the short-lived role. However, this is inconvenient and poses an interruption to the user's workflow. Implementing just-in-time resource requests was mentioned, but it does not apply as it restricts access to the base roles' resources when a new resource access is granted.

The logs detailing the behavior are as follows:

$> tsh login ...
...
Valid until: 2024-03-21 06:44:58 +0100 CET [valid for 12h0m0s]

$> tsh login --request-id 4ce48042-9a49-488a-95ea-34d0afcaec29
...
Valid until: 2024-03-20 19:38:18 +0100 CET [valid for 55m0s]

$> tsh request drop
Dropping all active access requests...

$> tsh status
...
Valid until: 2024-03-20 19:38:18 +0100 CET [valid for 55m0s]

Similarly, Just-in-Time access requests have the same problem:

% tsh login ...
  Valid until:        2024-03-26 04:29:51 -0400 EDT [valid for 11h57m0s]

% tsh ssh --request-reason please ubuntu@myhost
...
Approval received, getting updated certificates...
ubuntu@myhost:~$
logout

% tsh status
  Valid until:        2024-03-25 17:34:42 -0400 EDT [valid for 54m0s]

This could potentially be addressed by retaining the original cert in a different place in the user's ~/.tsh directory. That way, the tsh request drop would just need to move the file back instead of request a new cert.

zmb3 commented 7 months ago

gravitational / teleport