Feature: Provide a way to set the global default for secret_id_ttl with the AppRole auth method to 365 days or any value other than 0 (non-expiring/ permanent). For Enterprise Vault: this global setting should carry down to Namespaces/ Child Namespaces in order to enforce strict secret_id_ttls for everyone. We do not want any user being able to create a permanent credential to Vault. Similar to being able to enforce Token TTL defaults.
Issue: The default behavior of the AppRole auth method, when creating a new role, is that the secret_id_ttl defaults to 0 (non-expiring/ permanent). Due to this default behavior, many organizations end up with tons of non-expiring/ permanent credentials to HashiCorp Vault - which seems like pretty bad security practice for such a sensitive security tool.
Most organizations have an IAM policy that restricts any credential to a specific threshold (like 90 days or 365 days). Having default non-expiring credentials like this is going to result in tons of eventual audit findings and manual corrections for Vault users.
So far, I have not been able to find a way to enforce the default behavior of Approle from the top-down/ force users to specify a secret_id_ttl that complies with company policy. We have created advisory documentation to help users setup AppRole to comply with policy and we have detective scripts to catch secret_id_ttls that violate policy but those are not preventative controls, especially considering users who just use CLI help or Hashi documentation when setting up AppRole and the resulting default behavior when creating roles puts them in violation.
Sentinel policies can indeed help here but only when someone explicitly specifies a secret_id_ttl that violates the policy. Example: You can just write a new role with no TTL settings and it will default to a secret_id_ttl of 0 without passing any indication of it in the vault request data:
vault write auth/approle/role/sid-test policies=reader
Even though the secret_id_ttl is set to 0, that value for “secret_id_ttl” does not even get passed in the request to Vault (under request.data):
“request”: {
“id”: “#######################”,
“client_id”: “###########################”,
“operation”: “create”,
“mount_point”: “My-Namespace/auth/approle/”,
“mount_type”: “approle”,
“mount_accessor”: “auth_approle_######”,
“mount_running_version”: “v1.14.1+builtin.vault”,
“mount_class”: “auth”,
“client_token”: “hmac-sha256:####################”,
“client_token_accessor”: “hmac-sha256:###################”,
“namespace”: {
“id”: “######”,
“path”: “My-Namespace/”
},
“path”: “auth/approle/role/sid-test”,
“data”: {
“policies”: “hmac-sha256:#######################”
},…
Since “secret_id_ttl” does not even get passed in the Vault request.data when you create a new role without explicitly specifying the secret_id_ttl - it is very difficult to create an effective Sentinel policy to catch secret IDs matching “0” - so anybody can get around the Sentinel policy simply by issuing the default commands.