Approle Secret ID Expires Before Expected

Vault
1

While creating an approle authentication workflow for our infrastructure, we have been running into issues where the secret id becomes invalid despite all set TTL values suggesting it should live for longer. For example, we have a role for a system to access Vault secrets like so:

Key                        Value
---                        -----
bind_secret_id             true
local_secret_ids           false
policies                   [system-creds cred-provision cert-admin]
secret_id_bound_cidrs      <nil>
secret_id_num_uses         0
secret_id_ttl              2880h
token_bound_cidrs          []
token_explicit_max_ttl     0s
token_max_ttl              30m
token_no_default_policy    false
token_num_uses             0
token_period               0s
token_policies             [system-creds cred-provision cert-admin]
token_ttl                  30m
token_type                 default

The secret_id_ttl is set to live for 2880 hours or 120 days. The approle backend is configured for similar access:

Type - approle
Path - approle/
Accessor - auth_approle_6158da10
Local - No
Seal wrap - No
Default Lease TTL - 86400s
Max Lease TTL - 10368000s
Token Type - default-service

The max lease TTL is 10368000s, which I configured as 120 days but Vault changes to seconds.

Finally, the secret ID that is issued also shows the correct expiration, but in spite of this our secret IDs always end up invalid by the end of 30 days.

Here’s a LIST to a secret ID endpoint:

    "lease_id": "",
    "renewable": false,
    "lease_duration": 0,
    "data": {
        "keys": [
            "***"
        ]
    },
    "wrap_info": null,
    "warnings": null,
    "auth": null

And then info about the secret ID itself:

{
    "request_id": "f38865ca-b8c3-3114-604b-17d998c10b8d",
    "lease_id": "",
    "renewable": false,
    "lease_duration": 0,
    "data": {
        "cidr_list": [],
        "creation_time": "2022-10-14T10:18:37.958909138-07:00",
        "expiration_time": "2023-02-11T09:18:37.958909138-08:00",
        "last_updated_time": "2022-10-14T10:18:37.958909138-07:00",
        "metadata": {},
        "secret_id_accessor": "***",
        "secret_id_num_uses": 0,
        "secret_id_ttl": 10368000,
        "token_bound_cidrs": []
    },
    "wrap_info": null,
    "warnings": null,
    "auth": null
}

The expiration time seems appropriate on the secret ID above.

This seems possibly related to this issue but after changing the values about, we continue to see the issue. When attempting to use the role ID and secret ID, we get:

{"errors":["invalid secret id"]}

After which we issue a new secret ID and the cycle begins anew with expecting the Secret ID to survive for 120 days, and then having it expire after 30 days. We considered the possibility that we were hitting the system max TTL, but documentation says that setting a max TTL value on the Approle backend should override global values.

Any assistance with this would be greatly appreciated! Thanks for your time and patience.

2

None of the TTLs that relate to leases (systemwide ones, nor ones set on particular backend mounts) apply to SecretIDs, as SecretIDs are a separate concept not connected to leases.

The problem you describe seems pretty mysterious - it should be impossible. Is there any chance something/someone is calling the Vault API to explicitly destroy the SecretIDs?

3

Thanks for the quick response!

I checked our systems, and nothing glaring appears to be poking at Vault. I’ll keep investigating that possibility. Would the purported culprit show up in the Vault audit logs by any chance?