vault approle secret_id_accessor expires before secret_id

Created on 13 Dec 2019  Â·  4Comments  Â·  Source: hashicorp/vault

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:

  1. Run
vault write auth/approle/role/my-role \
    secret_id_ttl=129600m \
    token_ttl=20m \
    token_max_ttl=0
  1. Run
vault write -f auth/approle/role/my-role/secret-id
Key                   Value
---                   -----
secret_id             <secret_id>
secret_id_accessor    <secret_id_accessor>
  1. wait 32 days,
 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 Server Version (retrieve with vault status): 1.3.0
  • Vault CLI Version (retrieve with vault version): 1.2.3
  • Server Operating System/Architecture: Kubernetes (GKE)
autapprole bug

Most helpful comment

Hello! You've hit the system/mount max ttl:

Specifically (emphasis mine):

  1. The system max TTL, which is 32 days but can be changed in Vault's configuration file.
  2. 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.
  3. 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!

All 4 comments

Hello! You've hit the system/mount max ttl:

Specifically (emphasis mine):

  1. The system max TTL, which is 32 days but can be changed in Vault's configuration file.
  2. 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.
  3. 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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

tamalsaha picture tamalsaha  Â·  34Comments

sochoa picture sochoa  Â·  39Comments

ekristen picture ekristen  Â·  60Comments

Luzifer picture Luzifer  Â·  37Comments

ekristen picture ekristen  Â·  34Comments