77 lines
2.8 KiB
Plaintext
77 lines
2.8 KiB
Plaintext
[role="xpack"]
|
|
[[api-keys]]
|
|
=== API Keys
|
|
|
|
|
|
API keys enable you to create secondary credentials so that you can send
|
|
requests on behalf of a user. Secondary credentials have
|
|
the same or lower access rights.
|
|
|
|
For example, if you extract data from an {es} cluster on a daily
|
|
basis, you might create an API key tied to your credentials,
|
|
configure it with minimum access,
|
|
and then put the API credentials into a cron job.
|
|
Or, you might create API keys to automate ingestion of new data from
|
|
remote sources, without a live user interaction.
|
|
|
|
To manage API keys, open the main menu, then click *Stack Management > API Keys*.
|
|
|
|
[role="screenshot"]
|
|
image:images/api-keys.png["API Keys UI"]
|
|
|
|
[float]
|
|
[[api-keys-service]]
|
|
=== {es} API key service
|
|
|
|
The {es} API key service is automatically enabled when you configure
|
|
{ref}/configuring-tls.html#tls-http[TLS on the HTTP interface].
|
|
This ensures that clients are unable to send API keys in clear-text.
|
|
|
|
When HTTPS connections are not enabled between {kib} and {es},
|
|
you cannot create or manage API keys, and you get an error message.
|
|
For more information, see the
|
|
{ref}/security-api-create-api-key.html[{es} API key documentation],
|
|
or contact your system administrator.
|
|
|
|
[float]
|
|
[[api-keys-security-privileges]]
|
|
=== Security privileges
|
|
|
|
You must have the `manage_security`, `manage_api_key`, or the `manage_own_api_key`
|
|
cluster privileges to use API keys in {kib}. To manage roles, open the main menu, then click
|
|
*Stack Management > Roles*, or use the <<role-management-api, {kib} Role Management API>>.
|
|
|
|
|
|
[float]
|
|
[[create-api-key]]
|
|
=== Create an API key
|
|
|
|
To create an API key, open the main menu, then click *Stack Management > API Keys > Create API key*.
|
|
|
|
[role="screenshot"]
|
|
image:images/create-api-key.png["Create API Key UI"]
|
|
|
|
Once created, you can copy the API key (Base64 encoded) and use it to send requests to {es} on your behalf. For example:
|
|
|
|
[source,bash]
|
|
curl --location --request GET 'http://localhost:5601/api/security/role' \
|
|
--header 'Content-Type: application/json;charset=UTF-8' \
|
|
--header 'kbn-xsrf: true' \
|
|
--header 'Authorization: ApiKey aVZlLUMzSUJuYndxdDJvN0k1bU46aGxlYUpNS2lTa2FKeVZua1FnY1VEdw==' \
|
|
|
|
[float]
|
|
[[view-api-keys]]
|
|
=== View and delete API keys
|
|
|
|
The *API Keys* feature in Kibana lists your API keys, including the name, date created, and status. If an API key expires, its status changes from `Active` to `Expired`.
|
|
|
|
If you have `manage_security` or `manage_api_key` permissions,
|
|
you can view the API keys of all users, and see which API key was
|
|
created by which user in which realm.
|
|
If you have only the `manage_own_api_key` permission, you see only a list of your own keys.
|
|
|
|
You can delete API keys individually or in bulk.
|
|
|
|
You cannot modify an API key. If you need additional privileges,
|
|
you must create a new key with the desired configuration and invalidate the old key.
|