Approle Secret_ID with longer TTL expires before time.

An invalid secret id error is observed when a user or an application tries to log in via the approle auth method even after you've set yoursecret_id_ttlas2160h(90 days (Let's say)) which you can also check viavault read auth/approle/role/your_role_name.

This could be because of the following few reasons.

• If the auth mount is tuned differently. For example, as you can see, default_lease_ttl is 768h, hence the secret_id_ttl will be capped accordingly.

$vault read sys/auth/approle/tune

Key                  Value
---                  -----
default_lease_ttl    768h
description          n/a
force_no_cache       false
max_lease_ttl        768h
token_type           default-service

• • Tune the auth method for the role's secret_id_ttl to be honored, via:

vault auth tune -default-lease-ttl=2160h -max-lease-ttl=2160h approle/

• • However, after doing this, the token you'll generate viavault write auth/approle/login role_id=y-y-y-y- secret_id=z-z-z-z-will also have thetoken_ttlas2160hif you havetoken_ttlset as0sin approle's role.
    
    
  • If you would like to update thetoken_ttllesser thansecret_idttljust runvault write auth/approle/role/your_role_name token_ttl=768h(or set whateverttl you need for the token).
    
    
• If the default_lease_ttl is imposed from the Vault config file.
  • In the presence of default_lease_ttl within the Vault config file, all the auth engines in Vault pick up the default_lease_ttl from the config file when the service starts/restarts.
    • In cases like these, you can explicitly tune the auth engine as explained in the previous point for longer TTL to be honored as configured via role.