Pass through custom ttl

[optiz0r]

Hi,

I've looked through the code for this plugin to see if I could see a way to limit the TTL of the kerberos login session token, but don't think it's currently possible. The use-case for a custom TTL is that I'm going to run a short-lived script on a regular basis, and I know I only need the login token to be valid for a minute, but I don't think there's a way to request this? By default the kerberos token is valid for 32d, so will consume vault/consul resources for far longer than is necessary.

I know I can manually revoke my session token when the script is done, but I think it would still be useful to create a deliberately short-lived ticket so as to not leave any unnecessary tokens in vault in case the script crashes or is killed.

Also, I note that the session token returned is valid for the system max ttl. Should this be constrained to be valid for no longer than the kerberos ticket is valid for (either the current ticket expiry time, or if possible to determine, the maximum TGT renewable lifetime)? Is there enough information in the presented service ticket to determine this?

Thanks,
Ben

[tyrannosaurus-becks]

Hi! Thank you for opening this issue. It made me realize that in the docs I PR'd (which haven't gone live yet), I didn't document the TTL-related fields. I'll fix that right away.

Meanwhile, we do have TTL-related fields that can be configured at the LDAP config endpoint. The token fields added here include token_ttl and token_max_ttl. These are later applied here to the token issued at login.

Is this sufficient for your use case? Or are you looking for us to add a role-level or login-level TTL field as well? I'm marking this as a feature request now that I've investigated it more thoroughly.

[optiz0r]

Hi @tyrannosaurus-becks,

It would be nice to be able to request a custom low TTL at login time, because it will be the most flexible with the minimum admin overhead in terms of setting up specific roles.
In the meantime, I've reconfigured my app to revoke its kerberos login token when the script terminates, so it would only help protect against abnormal exit. As such, fairly low priority.

Thanks
Ben