2019-02-04 22:21:57 -05:00
|
|
|
[role="xpack"]
|
|
|
|
[[security-api-create-api-key]]
|
2019-03-19 14:00:42 -04:00
|
|
|
=== Create API key API
|
2019-03-04 18:06:00 -05:00
|
|
|
++++
|
|
|
|
<titleabbrev>Create API keys</titleabbrev>
|
|
|
|
++++
|
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.
|
|
|
|
|
2019-03-19 14:00:42 -04:00
|
|
|
A successful create API key API call returns a JSON structure that contains the
|
|
|
|
API key, its unique id, and its name. If applicable, it also returns expiration
|
|
|
|
information for the API key in milliseconds.
|
2019-02-04 22:21:57 -05:00
|
|
|
|
2019-03-19 14:00:42 -04:00
|
|
|
NOTE: By default, API keys never expire. You can specify expiration information
|
|
|
|
when you create the API keys.
|
2019-02-04 22:21:57 -05:00
|
|
|
|
2019-03-19 14:00:42 -04:00
|
|
|
See <<api-key-service-settings>> for configuration settings related to API key
|
|
|
|
service.
|
2019-02-06 04:58:22 -05:00
|
|
|
|
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.
|
|
|
|
|
2019-06-26 00:30:51 -04:00
|
|
|
`role_descriptors` (optional)::
|
2019-03-19 14:00:42 -04:00
|
|
|
(array-of-role-descriptor) An array of role descriptors for this API key. This
|
2019-06-26 00:30:51 -04:00
|
|
|
parameter is optional. When it is not specified or is an empty array, then the API key will have
|
|
|
|
the permissions of the authenticated user. If you supply role descriptors, they must
|
|
|
|
be a subset of the authenticated user's permissions. The structure of role descriptor is the
|
2019-03-19 14:00:42 -04:00
|
|
|
same as the request for create role API. For more details, see
|
|
|
|
<<security-api-roles,role management APIs>>.
|
2019-02-04 22:21:57 -05:00
|
|
|
|
|
|
|
`expiration`::
|
2019-03-19 14:00:42 -04:00
|
|
|
(string) Optional expiration time for the API key. By default, API keys never expire.
|
2019-02-04 22:21:57 -05:00
|
|
|
|
2019-07-02 23:51:44 -04:00
|
|
|
==== Authorization
|
|
|
|
|
|
|
|
To use this API, you must have at least the `manage_api_key` cluster privilege.
|
|
|
|
|
2019-02-04 22:21:57 -05:00
|
|
|
==== 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
|
2019-02-06 04:58:22 -05:00
|
|
|
|
|
|
|
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
|