[DOCS] Adds docs for API Keys UI (#49135) (#49415)

* [DOCS] Adds docs for API Keys UI

* [DOCS] Incorporates review comments into API keys doc

* [DOCS] Fixes typo
This commit is contained in:
gchaps 2019-10-25 14:43:36 -07:00 committed by GitHub
parent d23f7f6b2f
commit 5defcc3dd5
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
4 changed files with 88 additions and 0 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 126 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 109 KiB

View file

@ -0,0 +1,86 @@
[role="xpack"]
[[api-keys]]
=== API Keys
API keys enable you to create secondary credentials so that you can send
requests on behalf of the 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.
You can create API keys from the {kib} Console. To view and invalidate
API keys, use *Management > Security > API Keys*.
[role="screenshot"]
image:user/security/api-keys/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}. You can manage roles in
*Management > Security > Roles*, or use the <<role-management-api, {kib} Role Management API>>.
[float]
[[create-api-key]]
=== Create an API key
You can {ref}/security-api-create-api-key.html[create an API key] from
the Kibana Console. For example:
[source,js]
POST /_security/api_key
{
"name": "my_api_key",
"expiration": "1d"
}
This creates an API key with the name `my_api_key` that
expires after one day. API key names must be globally unique.
An expiration date is optional and follows {ref}/common-options.html#time-units[{es} time unit format].
When an expiration is not provided, the API key does not expire.
[float]
[[view-api-keys]]
=== View and invalidate API keys
The *API Keys* UI lists your API keys, including the name, date created,
and expiration date. 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 invalidate API keys individually or in bulk.
Invalidated keys are deleted in batch after seven days.
[role="screenshot"]
image:user/security/api-keys/images/api-key-invalidate.png["API Keys invalidate"]
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.

View file

@ -36,3 +36,5 @@ cause Kibana's authorization to behave unexpectedly.
include::authorization/index.asciidoc[]
include::authorization/kibana-privileges.asciidoc[]
include::api-keys/index.asciidoc[]