Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Docs] Document Anonymous authentication provider. #84910

Merged
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
45 changes: 45 additions & 0 deletions docs/settings/security-settings.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -162,6 +162,51 @@ In addition to <<authentication-provider-settings,the settings that are valid fo

|===

[float]
[[anonymous-authentication-provider-settings]]
===== Anonymous authentication provider settings

In addition to <<authentication-provider-settings,the settings that are valid for all providers>>, you can specify the following settings:

[NOTE]
============
You can configure only one anonymous provider per {kib} instance.
============

[cols="2*<"]
|===
| `xpack.security.authc.providers.`
`anonymous.<provider-name>.credentials` {ess-icon}
| Credentials that {kib} should use internally to authenticate anonymous requests to {es}. Possible values are: username and password, API key, or the constant `elasticsearch_anonymous_user` if you want to leverage {ref}/anonymous-access.html[{es} anonymous access].

2+a| For example:

[source,yaml]
----------------------------------------
# Username and password credentials
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

note: not super happy about having technically invalid yaml snippet (because of duplicated entries), but couldn't think of a better option.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is reasonable. We could split this out into 4 different snippets if necessary, but I think what you have here is fine.

xpack.security.authc.providers.anonymous.anonymous1:
credentials:
username: "anonymous_service_account"
password: "anonymous_service_account_password"

# API key (concatenated and base64-encoded)
xpack.security.authc.providers.anonymous.anonymous1:
credentials:
apiKey: "VnVhQ2ZHY0JDZGJrUW0tZTVhT3g6dWkybHAyYXhUTm1zeWFrdzl0dk5udw=="

# API key (as returned from Elasticsearch API)
xpack.security.authc.providers.anonymous.anonymous1:
credentials:
apiKey.id: "VuaCfGcBCdbkQm-e5aOx"
apiKey.key: "ui2lp2axTNmsyakw9tvNnw"

# Elasticsearch anonymous access
xpack.security.authc.providers.anonymous.anonymous1:
credentials: "elasticsearch_anonymous_user"
----------------------------------------

|===

[float]
[[http-authentication-settings]]
===== HTTP authentication settings
Expand Down
106 changes: 106 additions & 0 deletions docs/user/security/authentication/index.asciidoc
Original file line number Diff line number Diff line change
Expand Up @@ -13,6 +13,7 @@
- <<saml>>
- <<oidc>>
- <<kerberos>>
- <<anonymous-authentication>>
- <<http-authentication>>

Enable multiple authentication mechanisms at the same time specifying a prioritized list of the authentication _providers_ (typically of various types) in the configuration. Providers are consulted in ascending order. Make sure each configured provider has a unique name (e.g. `basic1` or `saml1` in the configuration example) and `order` setting. In the event that two or more providers have the same name or `order`, {kib} will fail to start.
Expand Down Expand Up @@ -293,6 +294,111 @@ xpack.security.authc.providers:

Kibana uses SPNEGO, which wraps the Kerberos protocol for use with HTTP, extending it to web applications. At the end of the Kerberos handshake, Kibana will forward the service ticket to Elasticsearch. Elasticsearch will unpack it and it will respond with an access and refresh token which are then used for subsequent authentication.

[[anonymous-authentication]]
==== Anonymous authentication

[IMPORTANT]
============================================================================
Anyone with access to the network {kib} is exposed to will be able to access {kib}. Make sure that you've properly restricted the capabilities of the anonymous service account so that anonymous users can't perform destructive actions or escalate their own privileges.
============================================================================

Anonymous authentication gives users access to {kib} without requiring them to provide credentials. This can be useful if you want your users to skip the login step when you embed dashboards in another application or set up a demo {kib} instance in your internal network, while still keeping other security features intact.

To enable anonymous authentication in {kib}, you must decide what credentials the anonymous service account {kib} should use internally to authenticate anonymous requests.

NOTE: You can configure only one anonymous authentication provider per {kib} instance.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggest moving the sentence "There are three ways to specify these credentials" to after the Note.


