Auth token renewal clarification
652 views
Skip to first unread message
Jameel Al-Aziz
Jan 28, 2016, 4:55:20 AM1/28/16
to Vault
I've been playing around with auth token renewal and looking at the source and have run into a few interesting scenarios that don't seem to be mentioned in the docs (or incorrect in the docs).
I didn't want to create an issue on Github as I'm not sure if these are by design or not.
1) "lookup-self" returns a different TTL than "renew-self" if the increment is different than the original TTL. It seems that the new TTL is not stored in the token store and is only used to update the expiration.
2) Since the "GracePeriod" is only set at token create time, renewing will cause expiraion after Increment + original Grace Period seconds. For example, if a token is created with a TTL of 1h (3600s) and immediately renewed with a TTL of 1m (60s), the token will expire after 420 seconds.
3) Tokens are no longer non-renewable by default. In fact, it seems that you can no longer create non-renewable tokens. Seems related to this change: https://github.com/hashicorp/vault/commit/d62f533a6f84ad05071070b07ee07ac999ed1203
#3 seems to contradict the comment (https://github.com/hashicorp/vault/blob/master/vault/token_store.go#L709) and parts of the documenttation.
Jeff Mitchell
Jan 28, 2016, 9:54:47 AM1/28/16
to vault...@googlegroups.com
Hi Jameel,
On Thu, Jan 28, 2016 at 4:55 AM, Jameel Al-Aziz <m...@jalaziz.io> wrote:
> 1) "lookup-self" returns a different TTL than "renew-self" if the increment
> is different than the original TTL. It seems that the new TTL is not stored
> in the token store and is only used to update the expiration.
That's correct. The TTL output is the one stored at token creation
time, which is what was set when the token was created. As of a month
ago we now look up the lease times in the expiration manager in order
to set last_renewal_time, so it's possible we could change the meaning
of TTL, but that would be a breaking API change. Instead, maybe we can
simply add another field -- so there is TTL which is static, and there
is expiration which is the actual time that the lease will expire,
taking into account any renewals. Feel free to file an issue about
this.
> 2) Since the "GracePeriod" is only set at token create time, renewing will
> cause expiraion after Increment + original Grace Period seconds. For
> example, if a token is created with a TTL of 1h (3600s) and immediately
> renewed with a TTL of 1m (60s), the token will expire after 420 seconds.
Honestly, I'm not a fan of the grace period because it leads to
confusion like this, and I plan to rip it out as soon as I can, except
that that won't be until we can make a breaking API change :-/
> 3) Tokens are no longer non-renewable by default. In fact, it seems that you
> can no longer create non-renewable tokens. Seems related to this change:
> https://github.com/hashicorp/vault/commit/d62f533a6f84ad05071070b07ee07ac999ed1203
That's a good catch, although the root of this has been going on a bit
before that particular commit. Here's an in-depth explanation:
The original blunt-force approach of a hard-coded 30 day maximum token
time was very hard for a lot of organizations to deal with, so in 0.3
we introduced both system-wide default/max TTL and specific mount
tuning with two initial options -- default lease TTL and max lease
TTL. The default is up to the individual backends to honor...and many
don't, but we're doing planning for v2 of the backend framework which
will generally take these kinds of decisions away from individual
backends so that they have much more consistent UX. The max lease TTL
is *always* enforced, because enforcement happens in the core.
This makes for a much more flexible approach, because you can have
multiple mounts of each backend, so you can enforce different maximums
regardless of how the backend itself behaves (and eventually,
defaults), plus you can selectively override the system default/max.
Renewability was always keyed to whether the TTL was greater than
zero; it's just that now there is always a default of one type or
another, either at the system side or the mount side, so you basically
never have a TTL of zero. This leads to the situation you found.
This isn't really a *problem* -- at least not in any security sense --
since you could never go past your maximum lease TTL even with
renewing. So having a non-renewable token of TTL X is essentially the
same as having a renewable token with a maximum TTL of X.
The longer term fix for this is that as we work on enhancing the
backend framework we're going to be expanding the options exposed by
mount-tune. For instance, one idea is to strip MFA support out of a
specific backend itself and instead bring that into core (e.g.
configured via /sys) so that you can then use a mount tuning option to
determine which defined MFAs are available/should be used by any given
mount -- suddenly *any* mount can use MFA, not just ones that are
specifically coded to be compatible with it. Along with this expansion
in mount tuning options I've been planning to add renewability as a
toggleable option, so rather than keyed to TTL > 0, it's just a
boolean that is set on that mount, or not.
We're still figuring out the details of how much overriding a
particular role within a backend should have over these set options.
But allowing overrides can lead right back to the current situation of
a lot of copy and pasted code between backends that never quite works
the same, and that's what we want to get rid of in the first place, so
we may just have these options live as mount tunables, and for
different needs a different copy of the backend can be mounted.
Let me know if that all makes sense to you...
--Jeff
On Thu, Jan 28, 2016 at 4:55 AM, Jameel Al-Aziz <m...@jalaziz.io> wrote:
> 1) "lookup-self" returns a different TTL than "renew-self" if the increment
> is different than the original TTL. It seems that the new TTL is not stored
> in the token store and is only used to update the expiration.
time, which is what was set when the token was created. As of a month
ago we now look up the lease times in the expiration manager in order
to set last_renewal_time, so it's possible we could change the meaning
of TTL, but that would be a breaking API change. Instead, maybe we can
simply add another field -- so there is TTL which is static, and there
is expiration which is the actual time that the lease will expire,
taking into account any renewals. Feel free to file an issue about
this.
> 2) Since the "GracePeriod" is only set at token create time, renewing will
> cause expiraion after Increment + original Grace Period seconds. For
> example, if a token is created with a TTL of 1h (3600s) and immediately
> renewed with a TTL of 1m (60s), the token will expire after 420 seconds.
confusion like this, and I plan to rip it out as soon as I can, except
that that won't be until we can make a breaking API change :-/
> 3) Tokens are no longer non-renewable by default. In fact, it seems that you
> can no longer create non-renewable tokens. Seems related to this change:
> https://github.com/hashicorp/vault/commit/d62f533a6f84ad05071070b07ee07ac999ed1203
before that particular commit. Here's an in-depth explanation:
The original blunt-force approach of a hard-coded 30 day maximum token
time was very hard for a lot of organizations to deal with, so in 0.3
we introduced both system-wide default/max TTL and specific mount
tuning with two initial options -- default lease TTL and max lease
TTL. The default is up to the individual backends to honor...and many
don't, but we're doing planning for v2 of the backend framework which
will generally take these kinds of decisions away from individual
backends so that they have much more consistent UX. The max lease TTL
is *always* enforced, because enforcement happens in the core.
This makes for a much more flexible approach, because you can have
multiple mounts of each backend, so you can enforce different maximums
regardless of how the backend itself behaves (and eventually,
defaults), plus you can selectively override the system default/max.
Renewability was always keyed to whether the TTL was greater than
zero; it's just that now there is always a default of one type or
another, either at the system side or the mount side, so you basically
never have a TTL of zero. This leads to the situation you found.
This isn't really a *problem* -- at least not in any security sense --
since you could never go past your maximum lease TTL even with
renewing. So having a non-renewable token of TTL X is essentially the
same as having a renewable token with a maximum TTL of X.
The longer term fix for this is that as we work on enhancing the
backend framework we're going to be expanding the options exposed by
mount-tune. For instance, one idea is to strip MFA support out of a
specific backend itself and instead bring that into core (e.g.
configured via /sys) so that you can then use a mount tuning option to
determine which defined MFAs are available/should be used by any given
mount -- suddenly *any* mount can use MFA, not just ones that are
specifically coded to be compatible with it. Along with this expansion
in mount tuning options I've been planning to add renewability as a
toggleable option, so rather than keyed to TTL > 0, it's just a
boolean that is set on that mount, or not.
We're still figuring out the details of how much overriding a
particular role within a backend should have over these set options.
But allowing overrides can lead right back to the current situation of
a lot of copy and pasted code between backends that never quite works
the same, and that's what we want to get rid of in the first place, so
we may just have these options live as mount tunables, and for
different needs a different copy of the backend can be mounted.
Let me know if that all makes sense to you...
--Jeff
Jameel Al-Aziz
Jan 29, 2016, 1:55:24 AM1/29/16
to vault...@googlegroups.com
Wow. Thanks for the detailed explanation.
One thing though, you said:
> This isn't really a *problem* -- at least not in any security sense --
> since you could never go past your maximum lease TTL even with
> renewing. So having a non-renewable token of TTL X is essentially the
> same as having a renewable token with a maximum TTL of X.
> since you could never go past your maximum lease TTL even with
> renewing. So having a non-renewable token of TTL X is essentially the
> same as having a renewable token with a maximum TTL of X.
Is that actually the case? It seems that auth tokens can be renewed forever since "0" is passed for maxSessionTime to framework.LeaseExtend. Wouldn't that result in a session being renewable forever?
Unless you're talking about not being able to increment larger than the original TTL? However that still allows you to renew forever.
In any case, I agree it's not really a problem (since you can always revoke).
--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.
GitHub Issues: https://github.com/hashicorp/vault/issues
IRC: #vault-tool on Freenode
---
You received this message because you are subscribed to a topic in the Google Groups "Vault" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vault-tool/aJ1XaOElZa0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vault-tool+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/CAORe8GFCaWOTim%2Byyqe0wQYWe7sOBbTgK755jy3i%3DLmJr%3D2c2w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Jeff Mitchell
Jan 29, 2016, 9:14:11 AM1/29/16
to vault...@googlegroups.com
On Fri, Jan 29, 2016 at 1:55 AM, Jameel Al-Aziz <m...@jalaziz.net> wrote:
> Wow. Thanks for the detailed explanation.
>
> One thing though, you said:
>
>> This isn't really a *problem* -- at least not in any security sense --
>> since you could never go past your maximum lease TTL even with
>> renewing. So having a non-renewable token of TTL X is essentially the
>> same as having a renewable token with a maximum TTL of X.
>
> Is that actually the case? It seems that auth tokens can be renewed forever
> since "0" is passed for maxSessionTime to framework.LeaseExtend. Wouldn't
> that result in a session being renewable forever?
I assume you're talking about the TokenStore call to LeaseExtend --
> Wow. Thanks for the detailed explanation.
>
> One thing though, you said:
>
>> This isn't really a *problem* -- at least not in any security sense --
>> since you could never go past your maximum lease TTL even with
>> renewing. So having a non-renewable token of TTL X is essentially the
>> same as having a renewable token with a maximum TTL of X.
>
> Is that actually the case? It seems that auth tokens can be renewed forever
> since "0" is passed for maxSessionTime to framework.LeaseExtend. Wouldn't
> that result in a session being renewable forever?
the maxFromLease bool value is set to true, which means that the lease
itself will be used to look up the max value.
--Jeff
Jameel Al-Aziz
Jan 29, 2016, 11:39:39 PM1/29/16
to Vault
Yup, I was talking about the TokenStore call to LeaseExtend. If I'm not mistaken, the maxFromLease bool is used to upper bound the increment, not the total lifetime of the token.
However, I don't actually need non-renewable tokens (nor do I foresee ever needing them). Just wanted to get clarification on the subject and point out the the documentation seems to suggest you can get non-renewable tokens when it seems like that's no longer the case.
Reply all
Reply to author
Forward
0 new messages