OpenSearch/x-pack/docs/en/rest-api/security/invalidate-api-keys.asciidoc

141 lines
3.9 KiB
Plaintext
Raw Normal View History

Add support for API keys to access Elasticsearch (#38291) X-Pack security supports built-in authentication service `token-service` that allows access tokens to be used to access Elasticsearch without using Basic authentication. The tokens are generated by `token-service` based on OAuth2 spec. The access token is a short-lived token (defaults to 20m) and refresh token with a lifetime of 24 hours, making them unsuitable for long-lived or recurring tasks where the system might go offline thereby failing refresh of tokens. This commit introduces a built-in authentication service `api-key-service` that adds support for long-lived tokens aka API keys to access Elasticsearch. The `api-key-service` is consulted after `token-service` in the authentication chain. By default, if TLS is enabled then `api-key-service` is also enabled. The service can be disabled using the configuration setting. The API keys:- - by default do not have an expiration but expiration can be configured where the API keys need to be expired after a certain amount of time. - when generated will keep authentication information of the user that generated them. - can be defined with a role describing the privileges for accessing Elasticsearch and will be limited by the role of the user that generated them - can be invalidated via invalidation API - information can be retrieved via a get API - that have been expired or invalidated will be retained for 1 week before being deleted. The expired API keys remover task handles this. Following are the API key management APIs:- 1. Create API Key - `PUT/POST /_security/api_key` 2. Get API key(s) - `GET /_security/api_key` 3. Invalidate API Key(s) `DELETE /_security/api_key` The API keys can be used to access Elasticsearch using `Authorization` header, where the auth scheme is `ApiKey` and the credentials, is the base64 encoding of API key Id and API key separated by a colon. Example:- ``` curl -H "Authorization: ApiKey YXBpLWtleS1pZDphcGkta2V5" http://localhost:9200/_cluster/health ``` Closes #34383
2019-02-04 22:21:57 -05:00
[role="xpack"]
[[security-api-invalidate-api-key]]
=== Invalidate API Key API
++++
<titleabbrev>Invalidate API key</titleabbrev>
++++
Invalidates one or more API keys.
==== Request
`DELETE /_security/api_key`
==== Description
The API keys created by <<security-api-create-api-key,create API Key>> can be invalidated
using this API.
==== Request Body
The following parameters can be specified in the body of a DELETE request and
pertain to invalidating api keys:
`id` (optional)::
(string) An API key id. This parameter cannot be used with any of `name`, `realm_name` or
`username` are used.
`name` (optional)::
(string) An API key name. This parameter cannot be used with any of `id`, `realm_name` or
`username` are used.
`realm_name` (optional)::
(string) The name of an authentication realm. This parameter cannot be used with either `api_key_id` or `api_key_name`.
`username` (optional)::
(string) The username of a user. This parameter cannot be used with either `api_key_id` or `api_key_name`.
NOTE: While all parameters are optional, at least one of them is required.
==== Examples
The following example invalidates the API key identified by specified `id` immediately:
[source,js]
--------------------------------------------------
DELETE /_security/api_key
{
"id" : "dGhpcyBpcyBub3QgYSByZWFsIHRva2VuIGJ1dCBpdCBpcyBvbmx5IHRlc3QgZGF0YS4gZG8gbm90IHRyeSB0byByZWFkIHRva2VuIQ=="
}
--------------------------------------------------
// NOTCONSOLE
whereas the following example invalidates the API key identified by specified `name` immediately:
[source,js]
--------------------------------------------------
DELETE /_security/api_key
{
"name" : "hadoop_myuser_key"
}
--------------------------------------------------
// NOTCONSOLE
The following example invalidates all API keys for the `native1` realm immediately:
[source,js]
--------------------------------------------------
DELETE /_security/api_key
Add support for API keys to access Elasticsearch (#38291) X-Pack security supports built-in authentication service `token-service` that allows access tokens to be used to access Elasticsearch without using Basic authentication. The tokens are generated by `token-service` based on OAuth2 spec. The access token is a short-lived token (defaults to 20m) and refresh token with a lifetime of 24 hours, making them unsuitable for long-lived or recurring tasks where the system might go offline thereby failing refresh of tokens. This commit introduces a built-in authentication service `api-key-service` that adds support for long-lived tokens aka API keys to access Elasticsearch. The `api-key-service` is consulted after `token-service` in the authentication chain. By default, if TLS is enabled then `api-key-service` is also enabled. The service can be disabled using the configuration setting. The API keys:- - by default do not have an expiration but expiration can be configured where the API keys need to be expired after a certain amount of time. - when generated will keep authentication information of the user that generated them. - can be defined with a role describing the privileges for accessing Elasticsearch and will be limited by the role of the user that generated them - can be invalidated via invalidation API - information can be retrieved via a get API - that have been expired or invalidated will be retained for 1 week before being deleted. The expired API keys remover task handles this. Following are the API key management APIs:- 1. Create API Key - `PUT/POST /_security/api_key` 2. Get API key(s) - `GET /_security/api_key` 3. Invalidate API Key(s) `DELETE /_security/api_key` The API keys can be used to access Elasticsearch using `Authorization` header, where the auth scheme is `ApiKey` and the credentials, is the base64 encoding of API key Id and API key separated by a colon. Example:- ``` curl -H "Authorization: ApiKey YXBpLWtleS1pZDphcGkta2V5" http://localhost:9200/_cluster/health ``` Closes #34383
2019-02-04 22:21:57 -05:00
{
"realm_name" : "native1"
}
--------------------------------------------------
// NOTCONSOLE
The following example invalidates all API keys for the user `myuser` in all realms immediately:
[source,js]
--------------------------------------------------
DELETE /_security/api_key
Add support for API keys to access Elasticsearch (#38291) X-Pack security supports built-in authentication service `token-service` that allows access tokens to be used to access Elasticsearch without using Basic authentication. The tokens are generated by `token-service` based on OAuth2 spec. The access token is a short-lived token (defaults to 20m) and refresh token with a lifetime of 24 hours, making them unsuitable for long-lived or recurring tasks where the system might go offline thereby failing refresh of tokens. This commit introduces a built-in authentication service `api-key-service` that adds support for long-lived tokens aka API keys to access Elasticsearch. The `api-key-service` is consulted after `token-service` in the authentication chain. By default, if TLS is enabled then `api-key-service` is also enabled. The service can be disabled using the configuration setting. The API keys:- - by default do not have an expiration but expiration can be configured where the API keys need to be expired after a certain amount of time. - when generated will keep authentication information of the user that generated them. - can be defined with a role describing the privileges for accessing Elasticsearch and will be limited by the role of the user that generated them - can be invalidated via invalidation API - information can be retrieved via a get API - that have been expired or invalidated will be retained for 1 week before being deleted. The expired API keys remover task handles this. Following are the API key management APIs:- 1. Create API Key - `PUT/POST /_security/api_key` 2. Get API key(s) - `GET /_security/api_key` 3. Invalidate API Key(s) `DELETE /_security/api_key` The API keys can be used to access Elasticsearch using `Authorization` header, where the auth scheme is `ApiKey` and the credentials, is the base64 encoding of API key Id and API key separated by a colon. Example:- ``` curl -H "Authorization: ApiKey YXBpLWtleS1pZDphcGkta2V5" http://localhost:9200/_cluster/health ``` Closes #34383
2019-02-04 22:21:57 -05:00
{
"username" : "myuser"
}
--------------------------------------------------
// NOTCONSOLE
Finally, the following example invalidates all API keys for the user `myuser` in
the `native1` realm immediately:
[source,js]
--------------------------------------------------
DELETE /_security/api_key
Add support for API keys to access Elasticsearch (#38291) X-Pack security supports built-in authentication service `token-service` that allows access tokens to be used to access Elasticsearch without using Basic authentication. The tokens are generated by `token-service` based on OAuth2 spec. The access token is a short-lived token (defaults to 20m) and refresh token with a lifetime of 24 hours, making them unsuitable for long-lived or recurring tasks where the system might go offline thereby failing refresh of tokens. This commit introduces a built-in authentication service `api-key-service` that adds support for long-lived tokens aka API keys to access Elasticsearch. The `api-key-service` is consulted after `token-service` in the authentication chain. By default, if TLS is enabled then `api-key-service` is also enabled. The service can be disabled using the configuration setting. The API keys:- - by default do not have an expiration but expiration can be configured where the API keys need to be expired after a certain amount of time. - when generated will keep authentication information of the user that generated them. - can be defined with a role describing the privileges for accessing Elasticsearch and will be limited by the role of the user that generated them - can be invalidated via invalidation API - information can be retrieved via a get API - that have been expired or invalidated will be retained for 1 week before being deleted. The expired API keys remover task handles this. Following are the API key management APIs:- 1. Create API Key - `PUT/POST /_security/api_key` 2. Get API key(s) - `GET /_security/api_key` 3. Invalidate API Key(s) `DELETE /_security/api_key` The API keys can be used to access Elasticsearch using `Authorization` header, where the auth scheme is `ApiKey` and the credentials, is the base64 encoding of API key Id and API key separated by a colon. Example:- ``` curl -H "Authorization: ApiKey YXBpLWtleS1pZDphcGkta2V5" http://localhost:9200/_cluster/health ``` Closes #34383
2019-02-04 22:21:57 -05:00
{
"username" : "myuser",
"realm_name" : "native1"
}
--------------------------------------------------
// NOTCONSOLE
A successful call returns a JSON structure that contains the ids of the API keys that were invalidated, the ids
of the API keys that had already been invalidated, and potentially a list of errors encountered while invalidating
specific api keys.
[source,js]
--------------------------------------------------
{
"invalidated_api_keys": [ <1>
"api-key-id-1"
],
"previously_invalidated_api_keys": [ <2>
"api-key-id-2",
"api-key-id-3"
],
"error_count": 2, <3>
"error_details": [ <4>
{
"type": "exception",
"reason": "error occurred while invalidating api keys",
"caused_by": {
"type": "illegal_argument_exception",
"reason": "invalid api key id"
}
},
{
"type": "exception",
"reason": "error occurred while invalidating api keys",
"caused_by": {
"type": "illegal_argument_exception",
"reason": "invalid api key id"
}
}
]
}
--------------------------------------------------
// NOTCONSOLE
<1> The ids of the API keys that were invalidated as part of this request.
<2> The ids of the API keys that were already invalidated.
<3> The number of errors that were encountered when invalidating the API keys.
<4> Details about these errors. This field is not present in the response when
`error_count` is 0.