There are three ways to specify these credentials:

If you have a user who can authenticate to {es} using username and password, for instance from the Native or LDAP security realms, you can also use these credentials to impersonate the anonymous users. Here is how your `kibana.yml` might look if you use username and password credentials:

[source,yaml]
-----------------------------------------------
xpack.security.authc.providers:
anonymous.anonymous1:
order: 0
credentials:
username: "anonymous_service_account"
password: "anonymous_service_account_password"
-----------------------------------------------

If using username and password credentials isn't desired or feasible, then you can create a dedicated <<api-keys, API key>> for the anonymous service account. In this case, your `kibana.yml` might look like this:

[source,yaml]
-----------------------------------------------
xpack.security.authc.providers:
anonymous.anonymous1:
order: 0
credentials:
apiKey: "VnVhQ2ZHY0JDZGJrUW0tZTVhT3g6dWkybHAyYXhUTm1zeWFrdzl0dk5udw=="
-----------------------------------------------

The previous configuration snippet uses an API key string that is the result of base64-encoding of the `id` and `api_key` fields returned from the {es} API, joined by a colon. You can also specify these fields separately, and {kib} will do the concatenation and base64-encoding for you:

[source,yaml]
-----------------------------------------------
xpack.security.authc.providers:
anonymous.anonymous1:
order: 0
credentials:
apiKey.id: "VuaCfGcBCdbkQm-e5aOx"
apiKey.key: "ui2lp2axTNmsyakw9tvNnw"
-----------------------------------------------

It's also possible to use {kib} anonymous access in conjunction with the {es} anonymous access.

Prior to configuring {kib}, ensure that anonymous access is enabled and properly configured in {es}. See {ref}/anonymous-access.html[Enabling anonymous access] for more information.

Here is how your `kibana.yml` might look like if you want to use {es} anonymous access to impersonate anonymous users in {kib}:

[source,yaml]
-----------------------------------------------
xpack.security.authc.providers:
anonymous.anonymous1:
order: 0
credentials: "elasticsearch_anonymous_user" <1>
-----------------------------------------------

<1> The `elasticsearch_anonymous_user` is a special constant that indicates you want to use the {es} anonymous user.

[float]
===== Anonymous access and other types of authentication

You can configure more authentication providers in addition to anonymous access in {kib}. In this case, the Login Selector presents a configurable *Continue as Guest* option for anonymous access:

[source,yaml]
--------------------------------------------------------------------------------
xpack.security.authc.providers:
basic.basic1:
order: 0
anonymous.anonymous1:
order: 1
credentials:
username: "anonymous_service_account"
password: "anonymous_service_account_password"
--------------------------------------------------------------------------------

[float]
===== Anonymous access and embedding

One of the most popular use cases for anonymous access is when you embed {kib} into other applications and don't want to force your users to log in to view it. If you configured {kib} to use anonymous access as the sole authentication mechanism, you don't need to do anything special while embedding {kib}.

If you have multiple authentication providers enabled, and you want to automatically log in anonymous users when embedding, then you will need to add the `auth_provider_hint=<anonymous-provider-name>` query string parameter to the {kib} URL that you're embedding.

For example, if you generate the iframe code to embed {kib}, it will look like this:

```html
<iframe src="https://localhost:5601/app/dashboards#/view/722b74f0-b882-11e8-a6d9-e546fe2bba5f?embed=true&_g=(....)" height="600" width="800"></iframe>
```

To make this iframe leverage anonymous access automatically, you will need to modify a link to {kib} in the `src` iframe attribute to look like this:

```html
<iframe src="https://localhost:5601/app/dashboards?auth_provider_hint=anonymous1#/view/722b74f0-b882-11e8-a6d9-e546fe2bba5f?embed=true&_g=(....)" height="600" width="800"></iframe>
```

Note that `auth_provider_hint` query string parameter goes *before* the hash URL fragment.

[[http-authentication]]
==== HTTP authentication

Expand Down