vault tokens - token_ttl and max_ttl

3,194 views
Skip to first unread message

iv

unread,
Nov 14, 2019, 2:23:56 AM11/14/19
to Vault
Hi,

I am confused about token ttls and more over what is in:
https://www.terraform.io/docs/providers/vault/r/aws_auth_backend_role.html

token_ttl - (Optional) The incremental lifetime for generated tokens in number of seconds. Its current value will be referenced at renewal time.
token_max_ttl - (Optional) The maximum lifetime for generated tokens in number of seconds. Its current value will be referenced at renewal time.

So if I understand correctly token_ttl is used when we renew the token and the validity of this renewal will be whatever is configured in token_ttl. For token_max_ttl is basically the cap of this token e.g we can NOT extend/renew the token more then whatever is configured in token_max_ttl (if we want to we need to relogin or obtain a new token). Do I understand correctly? 

Right now I have the following setup:
```
vault auth list --detailed
Path      Plugin    Accessor               Default TTL    Max TTL    Token Type         Replication    Seal Wrap    Options    Description                UUID
----      ------    --------               -----------    -------    ----------         -----------    ---------    -------    -----------                ----
aws/      aws       auth_aws_b08bfc9e      259200         system     default-service    replicated     false        map[]      n/a                        55a4d5f3-0d3a-d928-1e46-edb301dcd9ee
token/    token     auth_token_7199488a    system         system     default-service    replicated     false        map[]      token based credentials    42cd0247-b423-6467-9b20-cf376eb73a02
```

```
vault read auth/aws/role/my_role
Key                               Value
---                               -----
allow_instance_migration          false
auth_type                         iam
bound_account_id                  []
bound_ami_id                      []
bound_ec2_instance_id             <nil>
bound_iam_instance_profile_arn    []
bound_iam_principal_arn           [......]
bound_iam_principal_id            [... .....]
bound_iam_role_arn                []
bound_region                      []
bound_subnet_id                   []
bound_vpc_id                      []
disallow_reauthentication         false
inferred_aws_region               n/a
inferred_entity_type              n/a
policies                          [my policies ]
resolve_aws_unique_ids            true
role_id                           5120e8a1-99be-e6fc-16ca-8d93f51bbb44
role_tag                          n/a
token_bound_cidrs                 []
token_explicit_max_ttl            0s
token_max_ttl                     0s
token_no_default_policy           false
token_num_uses                    0
token_period                      0s
token_policies                    [my policies]
token_ttl                         1h30m
token_type                        default
``` 

```
vault token lookup
Key                 Value
---                 -----
accessor            fK...............RG
creation_time       1573715787
creation_ttl        1h30m
display_name        aws-............
entity_id           4c45a17e-b405-0c29-9dad-83c6653073d7
expire_time         2019-11-14T08:46:27.423114114Z
explicit_max_ttl    0s
id                  s.................Q
issue_time          2019-11-14T07:16:27.423113835Z
meta                map[]
num_uses            0
orphan              true
path                auth/aws/login
policies            []
renewable           true
ttl                 1h29m52s
type                service
```

So In this example my token is valid for 1h30m and I can renew it within this period. Since I dont set token_max_ttl or token_explicit_max_ttl thats default which I believe is 30 or 31 days. What is the cap of my token? When I will not be able to renew it? 

My end goal is to have a high number/long live token but if I can't renew it within a range then to expire. Something like have the validity of the token for 60 days, renew it every 24h if renew does not happen in 24h just expire? Can I achieve this is configuring token_ttl = 24h and max_token_ttl = 1440h (60 days)? 

Calvin Leung Huang

unread,
Nov 14, 2019, 3:48:20 PM11/14/19
to Vault
Hello,

I'll answer your questions inline:

For token_max_ttl is basically the cap of this token e.g we can NOT extend/renew the token more then whatever is configured in token_max_ttl (if we want to we need to relogin or obtain a new token). Do I understand correctly? 

