Identifying Tokens, Leases and Entities

Avatar
Mehdi Ahmadi
  • Updated

To complete part of this article, the raw_storage_endpoint parameter in the Vault config must be enabled. A token with a policy for the sys/*path is also required. The examples below use a root token.

As a Vault administrator, you may need to identify tokens, leases, or entities associated to respective identities in each mount.

Listing Token Accessors & Entities

The API or CLI list operation returns data from the following paths

The token accessor is used to perform a token lookup. The display_name, path, and policies fields identify the origin and owner. In this example, the display_name, path, and policies fields show root as the origin and owner.

$ vault list auth/token/accessors
Keys
----
Sjw0FzI5DifAjfinJiq0Fsj0

$ vault token lookup -accessor Sjw0FzI5DifAjfinJiq0Fsj0
Key Value
--- -----
accessor Sjw0FzI5DifAjfinJiq0Fsj0
creation_time 1727107066
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

Accessors from authentication methods, such as LDAP in this example, are distinguishable by the different values returned.

$ vault list auth/token/accessors
Keys
----
dTjIKvNgxF5OhAipEE9dnsU2

$ vault token lookup -accessor dTjIKvNgxF5OhAipEE9dnsU2
Key Value
--- -----
accessor dTjIKvNgxF5OhAipEE9dnsU2
creation_time 1727124616
creation_ttl 768h
display_name ldap-user01
entity_id 8e423680-fd16-3762-8768-62c554d9a733
expire_time 2024-10-25T20:50:16.736955919Z
explicit_max_ttl 0s
id n/a
issue_time 2024-09-23T20:50:16.736959669Z
meta map[username:user01]
num_uses 0
orphan true
path auth/ldap/login/user01
policies [default]
renewable true
ttl 767h58m21s
type service

The /identity/entity/id endpoint returns a list of available entities by their identifiers. This endpoint shows the aliases and entities associated to specific mounts.

$ vault read -format=json /identity/entity/id list=true
{
  "request_id": "7b5ca6e9-7ca8-c3d0-5cc5-9106a5a73c0a",
  "lease_id": "",
  "lease_duration": 0,
  "renewable": false,
  "data": {
    "key_info": {
      "229751b5-d2d3-f4f1-8477-af194b10169a": {
        "aliases": [
          {
            "id": "96989bce-7706-c016-7826-da6b29e82543",
            "mount_accessor": "auth_kubernetes_0ef3cfe2",
            "mount_path": "auth/kubernetes/",
            "mount_type": "kubernetes",
            "name": "ddf54727-5eae-4579-b4f7-7daa60b574b4"
          }
        ],
        "name": "entity_68ad4094"
      },
      "8e423680-fd16-3762-8768-62c554d9a733": {
        "aliases": [
          {
            "id": "5a2e95e3-ba21-a048-85da-922e662bace7",
            "mount_accessor": "auth_ldap_2ba27a8a",
            "mount_path": "auth/ldap/",
            "mount_type": "ldap",
            "name": "user01"
          }
        ],
        "name": "entity_01d43044"
      }
    },
    "keys": [
      "229751b5-d2d3-f4f1-8477-af194b10169a",
      "8e423680-fd16-3762-8768-62c554d9a733"
    ]
  },
  "warnings": null
}

In the event that an authentication method, such a LDAP in this example, is disabled and a new LDAP authentication method is configured, the /identity/entity/id endpoint will return former aliases. Note that the former user01 alias in this example is not linked to a mount, since the mount_type and mount_path fields are not displayed with the alias. These fields may also be set to an empty string to denote that an alias is not associated with the mount.

$ vault read -format=json /identity/entity/id list=true
{
  "request_id": "b83c9635-1d87-0f97-c9a3-4504c2d66dfc",
  "lease_id": "",
  "lease_duration": 0,
  "renewable": false,
  "data": {
    "key_info": {
      "229751b5-d2d3-f4f1-8477-af194b10169a": {
        "aliases": [
          {
            "id": "96989bce-7706-c016-7826-da6b29e82543",
            "mount_accessor": "auth_kubernetes_0ef3cfe2",
            "mount_path": "auth/kubernetes/",
            "mount_type": "kubernetes",
            "name": "ddf54727-5eae-4579-b4f7-7daa60b574b4"
          }
        ],
        "name": "entity_68ad4094"
      },
      "47f65e80-a837-e880-a6e2-eefe7151e7b2": {
        "aliases": [
          {
            "id": "f0d026af-4b3c-8f50-eaf8-a592fcdb1c59",
            "mount_accessor": "auth_ldap_07f78c8f",
            "mount_path": "auth/ldap/",
            "mount_type": "ldap",
            "name": "user01"
          }
        ],
        "name": "entity_0d9cd722"
      },
      "8e423680-fd16-3762-8768-62c554d9a733": {
        "aliases": [
          {
            "id": "5a2e95e3-ba21-a048-85da-922e662bace7",
            "mount_accessor": "auth_ldap_2ba27a8a",
            "name": "user01"
          }
        ],
        "name": "entity_01d43044"
      }
    },
    "keys": [
      "229751b5-d2d3-f4f1-8477-af194b10169a",
      "47f65e80-a837-e880-a6e2-eefe7151e7b2",
      "8e423680-fd16-3762-8768-62c554d9a733"
    ]
  },
  "warnings": null
}

Listing Leases

The /sys/leases/lookup endpoint returns all of the leases currently stored in Vault. When this command is run at the root-level, both authentication method mounts and secrets engine mounts are shown. If there are no active leases from any secrets engines, only the auth mount will be displayed. Each auth and secrets engine mount can be further examined using the full path to the listed key value. In this example, the user01 LDAP user has one lease.

$ vault list /sys/leases/lookup/auth
Keys
----
kubernetes/
ldap/

$ vault list /sys/leases/lookup/auth/ldap
Keys
----
login/

$ vault list /sys/leases/lookup/auth/ldap/login
Keys
----
user01/

$ vault list /sys/leases/lookup/auth/ldap/login/user01
Keys
----
hb580d20c12e6756112838ba9e54c795d0c776dbdb3f457b39378dbafe5108fb6

A lease lookup provides key information about a lease's TTL

$ VLEASE_PATH=auth/ldap/login/user01/h950fe17ffe60233102f7fbba41c65507855621e028e881399afcffd8e23e585c
$ vault write -format=json /sys/leases/lookup lease_id=${VLEASE_PATH} 
{
  "request_id": "1cc1a196-29b4-8f07-35f1-749bd17a0427",
  "lease_id": "",
  "lease_duration": 0,
  "renewable": false,
  "data": {
    "expire_time": "2024-10-25T22:36:09.6909543Z",
    "id": "auth/ldap/login/user01/h950fe17ffe60233102f7fbba41c65507855621e028e881399afcffd8e23e585c",
    "issue_time": "2024-09-23T22:36:09.690957217Z",
    "last_renewal": null,
    "renewable": true,
    "ttl": 2764518
},
"warnings": null
}

In the example above, a ttl field, along with the expire_time and issue_time fields indicate a valid TTL. A negative ttl field suggests potential issues with the revocation performed. A lease revocation is done using the complete lease ID path. The --force and --prefix options should be supplied as needed.

$ VLEASE_PATH=auth/ldap/login/user01/h950fe17ffe60233102f7fbba41c65507855621e028e881399afcffd8e23e585c
$ vault lease revoke ${VLEASE_PATH}
All revocation operations queued successfully!

$ vault lease revoke --force --prefix auth/ldap
Success! Force revoked any leases with prefix: auth/ldap

The raw_storage_endpoint parameter enables the sys/raw endpoint, allowing decryption and encryption of raw data into and out of the security barrier. This is a highly privileged endpoint. This parameter should be enabled with caution, since it can divulge end-user tokens and other sensitive information. This endpoint will return lease information in more detail.

$ vault read -format=json /sys/raw/sys/expire/id/${VLEASE_PATH} | jq .'data.value' | sed 's/\\"/"/g' | sed 's/\"{/\{/g' | sed 's/}\"/}/g' | jq
{
  "lease_id": "auth/ldap/login/user01/h2e3ad1b9b54ea33262bc34f4e7f73c28e6643939c98b71964c10644cf213ce0d",
  "client_token": "hvs.nCtGfljHrWSNLeb2G33NUAVk",
  "token_type": 0,
  "path": "auth/ldap/login/user01",
  "data": null,
  "secret": null,
  "auth": {
    "lease": 2764800000000000,
    "max_ttl": 0,
    "renewable": true,
    "internal_data": {
      "password": "password01"
    },
    "display_name": "ldap-user01",
    "policies": null,
    "token_policies": [
      "default"
    ],
    "identity_policies": null,
    "external_namespace_policies": null,
    "no_default_policy": false,
    "metadata": {
      "username": "user01"
    },
    "client_token": "hvs.nCtGfljHrWSNLeb2G33NUAVk",
    "accessor": "13Yy8wL2IqaXqZSpQC6Ck6vP",
    "period": 0,
    "explicit_max_ttl": 0,
    "num_uses": 0,
    "entity_id": "47f65e80-a837-e880-a6e2-eefe7151e7b2",
    "alias": {
      "mount_type": "ldap",
      "mount_accessor": "auth_ldap_07f78c8f",
      "name": "user01",
      "metadata": {
        "name": "user01"
      }
    },
    "group_aliases": null,
    "bound_cidrs": null,
    "creation_path": "",
    "token_type": 1,
    "orphan": true,
    "policy_results": null,
    "mfa_requirement": null,
    "entity_created": false
  },
  "issue_time": "2024-09-23T22:56:56.063101794Z",
  "expire_time": "2024-10-25T22:56:56.063099127Z",
  "last_renewal_time": "0001-01-01T00:00:00Z",
  "login_role": "",
  "version": 1,
  "revokeErr": ""
}

The example above shows the correlation of the lease to its related accessor.

Resources

Articles in this section

Related articles