Database token TTL displays incorrectly

[myoung34]

Environment:
0.9.4

• Vault Version:
• Operating System/Architecture:
  ubuntu client, aws linux server

Vault Config File:

$ vault read database/roles/rds-staging
Key                      Value
---                      -----
creation_statements      ["CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}' IN ROLE vault_role_full;"]
db_name                  rds-staging
default_ttl              36000
max_ttl                  86400
renew_statements         n/a
revocation_statements    ["DROP ROLE IF EXISTS \"{{name}}\";"]
rollback_statements      n/a

Expected Behavior:
It should generate a TTL based on the lowest TTL between the mount, my token, and the TTL set for the role above.

Actual Behavior:
It generates the TTL and user correctly, but displays the wrong TTL on generate

Steps to Reproduce:
My token TTL is 8h:

$ vault login -method=ldap username=marc
Password (will be hidden): 
Success! You are now authenticated. The token information displayed below
is already stored in the token helper. You do NOT need to run "vault login"
again. Future Vault requests will automatically use this token.

Key                    Value
---                    -----
..snip...
token_duration         8h
token_renewable        true
...snip...

My database mount tune is 60s default, 30d max:

{
    "default_lease_ttl": 60,
    "max_lease_ttl": 2592000,
    "force_no_cache": false
}

My role (above) is 10h. It should generate a user with an expiration time of now + 8h (because my lowest max is my token at 8h). However when I generate the credentials it shows 10h even though it correctly generated an 8h user:

$ vault read database/creds/rds-staging
Key                Value
---                -----
lease_id           database/creds/rds-staging/2a897866-79ad-99d0-69f3-2566f0256d38
lease_duration     10h 
lease_renewable    true
password           A1a-...
username           v-ldap-mar-rds-stag-qypx812vsqy4088x72s9-1519838046
$ c_rds
psql (9.6.7, server 9.6.6)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
db6t9t6pdmhs5t=> \du 
                                                               List of roles
                      Role name                      |                   Attributes                   |              Member of                  
-----------------------------------------------------+------------------------------------------------+-------------------------------------
 v-ldap-mar-rds-stag-qypx812vsqy4088x72s9-1519838046 | Password valid until 2018-03-01 03:14:06+00    | {vault_role_full}
 vault_role_full                                     | Cannot login                                   | {}
db6t9t6pdmhs5t=> select NOW();
              now                 
-------------------------------
 2018-02-28 17:14:46.798136+00
(1 row)
db6t9t6pdmhs5t=> 

[jefferai]

Can you provide the role configuration?

[myoung34]

  path = "database/config/rds-staging"

  data_json = <<EOF
{
  "plugin_name": "postgresql-database-plugin",
  "allowed_roles": "rds-staging",
  "connection_url": "postgresql://${data.vault_generic_secret.rds_user.data["value"]}:${data.vault_generic_secret.rds_password.data["value"]}@${module.rds.address}:${module.rds.port}/${data.vault_generic_secret.rds_dbname.data["value"]}  "
}
EOF
}

resource "vault_generic_secret" "rds_access_role" {
  path = "database/roles/rds-staging"

  data_json = <<EOF
{
    "db_name": "rds-staging",
    "creation_statements": "[\"...
    "default_ttl": "10h",
    "max_ttl": "24h",
    "revocation_statements": "[\"...]"
}
EOF
}

[jonwolski]

However when I generate the credentials it shows 10h even though it correctly generated an 8h user

'Now' (2018-02-28 17:14:…) + 8 hours is only 2018-03-01 01:14:… , but Password valid until 2018-03-01 03:14:06+00 (10 hours later)

IIUC, I think is not a display issue.

[jefferai]

I'm not sure where you're getting 8 hours from, but the current logic in the database backend uses the default ttl you're setting on the role, which is 10 hours. The PR that I referenced here will cause it to fall back to the mount-set default TTL if a role default TTL isn't set.

[calvn]

It should generate a user with an expiration time of now + 8h (because my lowest max is my token at 8h).

Database credentials generation (i.e. vault read database/creds/rds-staging) takes in the TTL values from the database role (10hr) and/or system TTL values, and not the TTL values in your token (8hr).

[myoung34]

This was more confusion about how TTL is handled. I assumed that it would generate 8h since that's as long as my authorization to Vault is good for, meaning it would revoke anything I had attached to me at that time

[jefferai]

Tokens can be renewed! So lifetimes of secrets are not tied at issuance to lifetimes of tokens, however, if your token does get revoked the associated secrets will too.

[myoung34]

Bad math aside on my part thanks for the info @jefferai and @calvn