That's correct, the token_max_ttl will determine the maximum lifetime of a non-periodic token. If the value is not specified under a particular role/token, then Vault will use either the backend value (if set when being enabled or tuned afterwards) or the default system value of 32 days.
 

So In this example my token is valid for 1h30m and I can renew it within this period. Since I dont set token_max_ttl or token_explicit_max_ttl thats default which I believe is 30 or 31 days. What is the cap of my token?  When I will not be able to renew it?

That's correct, you can renew the token up to the token's max TTL, which in this case is the system/mount value. The `auth list` command that you included indicates that the mount is using the system value. The system value for max TTL (unless otherwise specified in your config file) is 32 days as mentioned here. You won't be able to renew it once the token reaches the max TTL value. 

Sidenote: An exception to this is if the token created is a periodic token (i.e. one that has token_period set to a non-zero value), but it seems that in your case this is a non-periodic token so we don't have to worry about that. You can learn more about periodic tokens here. In that case, token_explicit_max_ttl can be used to cap the lifetime of a periodic token.


My end goal is to have a high number/long live token but if I can't renew it within a range then to expire. Something like have the validity of the token for 60 days, renew it every 24h if renew does not happen in 24h just expire? Can I achieve this is configuring token_ttl = 24h and max_token_ttl = 1440h (60 days)? 

Yes, that's correct. If you set  token_ttl = 24h and token_max_ttl = 1440h, it should give you the desired behavior of renewal up to 60 days, and if renewal does not occur within 24h, then the token expires.


 Hope this helps!


- Calvin

Ivan Varbanov

unread,
Nov 14, 2019, 4:25:08 PM11/14/19
to vault...@googlegroups.com
Calvin, thank you very much for your detailed answer! Appreciate it!

Last night I went through the documentations again and I find out about the period tokens. So I removed the token_ttl and max_token_ttl and used a token_period. I use terraform to create the role:

resource "vault_aws_auth_backend_role" "main" {
  role                     = "${var.name}"
  auth_type                = "${var.auth_type}"
  bound_iam_principal_arns = ["${var.bound_iam_principal_arns}"]
  token_period             = "${var.token_period}"
  token_policies = ["${var.policies}"]
  token_type = "${var.token_type}"

}

vault read auth/aws/role/my_role
Key                               Value
---                               -----
allow_instance_migration          false
auth_type                         iam
bound_account_id                  []
bound_ami_id                      []
bound_ec2_instance_id             <nil>
bound_iam_instance_profile_arn    []
bound_iam_principal_arn           [.................]
bound_iam_principal_id            [.......................]

bound_iam_role_arn                []
bound_region                      []
bound_subnet_id                   []
bound_vpc_id                      []
disallow_reauthentication         false
inferred_aws_region               n/a
inferred_entity_type              n/a
policies                          [...............................]

resolve_aws_unique_ids            true
role_id                           5120e8a1-99be-e6fc-16ca-8d93f51bbb44
role_tag                          n/a
token_bound_cidrs                 []
token_explicit_max_ttl            0s
token_max_ttl                     0s
token_no_default_policy           false
token_num_uses                    0
token_period                      1h30m
token_policies                    [.....................]
token_ttl                         0s

token_type                        default

vault token lookup
Key                 Value
---                 -----
accessor            BWKm9PLHDXamlZRW0kQpbas7
creation_time       1573766049
creation_ttl        1h30m
display_name        .....
entity_id           4c45a17e-b405-0c29-9dad-83c6653073d7
expire_time         2019-11-14T22:44:09.524374338Z
explicit_max_ttl    0s
id                  s.......
issue_time          2019-11-14T21:14:09.524373993Z

meta                map[]
num_uses            0
orphan              true
path                auth/aws/login
policies            [.......]
renewable           true
ttl                 1h26m57s
type                service

