We can't trust a remote secret store to guarantee that it will honour a lease duration on an authenticated token. As a fail-safe, we limit the time that we hold on to an authentication token.
While the secret service should always guarantee an authentication token lease, we have had a long-standing bug in our JVM secret service where it doesn't. In addition, our JVM secret service doesn't support app role authentication and returns user/password TTLs of 7 days for human convenience. Vault's documentation also recommends shorter TTLs to avoid memory exhaustion during their purging. There's no official statement on the amount of time the max should be, but I saw some Vault examples show 30 minutes. These values can always be overridden; the change here is to permit a maximum and facilitate it to be changed.
We can't trust a remote secret store to guarantee that it will honour a lease duration on an authenticated token. As a fail-safe, we limit the time that we hold on to an authentication token.
While the secret service should always guarantee an authentication token lease, we have had a long-standing bug in our JVM secret service where it doesn't. In addition, our JVM secret service doesn't support app role authentication and returns user/password TTLs of 7 days for human convenience. Vault's documentation also recommends shorter TTLs to avoid memory exhaustion during their purging. There's no official statement on the amount of time the max should be, but I saw some Vault examples show 30 minutes. These values can always be overridden; the change here is to permit a maximum and facilitate it to be changed.
For more info: https://learn.hashicorp.com/tutorials/vault/approle-best-practices?in=vault/auth-methods#token-lifetime-considerations