Using new token role feature via API

[dwa...@1043labs.com]

Folks,

I've done some testing with the new token role feature introduced in 0.5.2. This feature gives us the periodic token lease with no expiration we've been looking for. However, I'm a bit unclear on the best practices use of token roles, particularly through the API. It took us many iterations to figure out how to revoke a token created using token roles. Just as a general comment, it would be *very* helpful to include examples in the API documentation!

A number of questions came up in our testing:

1. Creating a token role

The documentation states "Role parameters, when set, override any provided options to the create endpoints." I first set only the "period" parameter, then attempted to create a token using the root role. This failed with the error "Token policies must be a subset of the role's allowed policies". Given that the root role was used, that was an unexpected error. I found that I had to also add the token's desired policies to the role parameter "allowed_policies" to avoid this error. Is that the expected behavior?

2. Revoking a token created using token role

Let's assume the token role is named "devrole" and the token is "devtoken". Revoking such a token by the usual means (POST /auth/token/revoke/devtoken) did not work. I then tried using the revoke-prefix method like this: POST /auth/token/revoke-prefix/devrole. That too failed. What did work was this: POST /auth/token/revoke-prefix/auth/token/create/devrole. Is this the only way to revoke such a token?

3. Unexpected expiration message

Let's say the above token was created, renewed several times, and then revoked. The following message shows up in the log file TTL seconds after the last renewal:

  [INFO] expire: revoked 'auth/token/renew-self/devtoken

What do I need to do to eliminate that message? Do I also need to revoke the renew-self endpoint? We would like to set up alarms on expiration messages in the log, and that one would be considered a false alarm.

Thanks for any comments,

Dave Walter

[Jeff Mitchell]

Hi Dave,

> 1. Creating a token role
> The documentation states "Role parameters, when set, override any provided
> options to the create endpoints." I first set only the "period" parameter,
> then attempted to create a token using the root role. This failed with the
> error "Token policies must be a subset of the role's allowed policies".
> Given that the root role was used, that was an unexpected error. I found
> that I had to also add the token's desired policies to the role parameter
> "allowed_policies" to avoid this error. Is that the expected behavior?

Yes. As the documentation notes, the parameters override any provided
options. This includes the policies of the calling token, regardless
of whether it is root. Generally speaking, root only allows bypassing
the path-based ACLs, but has no bearing on parameters given to paths.

> 2. Revoking a token created using token role
> Let's assume the token role is named "devrole" and the token is "devtoken".
> Revoking such a token by the usual means (POST /auth/token/revoke/devtoken)
> did not work. I then tried using the revoke-prefix method like this: POST
> /auth/token/revoke-prefix/devrole. That too failed. What did work was this:
> POST /auth/token/revoke-prefix/auth/token/create/devrole. Is this the only
> way to revoke such a token?

I can't really answer this without more information, especially, what
error messages you were seeing and the role parameters you used. I
can't reproduce this though:

$ vault write auth/token/roles/testrole period=3600
allowed_policies="foo,bar" orphan=true
Success! Data written to: auth/token/roles/testrole

$ vault write -f auth/token/create/testrole
token
09281a31-ca0f-ad1d-ed6d-7a9d39127bc0
...

$ vault token-lookup 09281a31-ca0f-ad1d-ed6d-7a9d39127bc0
accessor c220c740-a325-c38c-0d65-6d5162869b83
...

$ vault write -f auth/token/revoke/09281a31-ca0f-ad1d-ed6d-7a9d39127bc0
Success! Data written to: auth/token/revoke/09281a31-ca0f-ad1d-ed6d-7a9d39127bc0

$ vault token-lookup 09281a31-ca0f-ad1d-ed6d-7a9d39127bc0
error looking up token: Error making API request.
...
* bad token

> 3. Unexpected expiration message
> Let's say the above token was created, renewed several times, and then
> revoked. The following message shows up in the log file TTL seconds after
> the last renewal:
> [INFO] expire: revoked 'auth/token/renew-self/devtoken
> What do I need to do to eliminate that message?

You don't. When you revoke a token directly the expiration timer still
exists, and it's currently actually difficult to have the token
revocation action stop the expiration timer since within the Vault
core the data is purposefully kept separate from each other. So when
the expiration timer fires it logs this message, although the token
has already been revoked.

Best,
Jeff

[Dave Walter]

Jeff,

Thanks for the quick reply. 

I don't completely understand your response to the first issue.

>>> Yes. As the documentation notes, the parameters override any provided

options.

Actually, the doc states that "WHEN SET, parameters override any provided options", but I did not set the allowed_policies. In that case, I expected the create action to function just as it does without using token role. Our code currently does a token create from the root role using a policy that root doesn't explicitly have listed, and does not get the error "Token policies must be a subset of the role's allowed policies". So I'm trying to understand why the behavior is different.

The second issue regarding the revoke endpoint is my bad. I assumed that the expiration message in the log meant that the token had not been revoked, but doing a lookup proved that it was revoked. 

I didn't expect expiration messages to appear in the log after a token had been intentionally revoked. I would like to be able to set some kind of alarm that is triggered *only* when a token expires (as opposed to being explicitly revoked). Do you have a recommended way to do that?

Thanks again,

Dave 

--
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/WW4czi0TuU0/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/CAORe8GEf3k-uYxFK98EPPTe7_Pioann6ZVEv5O3UUuUat2bp%2Bg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Jeff Mitchell]

On Thu, Mar 31, 2016 at 12:40 PM, Dave Walter <dwa...@1043labs.com> wrote:
> Jeff,

> Actually, the doc states that "WHEN SET, parameters override any provided
> options", but I did not set the allowed_policies.

In this case, the role then uses the default of the empty set, e.g. no
policies allowed, so the real effect of this is to disk out tokens
with only the "default" policy attached. However, since you could also
do that by just making "default" the only policy allowed, I'm open to
changing this so that if allowed_policies is empty it uses normal
token behavior. A commit will go in soon.

> In that case, I expected
> the create action to function just as it does without using token role. Our
> code currently does a token create from the root role using a policy that
> root doesn't explicitly have listed, and does not get the error "Token
> policies must be a subset of the role's allowed policies". So I'm trying to
> understand why the behavior is different.

I couldn't comment without more information. I don't know what "root
role" means (do the tokens have the root policy? Is the root policy in
allowed_policies? Is it just a name?), but if you want to provide
details I can take a look.

> I didn't expect expiration messages to appear in the log after a token had
> been intentionally revoked. I would like to be able to set some kind of
> alarm that is triggered *only* when a token expires (as opposed to being
> explicitly revoked). Do you have a recommended way to do that?

I don't currently. I can see about trying to change this behavior for 0.6.

Best,
Jeff

[Jeff Mitchell]

On Thu, Mar 31, 2016 at 1:36 PM, Jeff Mitchell <je...@hashicorp.com> wrote:
>> I didn't expect expiration messages to appear in the log after a token had
>> been intentionally revoked. I would like to be able to set some kind of
>> alarm that is triggered *only* when a token expires (as opposed to being
>> explicitly revoked). Do you have a recommended way to do that?
>
> I don't currently. I can see about trying to change this behavior for 0.6.

FYI, I have changed this in master.

--Jeff