Describe the bug
we default the secret_id_ttl=129600m on our approles but after a month ( 32 days[768h]) we are no longer able to login with the secret_id {"errors":["invalid secret id"]}, when looking at the secret_id_accessor we noticed that it expires around this time.
â–¶ vault write auth/approle/role/<role-name>/secret-id-accessor/lookup secret_id_accessor=<accessor_id>
Key Value
--- -----
cidr_list []
creation_time 2019-12-13T14:52:59.502388079Z
expiration_time 2020-01-14T14:52:59.502388079Z
last_updated_time 2019-12-13T14:52:59.502388079Z
metadata map[]
secret_id_accessor <accessor_id>
secret_id_num_uses 0
secret_id_ttl 4320h
token_bound_cidrs []
To Reproduce
Steps to reproduce the behavior:
vault write auth/approle/role/my-role \
secret_id_ttl=129600m \
token_ttl=20m \
token_max_ttl=0
vault write -f auth/approle/role/my-role/secret-id
Key Value
--- -----
secret_id <secret_id>
secret_id_accessor <secret_id_accessor>
curl -v \
--header "X-Vault-Token: ..." \
--request POST \
--data @payload.json \
https://vault.example.com/v1/auth/approle/login
Response: {"errors":["invalid secret id"]}
Expected behavior
secret_id would be able to login for full ttl
Environment:
vault status): 1.3.0vault version): 1.2.3Hello! You've hit the system/mount max ttl:
Specifically (emphasis mine):
- The system max TTL, which is 32 days but can be changed in Vault's configuration file.
- The max TTL set on a mount using mount tuning. This value is allowed to override the system max TTL -- it can be longer or shorter, and if set this value will be respected.
- A value suggested by the auth method that issued the token. This might be configured on a per-role, per-group, or per-user basis. This value is allowed to be less than the mount max TTL (or, if not set, the system max TTL), but it is not allowed to be longer.
You can see your current max/default TTLs for the AppRole backend with the /sys/mounts endpoint:
You should be able to tune this by tuning the mount configuration:
Note that may require sudo level access to Vault.
I'm going to close this issue for now. Please let us know if you have any other questions!
@catsby I'm in the same boat as @nmnellis. I've looked at the various available mounts on my system, but I can't tell which of these mount points is relevant for the AppRole feature:
magi@arch ~> vault read /sys/mounts
Key Value
--- -----
cubbyhole/ map[accessor:cubbyhole_e25acddc config:map[default_lease_ttl:0 force_no_cache:false max_lease_ttl:0] description:per-token private secret storage external_entropy_access:false local:true options:<nil> seal_wrap:false type:cubbyhole uuid:0f57f1ae-b8ca-ce4f-019d-41c598bc21d5]
identity/ map[accessor:identity_efb7daef config:map[default_lease_ttl:0 force_no_cache:false max_lease_ttl:0] description:identity store external_entropy_access:false local:false options:<nil> seal_wrap:false type:identity uuid:7e14e7d6-1350-d1d4-3613-8912104b5d76]
kaloom-signer/ map[accessor:ssh_d595c337 config:map[default_lease_ttl:0 force_no_cache:false max_lease_ttl:0] description: external_entropy_access:false local:false options:<nil> seal_wrap:false type:ssh uuid:f1b86fec-7d7f-e9ee-7aee-2cd69ae50fc6]
kv/ map[accessor:kv_d41cf24a config:map[default_lease_ttl:0 force_no_cache:false max_lease_ttl:0] description:v2/versioned key/value secret storage external_entropy_access:false local:false options:map[version:2] seal_wrap:false type:kv uuid:c9f4914a-286e-7eec-9c6e-aba969d9c4d7]
secret/ map[accessor:kv_bb0c0f3f config:map[default_lease_ttl:0 force_no_cache:false max_lease_ttl:0] description:key/value secret storage external_entropy_access:false local:false options:<nil> seal_wrap:false type:kv uuid:80dd8313-79c4-c236-4be1-ba144db6db39]
sys/ map[accessor:system_2f6a855b config:map[default_lease_ttl:0 force_no_cache:false max_lease_ttl:0 passthrough_request_headers:[Accept]] description:system endpoints used for control, policy and debugging external_entropy_access:false local:false options:<nil> seal_wrap:false type:system uuid:7a3a10cf-0980-c0e5-0af3-8231534606bb]
I tried:
magi@arch ~> vault write /sys/mounts/identity/tune max_lease_ttl=4320h
Error writing data to sys/mounts/identity/tune: Error making API request.
URL: PUT https://vault.kaloom.io:8200/v1/sys/mounts/identity/tune
Code: 400. Errors:
* cannot tune "identity/"
magi@arch ~> vault write /sys/mounts/sys/tune max_lease_ttl=4320h
Error writing data to sys/mounts/sys/tune: Error making API request.
URL: PUT https://vault.kaloom.io:8200/v1/sys/mounts/sys/tune
Code: 400. Errors:
* cannot tune "sys/"
But neither worked. Any pointers for me? I know I'm doing something wrong but I can't tell what. Essentially I want to be able to generate Secret IDs for AppRoles that can last up to 6 months (4320 hours).
Thanks.
OK, I found the right command:
vault auth tune -max-lease-ttl=4320h approle/
Afterwards generated Secret IDs will indeed last up to 180 days:
magi@arch ~> vault write -f auth/approle/role/xxx/secret-id/lookup secret_id=xxx
Key Value
--- -----
cidr_list []
creation_time 2020-02-05T11:20:08.592444365-05:00
expiration_time 2020-08-03T12:20:08.592444365-04:00
last_updated_time 2020-02-05T11:20:08.592444365-05:00
metadata map[]
secret_id_accessor xxx
secret_id_num_uses 0
secret_id_ttl 4320h
token_bound_cidrs []
Thank you for the follow-up @radcool , I hope this helps others as well.
Most helpful comment
Hello! You've hit the system/mount max ttl:
Specifically (emphasis mine):
You can see your current max/default TTLs for the AppRole backend with the
/sys/mountsendpoint:You should be able to tune this by tuning the mount configuration:
Note that may require sudo level access to Vault.
I'm going to close this issue for now. Please let us know if you have any other questions!