In this case I set token_period to 1h30m. So if I understand correctly I should renew the token in that period of time 1h30m. If I dont renew it it will expire. Otherwise I can keep renewing it and it should be valid forever (if of course renewal succeeds). Do I understand correctly? I believe thats what I really need but wanted to confirm if I understand correctly the docs.

Thank you again!

--
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/7da9d979-35fe-462a-bfc2-bb6cd80e252d%40googlegroups.com.

Calvin Leung Huang

unread,
Nov 14, 2019, 6:17:58 PM11/14/19
to Vault
That's right. If you do want to set a maximum TTL lifetime for a periodic token, `token_explicit_max_ttl` would be the way to do it.

- Calvin
To unsubscribe from this group and stop receiving emails from it, send an email to vault...@googlegroups.com.

Calvin Leung Huang

unread,
Nov 18, 2019, 1:27:55 PM11/18/19
to Vault
Hi,

I wanted to give a follow-up in case you see a message similar to `period of 'X' is greater than the backend's maximum lease TTL of 'Y'` when you're creating/updating a role with a period value. If the period value that you are specifying is greater than the mount's max TTL value (e.g. 1440h as in your earlier examples, which would be greater than the default of 32 days), you'll have to perform auth tune in order for it to work. If you are specifying a relatively low value, then you shouldn't be encountering this issue.


- Calvin

Ivan Varbanov

unread,
Nov 18, 2019, 2:07:18 PM11/18/19
to vault...@googlegroups.com
Hello Calvin,

so I reverted the tune on the backend and leave the default values (32d).
```

Path      Plugin    Accessor               Default TTL    Max TTL    Token Type         Replication    Seal Wrap    Options    Description                UUID
----      ------    --------               -----------    -------    ----------         -----------    ---------    -------    -----------                ----
aws/      aws       auth_aws_b08bfc9e      system         system     default-service    replicated     false        map[]      n/a                        55a4d5f3-0d3a-d928-1e46-edb301dcd9ee

token/    token     auth_token_7199488a    system         system     default-service    replicated     false        map[]      token based credentials    42cd0247-b423-6467-9b20-cf376eb73a02
```

Now I create my roles using token_period or like that:
resource "vault_aws_auth_backend_role" "main" {
  role                     = var.name
  auth_type                = var.auth_type
  bound_iam_principal_arns = var.bound_iam_principal_arns
  token_explicit_max_ttl   = var.token_explicit_max_ttl
  token_period             = var.token_period
  token_policies           = var.policies
  token_type               = var.token_type
}

So my understanding is that using the period tokens all I care is to renew it within the token_period (in my case is 1d) and token can be forever active. If everything is fine and renew succeeds the token will be extended and it can be active as long as I renew it. Once I stop renewing it will expire. Here the max_ttl does not take any affect because renew is successful correct? That behavior is exactly what I am looking for. So my applications will renew the token and will take care of this. If renew fails they'll do another vault login.  The `token_explicit_max_ttl` is by default 0 (but I still want to have ability at certain point to cap the period token .... again thats all if at a certain point in time I want to do that). 

So I believe I should be good right? What you are saying was that if I want period_token to be 7d but on the backend I have max_ttl 2d for example. Right? 


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/5219ab20-141e-4890-8d22-af75775729f2%40googlegroups.com.

Calvin Leung Huang

unread,
Nov 18, 2019, 2:15:04 PM11/18/19
to Vault
Hi Ivan,

So I believe I should be good right? 

That's correct. In your scenario you shouldn't have to worry about the mount's max TTL since the period is less than that value.

What you are saying was that if I want period_token to be 7d but on the backend I have max_ttl 2d for example. Right?

 Yes, precisely that.


- Calvin

Ivan Varbanov

unread,
Nov 18, 2019, 2:22:49 PM11/18/19
to vault...@googlegroups.com
Thank you Calvin for your prompt reply and clarification! You guys rocks!

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/c7a138a9-7fc8-4459-8529-e53eb6ae9d93%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages