POST /_security/api_key/_bulk_update

This API is similar to update single API Key but allows you to apply the same update to multiple API keys in one API call. This operation can greatly improve performance over making individual updates.

It’s not possible to update expired or invalidated API keys.

This API supports updates to API key access scope and metadata. The access scope of each 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.

You can specify the following parameters in the request body.

Within the metadata object, top-level keys beginning with an underscore (_) are reserved for system usage. Any information specified with this parameter fully replaces metadata previously associated with the API key.

A successful request returns a JSON structure that contains the IDs of all updated API keys, the IDs of API keys that already had the requested changes and did not require an update, and error details for any failed update.

For the examples below, assume that a user creates two API keys. The user creates the first API key:

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"]
    }
  }
}

This results in a response with the following API key information.

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

The user creates the second API key:

POST /_security/api_key
{
  "name": "my-other-api-key",
  "metadata": {
    "application": "my-application",
    "environment": {
       "level": 2,
       "trusted": true,
       "tags": ["dev", "staging"]
    }
  }
}

Resulting in the following API key information.

{
  "id": "H3_AhoIBA9hmeQJdg7ij",
  "name": "my-other-api-key",
  "api_key": "134G4ilmT_uGWXHRfJfXXA",
  "encoded": "SDNfQWhvSUJBOWhtZVFKZGc3aWo6MTM0RzRpbG1UX3VHV1hIUmZKZlhYQQ=="
}

Further, assume that the owner user’s permissions are:

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

The following example updates the API keys created above, assigning them new role descriptors and metadata.

POST /_security/api_key/_bulk_update
{
  "ids": [
    "VuaCfGcBCdbkQm-e5aOx",
    "H3_AhoIBA9hmeQJdg7ij"
  ],
  "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 keys were updated:

{
  "updated": [
    "VuaCfGcBCdbkQm-e5aOx",
    "H3_AhoIBA9hmeQJdg7ij"
  ],
  "noops": []
}

Both API keys' 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 keys' previously assigned permissions, making them inherit the owner user’s full permissions.

POST /_security/api_key/_bulk_update
{
  "ids": [
    "VuaCfGcBCdbkQm-e5aOx",
    "H3_AhoIBA9hmeQJdg7ij"
  ],
  "role_descriptors": {}
}

Which returns the response:

{
  "updated": [
    "VuaCfGcBCdbkQm-e5aOx",
    "H3_AhoIBA9hmeQJdg7ij"
  ],
  "noops": []
}

The API keys' effective permissions after the update will be 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 two API keys.

POST /_security/api_key/_bulk_update
{
  "ids": [
    "VuaCfGcBCdbkQm-e5aOx",
    "H3_AhoIBA9hmeQJdg7ij"
  ]
}

Which returns the response:

{
  "updated": [
    "VuaCfGcBCdbkQm-e5aOx",
    "H3_AhoIBA9hmeQJdg7ij"
  ],
  "noops": []
}

Resulting in the following effective permissions for both API keys:

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

If any API keys fail to update, error details are included in the errors field. For example:

{
  "updated": ["VuaCfGcBCdbkQm-e5aOx"],
  "noops": [],
  "errors": { 
    "count": 3,
    "details": {
       "g_PqP4IBcBaEQdwM5-WI": { 
         "type": "resource_not_found_exception",
         "reason": "no API key owned by requesting user found for ID [g_PqP4IBcBaEQdwM5-WI]"
       },
       "OM4cg4IBGgpHBfLerY4B": {
         "type": "illegal_argument_exception",
         "reason": "cannot update invalidated API key [OM4cg4IBGgpHBfLerY4B]"
       },
       "Os4gg4IBGgpHBfLe2I7j": {
         "type": "exception",
         "reason": "bulk request execution failure",
         "caused_by": { 
           "type" : "version_conflict_engine_exception",
           "reason" : "[1]: version conflict, required seqNo [1], primary term [1]. current document has seqNo [2] and primary term [1]"
         }
       }
    }
  }
}