« Update Security index settings SAML prepare authentication API »

› › ›

Bulk update API keys API

edit

Bulk update API keys API

edit

Request

edit

POST /_security/api_key/_bulk_update

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 API keys, the owner user’s credentials are required.

Description

edit

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, metadata and expiration. 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.

If you don’t specify role_descriptors in the request, a call to this API might still change an 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.

Request body

edit

You can specify the following parameters in the request body.

ids: (Required, list) The IDs of the API keys to update.

role_descriptors: (Optional, object) The role descriptors to assign to the API keys. An API key’s effective permissions are an intersection of its assigned privileges and the point-in-time snapshot of permissions of the owner user. You can assign new privileges by specifying them in this parameter. To remove assigned privileges, supply the role_descriptors parameter as an empty object {}. If an API key has no assigned privileges, it inherits the owner user’s full permissions. 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 API keys API.
metadata: (Optional, object) Arbitrary, nested metadata to associate with the API keys.

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.

expiration: (Optional, string) Expiration time for the API keys. By default, API keys never expire. Can be omitted to leave unchanged.

Response body

edit

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.

Examples

edit

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

resp = client.security.create_api_key(
    name="my-api-key",
    role_descriptors={
        "role-a": {
            "cluster": [
                "all"
            ],
            "indices": [
                {
                    "names": [
                        "index-a*"
                    ],
                    "privileges": [
                        "read"
                    ]
                }
            ]
        }
    },
    metadata={
        "application": "my-application",
        "environment": {
            "level": 1,
            "trusted": True,
            "tags": [
                "dev",
                "staging"
            ]
        }
    },
)
print(resp)

const response = await client.security.createApiKey({
  name: "my-api-key",
  role_descriptors: {
    "role-a": {
      cluster: ["all"],
      indices: [
        {
          names: ["index-a*"],
          privileges: ["read"],
        },
      ],
    },
  },
  metadata: {
    application: "my-application",
    environment: {
      level: 1,
      trusted: true,
      tags: ["dev", "staging"],
    },
  },
});
console.log(response);

POST /_security/api_key
{
  "name": "my-api-key",
  "role_descriptors": {
    "role-a": {
      "cluster": ["all"],
      "indices": [
        {
          "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:

resp = client.security.create_api_key(
    name="my-other-api-key",
    metadata={
        "application": "my-application",
        "environment": {
            "level": 2,
            "trusted": True,
            "tags": [
                "dev",
                "staging"
            ]
        }
    },
)
print(resp)

const response = await client.security.createApiKey({
  name: "my-other-api-key",
  metadata: {
    application: "my-application",
    environment: {
      level: 2,
      trusted: true,
      tags: ["dev", "staging"],
    },
  },
});
console.log(response);

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"],
  "indices": [
    {
      "names": ["*"],
      "privileges": ["all"]
    }
  ]
}

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

resp = client.security.bulk_update_api_keys(
    body={
        "ids": [
            "VuaCfGcBCdbkQm-e5aOx",
            "H3_AhoIBA9hmeQJdg7ij"
        ],
        "role_descriptors": {
            "role-a": {
                "indices": [
                    {
                        "names": [
                            "*"
                        ],
                        "privileges": [
                            "write"
                        ]
                    }
                ]
            }
        },
        "metadata": {
            "environment": {
                "level": 2,
                "trusted": True,
                "tags": [
                    "production"
                ]
            }
        },
        "expiration": "30d"
    },
)
print(resp)

const response = await client.security.bulkUpdateApiKeys({
  body: {
    ids: ["VuaCfGcBCdbkQm-e5aOx", "H3_AhoIBA9hmeQJdg7ij"],
    role_descriptors: {
      "role-a": {
        indices: [
          {
            names: ["*"],
            privileges: ["write"],
          },
        ],
      },
    },
    metadata: {
      environment: {
        level: 2,
        trusted: true,
        tags: ["production"],
      },
    },
    expiration: "30d",
  },
});
console.log(response);

POST /_security/api_key/_bulk_update
{
  "ids": [
    "VuaCfGcBCdbkQm-e5aOx",
    "H3_AhoIBA9hmeQJdg7ij"
  ],
  "role_descriptors": {
    "role-a": {
      "indices": [
        {
          "names": ["*"],
          "privileges": ["write"]
        }
      ]
    }
  },
  "metadata": {
    "environment": {
       "level": 2,
       "trusted": true,
       "tags": ["production"]
    }
  },
  "expiration": "30d"
}

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:

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

The following example removes the API keys' previously assigned permissions, making them inherit the owner user’s full permissions.

resp = client.security.bulk_update_api_keys(
    body={
        "ids": [
            "VuaCfGcBCdbkQm-e5aOx",
            "H3_AhoIBA9hmeQJdg7ij"
        ],
        "role_descriptors": {}
    },
)
print(resp)

const response = await client.security.bulkUpdateApiKeys({
  body: {
    ids: ["VuaCfGcBCdbkQm-e5aOx", "H3_AhoIBA9hmeQJdg7ij"],
    role_descriptors: {},
  },
});
console.log(response);

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"],
  "indices": [
    {
      "names": ["*"],
      "privileges": ["all"]
    }
  ]
}

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

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

The following request auto-updates the snapshot of the user’s permissions associated with the two API keys.

resp = client.security.bulk_update_api_keys(
    body={
        "ids": [
            "VuaCfGcBCdbkQm-e5aOx",
            "H3_AhoIBA9hmeQJdg7ij"
        ]
    },
)
print(resp)

const response = await client.security.bulkUpdateApiKeys({
  body: {
    ids: ["VuaCfGcBCdbkQm-e5aOx", "H3_AhoIBA9hmeQJdg7ij"],
  },
});
console.log(response);

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"],
  "indices": [
    {
      "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]"
         }
       }
    }
  }
}

	This field is not present in the response when `count` is 0.
	The ID of the API key for which the error occurred.
	The error details may also include a `caused_by` field.

« Update Security index settings SAML prepare authentication API »