Is it possible to create a token with no expiration and read only?

[Andy Lee]

Hi,

I'm having some trouble figuring out how I can create a token like the root token that has no expiration but tied to a read only policy. Is it even possible?

At first I tried creating an app_id user_id token but that doesn't seem to have any parameters to change the token duration.

# cat my-policy

path "secret/myapp/*" {

  policy = "read"

}

vault write auth/app-id/login app_id=foo user_id=admin

Key               Value

token             87456fbe-33c9-0df0-2995-7c22af37bec5

token_duration     2592000

token_renewable   false

token_policies     [my-policy]

token_meta_app-id "sha1:a2468f28b1edfae3e0a0ca3842941d5601441434"

token_meta_user-id "sha1:d033e22ae348aeb5660fc2140aec35850c4da997"

Also, can somebody give me an example of how I can authenticate using the app_id and user_id instead of the token?

Thanks,

Andy

[Andy Lee]

Also, if it's not possible to extend the duration, is it possible to at least make the token renewable?

[Andy Lee]

Never mind, answered my second question here

On Monday, July 27, 2015 at 3:28:19 PM UTC-7, Andy Lee wrote:

[Clay Bowen]

The user that you use to create the token (the account used to login) will have a policy on what access that user has to the secrets.  You can make their access read-only for a set of secrets.  When you login using any method (app-id, cert, username, etc.), a token is generated which will allow access to the secrets for a time specified.

I use the cert backend vs. app-id, but you can find examples in my posts on logging in and using the tokens on this board.

Thanks,

Clay

[Armon Dadgar]

Hey Andy,

All tokens are subject to a maximum validity duration in Vault, with the exception of root tokens.

Even those can and should have limited validity but they can be created in a way that does not

expire. For all other types of tokens, Vault will enforce a lease duration.

This means you cannot create a read-only token with a permanent life span. At most

you can create one with a 30 day duration. If you use an AppID auth type, you can certainly

have the application login periodically to get a new read-only token, which is the best way

to approach this.

Best Regards,

Armon Dadgar

--
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/4ebc38ae-9a02-474b-826d-74d55480f518%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Andy Lee]

Okay cool, but which types of tokens can be renewed? 

On Tuesday, July 28, 2015 at 12:58:51 PM UTC-7, Armon Dadgar wrote:

Hey Andy,

All tokens are subject to a maximum validity duration in Vault, with the exception of root tokens.

Even those can and should have limited validity but they can be created in a way that does not

expire. For all other types of tokens, Vault will enforce a lease duration.

This means you cannot create a read-only token with a permanent life span. At most

you can create one with a 30 day duration. If you use an AppID auth type, you can certainly

have the application login periodically to get a new read-only token, which is the best way

to approach this.

Best Regards,

Armon Dadgar

[Armon Dadgar]

Andy,

It depends on the authentication mechanism that is used if they support renewal or not.

For example, LDAP will re-check the credentials to ensure they are still valid and supports

renewal.

Best Regards,

Armon Dadgar

[Andy Lee]

I would actually like to amend my original question. What is the exact incantation to create app_id tokens with a 1 hour duration?

I tried these methods but neither didn't seemed to take.

vault write auth/app-id/map/app-id/foo value=my-policy token_duration=3600

vault write auth/app-id/map/user-id/bar value=foo token_duration=3600

On Wednesday, July 29, 2015 at 1:03:53 PM UTC-7, Armon Dadgar wrote:

Andy,

It depends on the authentication mechanism that is used if they support renewal or not.

For example, LDAP will re-check the credentials to ensure they are still valid and supports

renewal.

Best Regards,

Armon Dadgar

[Jeff Mitchell]

Hi Andy,

Different backends support different options. App-ID does not support a duration parameter. You can see the docs for the backend here: https://vaultproject.io/docs/auth/app-id.html

--Jeff

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/036bf7fe-6566-4cc4-90e9-371004183139%40googlegroups.com.

[Andy Lee]

Is there any particular reason why? If you have your config management system constantly posting login with the app_id user_id, wouldn't you create a lot bunch of unused tokens?

[Jeff Mitchell]

I'm not sure why the app-id backend doesn't support a duration parameter, but a PR to add that would probably be welcomed.

However, you shouldn't be ending up with a lot of extra tokens -- the app-id backend is designed to identify particular machines, which you would probably set onto your machines via your configuration management solution. It's relatively static. For short-lived needs with expiration or a limited number of uses, the token backend works well.

--Jeff

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/9f82e790-51b9-43c2-98f4-3edbf6a2e30d%40googlegroups.com.

[Andy Lee]

I know that everytime the machine posts their app_id and user_id to the login endpoint, a new token gets created That's my concern as puppet or whatever config management system runs in at least 30 minute intervals.

[Jeff Mitchell]

Those tokens will expire, though, so nothing will become cluttered. That's the point! :-)

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/dd0831d2-020c-4acf-b72e-98abea2e2da5%40googlegroups.com.

[Andy Lee]

Yeah but in 30 days! You can create a whole lot of tokens in 30 days worth of 30 minute puppet runs on hundreds of hosts. :(

[Michael Fischer]

I agree with Andy here; it'd be useful to declare a shorter lease for clients that acquire tokens or read values frequently but don't use them for long.

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/036f4220-a115-4c77-81c3-cfa601188ebe%40googlegroups.com.

[Jeff Mitchell]

Hi Andy,

I see what you are asking; I thought you wanted entries in the appid/userid table to have an expiration, but you are concerned with the tokens that those entries generate.

Controlling this is something that could be added, but there may already be a feature that will meet your needs. In 0.3 there will be the ability to manually set max and default lease TTLs (the code is already in master, if you want to build from there), so you could set the default to something short. At some point, probably after 0.3, we plan to add controllable max and default lease TTLs as per-backend parameters.

--Jeff

To view this discussion on the web visit https://groups.google.com/d/msgid/vault-tool/036f4220-a115-4c77-81c3-cfa601188ebe%40googlegroups.com.