Part of this article needs the configuration parameter raw_storage_endpoint enabled and uses a token with a privileged policy on the path of: sys/*. A root-token is used in the demonstrations below.
As a Vault administrator you may be faced with the task of identifying tokens, leases or entities that may be associated to the respective identities in each mount.
Listing Token Accessors & Entities
The API or CLI list operation can be used on the path below to gain listings of:
- /sys/leases/lookup - all leases presently applicable to any mount
- /auth/token/accessors - accessor IDs of all generated tokens present
For example - using a newly installed Vault instance containing only the initial root token - we can use the listed accessor_id to perform a lookup where the parameters of: display_name, path, policy as well some others can help to identify its origin and owner.
# // list current auth accessors
vault list auth/token/accessors
# Keys
# ----
# 3LtijwdXqw3AxuffghdRXREq
vault token lookup -accessor 3LtijwdXqw3AxuffghdRXREq
# Key Value
# --- -----
# accessor 3LtijwdXqw3AxuffghdRXREq
# creation_time 1632493058
# creation_ttl 0s
# display_name root
# entity_id n/a
# expire_time <nil>
# explicit_max_ttl 0s
# id n/a
# meta <nil>
# num_uses 0
# orphan true
# path auth/token/root
# policies [root]
# ttl 0s
# type service
# // ^^ note that it's root from display_name, path & 'root' policy.
Accessors from other authentication mounts such as LDAP should be distinguishable by the difference in parameter values as seen in the following example:
# // After auth method (LDAP) setup & with creds generated by Vault.
vault list auth/token/accessors
# Keys
# ----
# 3LtijwdXqw3AxuffghdRXREq
# QBf9Rs3fTr8wlxJMoSDYCXhu
vault token lookup -accessor QBf9Rs3fTr8wlxJMoSDYCXhu
# Key Value
# --- -----
# accessor QBf9Rs3fTr8wlxJMoSDYCXhu
# creation_time 1632833445
# creation_ttl 768h
# display_name ldap-laura
# entity_id cbd0846f-ed05-794c-d1cb-438b955b1de3
# expire_time 2021-10-30T12:50:45.693048108Z
# explicit_max_ttl 0s
# id n/a
# issue_time 2021-09-28T12:50:45.69305424Z
# meta map[username:laura]
# num_uses 0
# orphan true
# path auth/ldap/login/laura
# policies [default]
# renewable true
# ttl 767h47m43s
# type service
# // ^^ here we see this relates to ldap auth path.
The entity_id that's automatically generated by Vault can be read via a list on the /identity/entity/id API showing affiliated aliases, entity associations to the related mounts, roles or users - like for example :
vault read /identity/entity/id list=true -format=json
# {
# "request_id": "630e0a42-6131-6235-bc70-6202a2f0ace8",
# "lease_id": "",
# "lease_duration": 0,
# "renewable": false,
# "data": {
# "key_info": {
# "cbd0846f-ed05-794c-d1cb-438b955b1de3": {
# "aliases": [
# {
# "id": "30972c7c-6c35-2ce5-0e5a-4e4395426965",
# "mount_accessor": "auth_ldap_13e27271",
# "mount_path": "auth/ldap/",
# "mount_type": "ldap",
# "name": "laura"
# }
# ],
# "name": "entity_00432429"
# }
# },
# "keys": [
# "cbd0846f-ed05-794c-d1cb-438b955b1de3"
# ]
# },
# "warnings": null
# }
In the event that the LDAP auth mount in question is disabled and re-setup anew - a re-listing of /identity/entity/id will highlight former aliases that are clearly without any associated mount_type or mount_path (it can be a blank empty string "" too in some places)
vault read /identity/entity/id list=true -format=json
# {
# "request_id": "dbb09de1-07d2-7fa1-2b85-2448fd01a9da",
# "lease_id": "",
# "lease_duration": 0,
# "renewable": false,
# "data": {
# "key_info": {
# "b17a5426-990c-58f7-af16-7b2f3c5aed24": {
# "aliases": [
# {
# "id": "9a377edd-2b53-08d4-a879-57059ff0c318",
# "mount_accessor": "auth_ldap_3569a3e6",
# "mount_path": "auth/ldap/",
# "mount_type": "ldap",
# "name": "andrew"
# }
# ],
# "name": "entity_d4d634e1"
# },
# "fe3c5bb1-a667-bdc7-8a49-29131f53a33b": {
# "aliases": [
# {
# "id": "6fec61e1-da0e-1a53-bc57-f9cf58b3eb53",
# "mount_accessor": "auth_ldap_3569a3e6",
# "mount_path": "auth/ldap/",
# "mount_type": "ldap",
# "name": "laura"
# }
# ],
# "name": "entity_657e082d"
# },
# "cbd0846f-ed05-794c-d1cb-438b955b1de3": {
# "aliases": [
# {
# "id": "30972c7c-6c35-2ce5-0e5a-4e4395426965",
# "mount_accessor": "auth_ldap_13e27271",
# "name": "laura"
# }
# ],
# "name": "entity_00432429"
# }
# },
# "keys": [
# "b17a5426-990c-58f7-af16-7b2f3c5aed24",
# "fe3c5bb1-a667-bdc7-8a49-29131f53a33b",
# "cbd0846f-ed05-794c-d1cb-438b955b1de3"
# ]
# },
# "warnings": null
# }
# // ^^ former 'laura' alias is no longer linked to any mount.
Listing Leases
Viewing all of the leases presently stored in Vault can be done by starting at the root-level listing of /sys/leases/lookup - which lists both auth and secrets at the root-level or just auth if only authentication related leases are present.
Each auth and secrets path can be further detailed to comprise a complete path where the listed key values are the individual leases that are current - like for example:
vault list /sys/leases/lookup/auth
# // ...
vault list /sys/leases/lookup/auth/ldap
# // ...
# // ^^ vault list each sub-path till keys are listed:
vault list /sys/leases/lookup/auth/ldap/login/andrew
# Keys
# ----
# h900f21036a8d83528ec6beaa4aa5a6cfdb1ddcbbc1ed7df18c4c74a4ec50d7b9
# hc569e568a1e79095a1cf8e1d42784efe9c7b8dbab39756ef7d5c61948c839386
# // ^^ LDAP user Andrew has two leases
Performing a lease lookup of one of the above leases via CLI will show important TTL and duration related properties such as:
VLEASE_PATH=auth/ldap/login/andrew/h900f21036a8d83528ec6beaa4aa5a6cfdb1ddcbbc1ed7df18c4c74a4ec50d7b9
vault write /sys/leases/lookup lease_id=${VLEASE_PATH} -format=json
# {
# "request_id": "d71f1e39-f6be-4e7b-e2b6-fd46992672a2",
# "lease_id": "",
# "lease_duration": 0,
# "renewable": false,
# "data": {
# "expire_time": "2021-10-30T13:23:17.639897824Z",
# "id": "auth/ldap/login/andrew/h900f21036a8d83528ec6beaa4aa5a6cfdb1ddcbbc1ed7df18c4c74a4ec50d7b9",
# "issue_time": "2021-09-28T13:23:17.639904852Z",
# "last_renewal": null,
# "renewable": true,
# "ttl": 2759489
# },
# "warnings": null
# }
In the above example a positive TTL is indicative of the leases validity and the parameters of expire_time as well as issue_time help to determine its validity or relevance, whereas a negative TTL is hinting to potential issues with the revocation that was last performed. The revocation of leases use the complete lease_id path and can resemble:
VLEASE_PATH=auth/ldap/login/andrew/h900f21036a8d83528ec6beaa4aa5a6cfdb1ddcbbc1ed7df18c4c74a4ec50d7b9
vault lease revoke ${VLEASE_PATH}
# All revocation operations queued successfully!
# // consider --force & --prefix as needed eg:
# vault lease revoke --force --prefix ...
However - in some cases you may be investigating a particular lease and striving to traverse directly to its token or accessor. This is possible in cases where raw_storage_endpoint is enabled (which should be used cautiously since it will divulge actual end-user tokens). Using the CLI utility jq to parse JSON responses from Vault - the example below can be used to read the lease in more detail:
vault read /sys/raw/sys/expire/id/${VLEASE_PATH} -format=json | jq .'data.value' | sed 's/\\"/"/g' | sed 's/\"{/\{/g' | sed 's/}\"/}/g' | jq
# {
# "lease_id": "auth/ldap/login/andrew/h900f21036a8d83528ec6beaa4aa5a6cfdb1ddcbbc1ed7df18c4c74a4ec50d7b9",
# "client_token": "s.4lq1uAI705DstEWNlaMGOdjY",
# "token_type": 0,
# "path": "auth/ldap/login/andrew",
# "data": null,
# "secret": null,
# "auth": {
# "lease": 2764800000000000,
# "max_ttl": 0,
# "renewable": true,
# "internal_data": {
# "password": "andrew"
# },
# "display_name": "ldap-andrew",
# "policies": null,
# "token_policies": [
# "default"
# ],
# "identity_policies": null,
# "external_namespace_policies": null,
# "no_default_policy": false,
# "metadata": {
# "username": "andrew"
# },
# "client_token": "s.4lq1uAI705DstEWNlaMGOdjY",
# "accessor": "4V2AECc42R0y1fygZl9Vre6K",
# "period": 0,
# "explicit_max_ttl": 0,
# "num_uses": 0,
# "entity_id": "b17a5426-990c-58f7-af16-7b2f3c5aed24",
# "alias": {
# "mount_type": "ldap",
# "mount_accessor": "auth_ldap_3569a3e6",
# "name": "andrew"
# },
# "group_aliases": null,
# "bound_cidrs": null,
# "creation_path": "",
# "token_type": 1,
# "orphan": true
# },
# "issue_time": "2021-09-28T13:23:17.639904852Z",
# "expire_time": "2021-10-30T13:23:17.639897824Z",
# "last_renewal_time": "0001-01-01T00:00:00Z",
# "version": 1
# }
In the above example we can see the completed correlation of the lease to the related accessor and all other available details.
Resources
- Docs: vault list
- Docs: List Entities by ID
- Docs: Tokens - List Accessors
- Docs: Read Lease
- Learn: Auth Methods - Token
- Learn: Token Management
- Learn: Troubleshoot Irrevocable Leases
- Docs: Vault Limits and Maximums - Entity and group limits