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

115 lines
3.7 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-create-api-key]]
=== Create API Key API
2019-03-04 18:06:00 -05:00
++++
<titleabbrev>Create API keys</titleabbrev>
++++
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
Creates an API key for access without requiring basic authentication.
==== Request
`POST /_security/api_key`
`PUT /_security/api_key`
==== Description
The API keys are created by the {es} API key service, which is automatically enabled
when you configure TLS on the HTTP interface. See <<tls-http>>. Alternatively,
you can explicitly enable the `xpack.security.authc.api_key.enabled` setting. When
you are running in production mode, a bootstrap check prevents you from enabling
the API key service unless you also enable TLS on the HTTP interface.
A successful create API key API call returns a JSON structure that contains
the unique id, the name to identify API key, the API key and the expiration if
applicable for the API key in milliseconds.
NOTE: By default API keys never expire. You can specify expiration at the time of
creation for the API keys.
See <<api-key-service-settings>> for configuration settings related to API key service.
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
==== Request Body
The following parameters can be specified in the body of a POST or PUT request:
`name`::
(string) Specifies the name for this API key.
`role_descriptors`::
(array-of-role-descriptor) Optional array of role descriptor for this API key. The role descriptor
must be a subset of permissions of the authenticated user. The structure of role
descriptor is same as the request for create role API. For more details on role
see <<security-api-roles, Role Management APIs>>.
If the role descriptors are not provided then permissions of the authenticated user are applied.
`expiration`::
(string) Optional expiration time for the API key. By default API keys never expire.
==== Examples
The following example creates an API key:
[source, js]
------------------------------------------------------------
POST /_security/api_key
{
"name": "my-api-key",
"expiration": "1d", <1>
"role_descriptors": { <2>
"role-a": {
"cluster": ["all"],
"index": [
{
"names": ["index-a*"],
"privileges": ["read"]
}
]
},
"role-b": {
"cluster": ["all"],
"index": [
{
"names": ["index-b*"],
"privileges": ["all"]
}
]
}
}
}
------------------------------------------------------------
// CONSOLE
<1> optional expiration for the API key being generated. If expiration is not
provided then the API keys do not expire.
<2> optional role descriptors for this API key, if not provided then permissions
of authenticated user are applied.
A successful call returns a JSON structure that provides
API key information.
[source,js]
--------------------------------------------------
{
"id":"VuaCfGcBCdbkQm-e5aOx", <1>
"name":"my-api-key",
"expiration":1544068612110, <2>
"api_key":"ui2lp2axTNmsyakw9tvNnw" <3>
}
--------------------------------------------------
// TESTRESPONSE[s/VuaCfGcBCdbkQm-e5aOx/$body.id/]
// TESTRESPONSE[s/1544068612110/$body.expiration/]
// TESTRESPONSE[s/ui2lp2axTNmsyakw9tvNnw/$body.api_key/]
<1> unique id for this API key
<2> optional expiration in milliseconds for this API key
<3> generated API key
The API key returned by this API can then be used by sending a request with a
`Authorization` header with a value having the prefix `ApiKey ` followed
by the _credentials_, where _credentials_ is the base64 encoding of `id` and `api_key` joined by a colon.
[source,shell]
--------------------------------------------------
curl -H "Authorization: ApiKey VnVhQ2ZHY0JDZGJrUW0tZTVhT3g6dWkybHAyYXhUTm1zeWFrdzl0dk5udw==" http://localhost:9200/_cluster/health
--------------------------------------------------
// NOTCONSOLE