Token leases, how do they work exactly?

[Alex Urcioli]

Just doing some experimentation to figure out how all this works..

I've created a token from the CLI and mapped it to a policy. This token will be used to access a "master seed" value for some totp codes. Documentation specifically states that: "Every token has a lease associated with it. After the lease period is up, the token will no longer function. In addition to no longer functioning, Vault will revoke it."  (https://www.vaultproject.io/docs/concepts/tokens.html) 

However, when I query the API /auth/token/lookup/<created_token>  (using my root token as x-vault-token header), I get the following response:

How come I can not renew this token, and how come it has no lease_id? Does this token never expire? Will it expire after 30 days? If this token expires and I am no longer able to access the "master seed" then the entire database of codes becomes unusable. My use case might be too brittle for vault but like I said im just experimenting. Any insight would be appreciated.

{

  "lease_id": "",

  "renewable": false,

  "lease_duration": 0,

  "data": {

    "creation_time": 1445458895,

    "display_name": "token",

    "id": "dd3b637a-90bd-5a5e-650f-fb93bae406a2",

    "meta": null,

    "num_uses": 0,

    "path": "auth/token/create",

    "policies": [

      "totp-server"

    ],

    "ttl": 2592000

  },

  "auth": null

}

[Jeff Mitchell]

Hi Alex,

On Thu, Oct 22, 2015 at 10:31 AM, Alex Urcioli <ale...@gmail.com> wrote:
> I've created a token from the CLI and mapped it to a policy. This token will
> be used to access a "master seed" value for some totp codes. Documentation
> specifically states that: "Every token has a lease associated with it. After
> the lease period is up, the token will no longer function. In addition to no
> longer functioning, Vault will revoke it."
> (https://www.vaultproject.io/docs/concepts/tokens.html)
> However, when I query the API /auth/token/lookup/<created_token> (using my
> root token as x-vault-token header), I get the following response:
> How come I can not renew this token, and how come it has no lease_id? Does
> this token never expire?

Root tokens are special -- unlike other tokens, they are allowed to
have an infinite lifetime. So this particular token will indeed never
expire, and since only tokens that can expire are renewable, this
token is not renewable. If you attempt to hit the
/v1/auth/token/renew-self endpoint you will see that you get an error,
but any non-root token will have a finite lifetime and be renewable.

How renewability is handled in a general sense varies a little bit
per-backend (something that we hope to make more standardized going
forward). In general, if you give an explicit TTL, the lease will be
renewable; if not, it will not be.

The reason you don't have a lease-id is that leases are associated
with tokens, not the other way around. That part of the documentation
is still a holdover that we've slowly been fixing up from when "lease"
was overloaded to mean both "borrowed metadata/credentials, including
a duration" and simply "a duration". I'll mark that to get fixed.

> Will it expire after 30 days? If this token expires
> and I am no longer able to access the "master seed" then the entire database
> of codes becomes unusable.

The root token will not expire, so can always be used to access the
information, or create more tokens. Generally policies are created to
control access to various parts of the vault, then the various
authentication backends are used to create and distribute access
tokens after successful authentication.

Let us know if you have more questions!
--Jeff

[Alex Urcioli]

Jeff, 

Thankyou for the informative reply. I suppose a more resilient and secure configuration would be to use the App-ID auth backend, which will handle token lifetime for me. Anyway, this is great and Vault is really cool.

Thanks again

Alex

[Jeff Mitchell]

Hi Alex,

FYI, I am in the middle of constructing a very in-depth blog post
around the Cubbyhole authentication model, which is going to be our
recommended approach for authentication for automated uses going
forward. You can get an idea of how it works in the 0.3 blog post
(https://hashicorp.com/blog/vault-0.3.html).

Thanks,
Jeff

> --
> 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 the Google Groups
> "Vault" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to vault-tool+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/vault-tool/f1be3cf8-864e-42ac-8e0d-d4eea855469a%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[Alex Urcioli]

Hi Jeff, 

Since I have your attention, what is the suggested method for securely unsealing a server in an automatic fashion? It seems to me that if you have production services relying on retrieving data from a vault, and the vaults for some reason go down, how do you have these systems come up and automatically unseal without sort of defeating the whole purpose of the vault? Just interested in your philosophy on this.

Thanks

Alex

[Jeff Mitchell]

On Thu, Oct 22, 2015 at 5:08 PM, Alex Urcioli <ale...@gmail.com> wrote:
> Since I have your attention, what is the suggested method for securely
> unsealing a server in an automatic fashion? It seems to me that if you have
> production services relying on retrieving data from a vault, and the vaults
> for some reason go down, how do you have these systems come up and
> automatically unseal without sort of defeating the whole purpose of the
> vault? Just interested in your philosophy on this.

Hi Alex,

Vault is really designed *not* to be unsealed in an automated fashion;
that's a large part of why a lot of people in security disciplines
really like it, because it means someone can't make a copy of the
physical storage and unseal it on their own so long as they only have
one unseal key. If they have access to automated services that contain
unseal keys, they could unseal a local copy and read all the secrets
inside. The founders of HashiCorp together can't unseal their own
vault. Vault is a zero-trust model, so we consider that a good thing.

I've heard of people storing unseal keys in AWS' KMS, but if you want
to do that in some kind of automated fashion you then need to have
some kind of security around those machines, their KMS keys, and so
on. Then you have the same kind of protecting-the-secrets problem you
have with Vault unseal keys, you've only shifted it elsewhere and
opened up a new channel for attacks at the same time.

Most people handle the possibility of a Vault server going down by
using an HA setup and having proper alerts for when health checks
fail. That way you still have Vault servers able to handle requests
until the one that went down can be brought back up again and
unsealed.

Hope this helps!
--Jeff

[Alex Urcioli]

Thanks Jeff, this reply makes a lot of sense. Thanks!