Update API key API

edit

Request

edit

PUT /_security/api_key/<id>

Prerequisites

edit
  • To use this API, you must have at least the manage_own_api_key cluster privilege. Users can only update API keys that they created or that were granted to them. To update another user’s API key, use the run_as feature to submit a request on behalf of another user.

It’s not possible to use an API key as the authentication credential for this API. To update an API key, the owner user’s credentials are required.

Description

edit

Use this API to update API keys created by the create API Key or grant API Key APIs. It’s not possible to update expired API keys, or API keys that have been invalidated by invalidate API Key.

This API supports updates to an API key’s access scope and metadata. The access scope of an API key is derived from the role_descriptors you specify in the request, and a snapshot of the owner user’s permissions at the time of the request. The snapshot of the owner’s permissions is updated automatically on every call.

If you don’t specify role_descriptors in the request, a call to this API might still change the API key’s access scope. This change can occur if the owner user’s permissions have changed since the API key was created or last modified.

Path parameters

edit
id
(Required, string) The ID of the API key to update.

Request body

edit

You can specify the following parameters in the request body, which is optional.

role_descriptors
(Optional, object) The role descriptors to assign to this API key. The API key’s effective permissions are an intersection of its assigned privileges and the point in time snapshot of permissions of the owner user. If no privileges are assigned, the API key inherits the owner user’s full permissions. You can assign new privileges to the API key by specifying them in this parameter. To remove assigned privileges, you can supply an empty role_descriptors parameter. The snapshot of the owner’s permissions is always updated, whether you supply the role_descriptors parameter or not. The structure of a role descriptor is the same as the request for the create or update roles API.
metadata
(Optional, object) Arbitrary metadata that you want to associate with the API key. It supports nested data structure. Within the metadata object, top-level keys beginning with _ are reserved for system usage. When specified, this fully replaces metadata previously associated with the API key.

Response body

edit
updated
(boolean) If true, the API key was updated. If false, the API key didn’t change because no change was detected.

Examples

edit

If you create an API key as follows:

POST /_security/api_key
{
  "name": "my-api-key",
  "role_descriptors": {
    "role-a": {
      "cluster": ["all"],
      "index": [
        {
          "names": ["index-a*"],
          "privileges": ["read"]
        }
      ]
    }
  },
  "metadata": {
    "application": "my-application",
    "environment": {
       "level": 1,
       "trusted": true,
       "tags": ["dev", "staging"]
    }
  }
}

A successful call returns a JSON structure that provides API key information. For example:

{
  "id": "VuaCfGcBCdbkQm-e5aOx",
  "name": "my-api-key",
  "api_key": "ui2lp2axTNmsyakw9tvNnw",
  "encoded": "VnVhQ2ZHY0JDZGJrUW0tZTVhT3g6dWkybHAyYXhUTm1zeWFrdzl0dk5udw=="
}

For the examples below, assume that the owner user’s permissions are:

{
  "cluster": ["all"],
  "index": [
    {
      "names": ["*"],
      "privileges": ["all"]
    }
  ]
}

The following example updates the API key created above, assigning it new role descriptors and metadata:

PUT /_security/api_key/VuaCfGcBCdbkQm-e5aOx
{
  "role_descriptors": {
    "role-a": {
      "index": [
        {
          "names": ["*"],
          "privileges": ["write"]
        }
      ]
    }
  },
  "metadata": {
    "environment": {
       "level": 2,
       "trusted": true,
       "tags": ["production"]
    }
  }
}

A successful call returns a JSON structure indicating that the API key was updated:

{
  "updated": true
}

The API key’s effective permissions after the update will be the intersection of the supplied role descriptors and the owner user’s permissions:

{
  "index": [
    {
      "names": ["*"],
      "privileges": ["write"]
    }
  ]
}

The following example removes the API key’s previously assigned permissions.

PUT /_security/api_key/VuaCfGcBCdbkQm-e5aOx
{
  "role_descriptors": {}
}

Which returns the response:

{
  "updated": true
}

The API key’s effective permissions after the update will the same as the owner user’s:

{
  "cluster": ["all"],
  "index": [
    {
      "names": ["*"],
      "privileges": ["all"]
    }
  ]
}

For the next example, assume that the owner user’s permissions have changed from the original permissions to:

{
  "cluster": ["manage_security"],
  "index": [
    {
      "names": ["*"],
      "privileges": ["read"]
    }
  ]
}

The following request auto-updates the snapshot of the user’s permissions associated with the API key:

PUT /_security/api_key/VuaCfGcBCdbkQm-e5aOx

Which returns the response:

{
  "updated": true
}

Resulting in the following effective permissions for the API key:

{
  "cluster": ["manage_security"],
  "index": [
    {
      "names": ["*"],
      "privileges": ["read"]
    }
  ]
}