diff --git a/deploy-manage/deploy/self-managed/configure.md b/deploy-manage/deploy/self-managed/configure.md index 54ef1b25ed..197e14fdb4 100644 --- a/deploy-manage/deploy/self-managed/configure.md +++ b/deploy-manage/deploy/self-managed/configure.md @@ -102,7 +102,7 @@ $$$elasticsearch-pingTimeout$$$ `elasticsearch.pingTimeout` : Time in milliseconds to wait for {{es}} to respond to pings. **Default: the value of the [`elasticsearch.requestTimeout`](#elasticsearch-requestTimeout) setting** $$$elasticsearch-requestHeadersWhitelist$$$ `elasticsearch.requestHeadersWhitelist` -: List of {{kib}} client-side headers to send to {{es}}. To send **no** client-side headers, set this value to [] (an empty list). Removing the `authorization` header from being whitelisted means that you cannot use [basic authentication](../../users-roles/cluster-or-deployment-auth/user-authentication.md#basic-authentication) in {{kib}}. **Default: `[ 'authorization', 'es-client-authentication' ]`** +: List of {{kib}} client-side headers to send to {{es}}. To send **no** client-side headers, set this value to [] (an empty list). Removing the `authorization` header from being whitelisted means that you cannot use [basic authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md) in {{kib}}. **Default: `[ 'authorization', 'es-client-authentication' ]`** $$$elasticsearch-requestTimeout$$$ `elasticsearch.requestTimeout` : Time in milliseconds to wait for responses from the back end or {{es}}. This value must be a positive integer. **Default: `30000`** @@ -524,4 +524,4 @@ $$$settings-explore-data-in-chart$$$ `xpack.discoverEnhanced.actions.exploreData : Set this value to false to disable the Upgrade Assistant UI. **Default: true** `i18n.locale` ![logo cloud](https://doc-icons.s3.us-east-2.amazonaws.com/logo_cloud.svg "Supported on {{ess}}") -: Set this value to change the {{kib}} interface language. Valid locales are: `en`, `zh-CN`, `ja-JP`, `fr-FR`. **Default: `en`** +: Set this value to change the {{kib}} interface language. Valid locales are: `en`, `zh-CN`, `ja-JP`, `fr-FR`. **Default: `en`** \ No newline at end of file diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml index e869e0adda..34d6149e9a 100644 --- a/deploy-manage/toc.yml +++ b/deploy-manage/toc.yml @@ -637,10 +637,9 @@ toc: - file: users-roles/cluster-or-deployment-auth/pki.md - file: users-roles/cluster-or-deployment-auth/custom.md - file: users-roles/cluster-or-deployment-auth/built-in-users.md - - file: users-roles/cluster-or-deployment-auth/user-profiles.md + - file: users-roles/cluster-or-deployment-auth/kibana-authentication.md - file: users-roles/cluster-or-deployment-auth/access-agreement.md - file: users-roles/cluster-or-deployment-auth/anonymous-access.md - - file: users-roles/cluster-or-deployment-auth/manage-authentication-for-multiple-clusters.md - file: users-roles/cluster-or-deployment-auth/token-based-authentication-services.md - file: users-roles/cluster-or-deployment-auth/service-accounts.md - file: users-roles/cluster-or-deployment-auth/internal-users.md @@ -649,8 +648,10 @@ toc: - file: users-roles/cluster-or-deployment-auth/configure-operator-privileges.md - file: users-roles/cluster-or-deployment-auth/operator-only-functionality.md - file: users-roles/cluster-or-deployment-auth/operator-privileges-for-snapshot-restore.md + - file: users-roles/cluster-or-deployment-auth/user-profiles.md - file: users-roles/cluster-or-deployment-auth/looking-up-users-without-authentication.md - file: users-roles/cluster-or-deployment-auth/controlling-user-cache.md + - file: users-roles/cluster-or-deployment-auth/manage-authentication-for-multiple-clusters.md - file: users-roles/cluster-or-deployment-auth/user-roles.md children: - file: users-roles/cluster-or-deployment-auth/defining-roles.md diff --git a/deploy-manage/users-roles/_snippets/external-realms.md b/deploy-manage/users-roles/_snippets/external-realms.md new file mode 100644 index 0000000000..ab1876a1e9 --- /dev/null +++ b/deploy-manage/users-roles/_snippets/external-realms.md @@ -0,0 +1,20 @@ +ldap +: Uses an external LDAP server to authenticate the users. This realm supports an authentication token in the form of username and password, and requires explicit configuration in order to be used. See [LDAP user authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/ldap.md). + +active_directory +: Uses an external Active Directory Server to authenticate the users. With this realm, users are authenticated by usernames and passwords. See [Active Directory user authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/active-directory.md). + +pki +: Authenticates users using Public Key Infrastructure (PKI). This realm works in conjunction with SSL/TLS and identifies the users through the Distinguished Name (DN) of the client’s X.509 certificates. See [PKI user authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/pki.md). + +saml +: Facilitates authentication using the SAML 2.0 Web SSO protocol. This realm is designed to support authentication through {{kib}} and is not intended for use in the REST API. See [SAML authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/saml.md). + +kerberos +: Authenticates a user using Kerberos authentication. Users are authenticated on the basis of Kerberos tickets. See [Kerberos authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/kerberos.md). + +oidc +: Facilitates authentication using OpenID Connect. It enables {{es}} to serve as an OpenID Connect Relying Party (RP) and provide single sign-on (SSO) support in {{kib}}. See [Configuring single sign-on to the {{stack}} using OpenID Connect](/deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md). + +jwt +: Facilitates using JWT identity tokens as authentication bearer tokens. Compatible tokens are OpenID Connect ID Tokens, or custom JWTs containing the same claims. See [JWT authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/jwt.md). \ No newline at end of file diff --git a/deploy-manage/users-roles/_snippets/internal-realms.md b/deploy-manage/users-roles/_snippets/internal-realms.md new file mode 100644 index 0000000000..438477b25c --- /dev/null +++ b/deploy-manage/users-roles/_snippets/internal-realms.md @@ -0,0 +1,5 @@ +native +: Users are stored in a dedicated {{es}} index. This realm supports an authentication token in the form of username and password, and is available by default when no realms are explicitly configured. Users are managed through {{kib}}, or using [user management APIs](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-security). See [Native user authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/native.md). + +file +: Users are defined in files stored on each node in the {{es}} cluster. This realm supports an authentication token in the form of username and password and is always available. See [File-based user authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/file-based.md). Available for {{eck}} and self-managed deployments only. \ No newline at end of file diff --git a/deploy-manage/users-roles/cloud-enterprise-orchestrator/active-directory.md b/deploy-manage/users-roles/cloud-enterprise-orchestrator/active-directory.md index d688c3c2e0..5695634052 100644 --- a/deploy-manage/users-roles/cloud-enterprise-orchestrator/active-directory.md +++ b/deploy-manage/users-roles/cloud-enterprise-orchestrator/active-directory.md @@ -1,22 +1,26 @@ --- mapped_pages: - https://www.elastic.co/guide/en/cloud-enterprise/current/ece-create-ad-profiles.html +applies: + ece: all --- # Active Directory [ece-create-ad-profiles] -If you use an Active Directory (AD) server to authenticate users, you can specify the servers, parameters, and the search modes that Elastic Cloud Enterprise uses to locate user credentials. There are several sections to the profile: +If you use an Active Directory (AD) server to authenticate users, you can specify the servers, parameters, and the search modes that {{ece}} uses to locate user credentials. To set up Active Directory authentication, perform the following steps: -* Specify the [general AD settings](#ece-ad-general-settings). -* Optional: Prepare the [trusted CA certificates](#ece-prepare-ad-certificates). -* Supply the [bind credentials](#ece-supply-ad-bind-credentials). -* Select the [search mode and group search](#ece-ad-search-mode) settings. -* Create [role mappings](#ece-ad-role-mapping), either to all users that match the profile or assign roles to specific groups. -* Add any [custom configuration](#ece-ad-custom-configuration) advanced settings to the YAML file. +1. Specify the [general AD settings](#ece-ad-general-settings). +2. Optional: Prepare the [trusted CA certificates](#ece-prepare-ad-certificates). +3. Supply the [bind credentials](#ece-supply-ad-bind-credentials). +4. Select the [search mode and group search](#ece-ad-search-mode) settings. +5. Create [role mappings](#ece-ad-role-mapping), either to all users that match the profile or assign roles to specific groups. +6. Add any [custom configuration](#ece-ad-custom-configuration) advanced settings to the YAML file. -$$$ece-ad-general-settings$$$Begin the provider profile by adding the general settings: +## Add the general settings [ece-ad-general-settings] -1. [Log into the Cloud UI](../../deploy/cloud-enterprise/log-into-cloud-ui.md). +Begin the provider profile by adding the general settings: + +1. [Log into the Cloud UI](/deploy-manage/deploy/cloud-enterprise/log-into-cloud-ui.md). 2. Go to **Users** and then **Authentication providers**. 3. From the **Add provider** drop-down menu, select **Active Directory**. 4. Provide a unique profile name. This name becomes the realm ID, with any spaces replaced by hyphens. @@ -44,16 +48,16 @@ $$$ece-ad-general-settings$$$Begin the provider profile by adding the general se 7. Provide the top-level domain name. -## Prepare certificates [ece-prepare-ad-certificates] +## Prepare certificates (optional)[ece-prepare-ad-certificates] -Though optional, you can add one or more certificate authorities (CAs) to validate the server certificate that the Domain Controller uses for SSL/TLS. Connecting through SSL/TLS ensures that the identity of the AD server is authenticated before Elastic Cloud Enterprise transmits the user credentials and that the contents of the connection are encrypted. +You can add one or more certificate authorities (CAs) to validate the server certificate that the domain controller uses for SSL/TLS. Connecting through SSL/TLS ensures that the identity of the Active Directory server is authenticated before {{ece}} transmits the user credentials and that the contents of the connection are encrypted. 1. Provide the URL to the ZIP file that contains a keystore with the CA certificate(s). The bundle should be a ZIP file containing a single `keystore.ks` file in the directory `/active_directory/:id/truststore`, where `:id` is the value of the **Realm ID** field created in the [General settings](#ece-ad-general-settings). The keystore file can either be a JKS or a PKCS#12 keystore, but the name of the file should be `keystore.ks`. ::::{important} - Don’t use the same URL to serve a new version of the ZIP file as otherwise the new version may not be picked up. + Don’t use the same URL to serve a new version of the ZIP file. If you do, the new version might not be picked up. :::: 2. Select a keystore type. @@ -62,12 +66,16 @@ Though optional, you can add one or more certificate authorities (CAs) to valida ## Supply the bind credentials [ece-supply-ad-bind-credentials] -You can either select **Bind anonymously** for user searches or you must specify the distinguished name (DN) of the user to bind and the bind password. When **Bind anonymously** is selected, all requests to Active Directory will be performed with the credentials of the authenticating user. In the case that `Bind DN` and `Bind Password` are provided, requests are performed on behalf of this bind user. This can be useful in cases where the regular users can’t access all of the necessary items within Active Directory. +You can either select **Bind anonymously** for user searches, or you must specify the distinguished name (DN) of the user to bind and the bind password. + +When **Bind anonymously** is selected, all requests to Active Directory will be performed with the credentials of the authenticating user. + +In the case that `Bind DN` and `Bind Password` are provided, requests are performed on behalf of this bind user. This can be useful in cases where the regular users can’t access all of the necessary items within Active Directory. ## Configure the user search settings [ece-ad-search-mode] -You can configure how Elastic Cloud Enterprise will search for users in the Active Directory +You can configure how {{ece}} will search for users in the Active Directory To configure the user search: @@ -75,7 +83,7 @@ To configure the user search: 2. Set the **Search scope**: Sub-tree - : Searches all entries at all levels *under* the base DN, including the base DN itself. + : Searches all entries at all levels under the base DN, including the base DN itself. One level : Searches for objects one level under the `Base DN` but not the `Base DN` or entries in lower levels. @@ -88,7 +96,7 @@ To configure the user search: ## Configure the group search settings [ece-ad-search-groups] -You can configure how Elastic Cloud Enterprise will search for groups in the Active Directory +You can configure how {{ece}} will search for groups in Active Directory. To configure the group search: @@ -96,7 +104,7 @@ To configure the group search: 2. Set the **Search scope**: Sub-tree - : Searches all entries at all levels *under* the base DN, including the base DN itself. + : Searches all entries at all levels under the base DN, including the base DN itself. One level : Searches for objects one level under the `Base DN` but not the `Base DN` or entries in lower levels. @@ -108,19 +116,25 @@ To configure the group search: ## Create role mappings [ece-ad-role-mapping] -When a user is authenticated, the role mapping assigns them roles in Elastic Cloud Enterprise. +When a user is authenticated, the role mapping assigns them roles in {{ece}}. To assign all authenticated users a single role, select one of the **Default roles**. To assign roles according to the **User DN** of the user or **Group DN** of the group they belong to, use the **Add role mapping rule** fields. +For a list of roles, refer to [Available roles and permissions](/deploy-manage/users-roles/cloud-enterprise-orchestrator/manage-users-roles.md#ece-user-role-permissions). + ## Custom configuration [ece-ad-custom-configuration] -You can add any additional settings to the **Advanced configuration** YAML file. For example, if you need to ignore the SSL check for the SSL certificate of the Domain Controller in a testing environment, you might add `ssl.verification_mode: none`. Note that all keys should omit the `xpack.security.authc.realms.active_directory.$realm_id` prefix that is required in `elasticsearch.yml`, as ECE will insert this itself and automatically account for any differences in format across Elasticsearch versions. +You can add any additional settings to the **Advanced configuration** YAML file. For example, if you need to ignore the SSL check for the SSL certificate of the domain controller in a testing environment, you might add `ssl.verification_mode: none`. + +:::{note} +All entries added should omit the `xpack.security.authc.realms.ldap.$realm_id` prefix, as ECE will insert this itself and automatically account for any differences in format across {{es}} versions. +::: ::::{important} -API keys created by Active Directory users are not automatically deleted or disabled when the user is deleted or disabled in Active Directory. When you delete a user in Active Directory, make sure to also remove the user’s API key or delete the user in ECE. +API keys created by Active Directory users are not automatically deleted or disabled when the user is deleted or disabled in Active Directory. When you delete a user in Active Directory, make sure to also remove the user’s API key or delete the user in {{ece}}. :::: diff --git a/deploy-manage/users-roles/cloud-enterprise-orchestrator/configure-sso-for-deployments.md b/deploy-manage/users-roles/cloud-enterprise-orchestrator/configure-sso-for-deployments.md index d96cb32a87..6f5be9f8bf 100644 --- a/deploy-manage/users-roles/cloud-enterprise-orchestrator/configure-sso-for-deployments.md +++ b/deploy-manage/users-roles/cloud-enterprise-orchestrator/configure-sso-for-deployments.md @@ -1,16 +1,18 @@ --- mapped_pages: - https://www.elastic.co/guide/en/cloud-enterprise/current/ece-deployment-sso.html +applies: + ece: all --- # Configure SSO for deployments [ece-deployment-sso] -The single sign-on (SSO) feature in ECE allows `platform admins` and `deployment managers` to log in to their Kibana instances automatically once they are logged in to ECE. +The single sign-on (SSO) feature in ECE allows `platform admins` and `deployment managers` to log in to their {{kib}} instances automatically after they are logged in to ECE. ::::{note} Single sign-on is not available for system deployments; you need to use credentials to log in to them. :::: -To use single sign-on you first need to [configure the API base URL](../../deploy/cloud-enterprise/change-ece-api-url.md). Once this is set, all new deployments are SSO-enabled automatically, and existing deployments become SSO-enabled after any plan changes are applied. +To use single sign-on, you first need to [configure the API base URL](/deploy-manage/deploy/cloud-enterprise/change-ece-api-url.md). After this is set, all new deployments are SSO-enabled automatically, and existing deployments become SSO-enabled after any plan changes are applied. diff --git a/deploy-manage/users-roles/cloud-enterprise-orchestrator/ldap.md b/deploy-manage/users-roles/cloud-enterprise-orchestrator/ldap.md index 3524bed3c8..011cc7246a 100644 --- a/deploy-manage/users-roles/cloud-enterprise-orchestrator/ldap.md +++ b/deploy-manage/users-roles/cloud-enterprise-orchestrator/ldap.md @@ -1,22 +1,26 @@ --- mapped_pages: - https://www.elastic.co/guide/en/cloud-enterprise/current/ece-create-ldap-profiles.html +applies: + ece: all --- # LDAP [ece-create-ldap-profiles] -If you use a Lightweight Directory Access Protocol (LDAP) server to authenticate users, you can specify the servers, parameters, and the search modes that Elastic Cloud Enterprise uses to locate user credentials. There are several sections to the profile: +If you use a Lightweight Directory Access Protocol (LDAP) server to authenticate users, you can specify the servers, parameters, and the search modes that {{ece}} uses to locate user credentials. To set up LDAP authentication, perform the following steps: -* Specify the [general LDAP settings](#ece-ldap-general-settings). -* Optional: Prepare the [trusted CA certificates](#ece-prepare-ldap-certificates). -* Supply the [bind credentials](#ece-supply-ldap-bind-credentials). -* Select the [search mode and group search](#ece-ldap-search-mode) settings. -* Create [role mappings](#ece-ldap-role-mapping), either to all users that match the profile or assign roles to specific groups. -* Add any [custom configuration](#ece-ldap-custom-configuration) advanced settings to the YAML file. +1. Specify the [general LDAP settings](#ece-ldap-general-settings). +2. Optional: Prepare the [trusted CA certificates](#ece-prepare-ldap-certificates). +3. Supply the [bind credentials](#ece-supply-ldap-bind-credentials). +4. Select the [search mode and group search](#ece-ldap-search-mode) settings. +5. Create [role mappings](#ece-ldap-role-mapping), either to all users that match the profile, or assign roles to specific groups. +6. Add any [custom configuration](#ece-ldap-custom-configuration) advanced settings to the YAML file. -$$$ece-ldap-general-settings$$$Begin the provider profile by adding the general settings: +## Add the general settings [ece-ldap-general-settings] -1. [Log into the Cloud UI](../../deploy/cloud-enterprise/log-into-cloud-ui.md). +Begin the provider profile by adding the general settings: + +1. [Log into the Cloud UI](/deploy-manage/deploy/cloud-enterprise/log-into-cloud-ui.md). 2. Go to **Users** and then **Authentication providers**. 3. From the **Add provider** drop-down menu, select **LDAP**. 4. Provide a unique profile name. This name becomes the realm ID, with any spaces replaced by hyphens. @@ -43,9 +47,9 @@ $$$ece-ldap-general-settings$$$Begin the provider profile by adding the general -## Prepare certificates [ece-prepare-ldap-certificates] +## Prepare certificates (optional)[ece-prepare-ldap-certificates] -Though optional, you can add one or more certificate authorities (CAs) to validate the server certificate that the Domain Controller uses for SSL/TLS. Connecting through SSL/TLS ensures that the identity of the AD server is authenticated before Elastic Cloud Enterprise transmits the user credentials and that the contents of the connection are encrypted. +You can add one or more certificate authorities (CAs) to validate the server certificate that the Domain Controller uses for SSL/TLS. Connecting through SSL/TLS ensures that the identity of the AD server is authenticated before {{ece}} transmits the user credentials and that the contents of the connection are encrypted. 1. Provide the URL to the ZIP file that contains a keystore with the CA certificate(s). @@ -91,7 +95,7 @@ To configure the template search: ## Configure the group search settings [ece-ldap-search-groups] -You can configure how Elastic Cloud Enterprise searches for groups in the LDAP Server +You can configure how {{ece}} searches for groups in the LDAP Server. To configure the group search: @@ -111,16 +115,22 @@ To configure the group search: ## Create role mappings [ece-ldap-role-mapping] -When a user is authenticated, the role mapping assigns them roles in Elastic Cloud Enterprise. +When a user is authenticated, the role mapping assigns them roles in {{ece}}. To assign all authenticated users a single role, select one of the **Default roles**. To assign roles according to the **User DN** of the user or **Group DN** of the group they belong to, use the **Add role mapping rule** fields. +For a list of roles, refer to [Available roles and permissions](/deploy-manage/users-roles/cloud-enterprise-orchestrator/manage-users-roles.md#ece-user-role-permissions). + ## Custom configuration [ece-ldap-custom-configuration] -You can add any additional settings to the **Advanced configuration** YAML file. For example, if you need to ignore the SSL check in a testing environment, you might add `ssl.verification_mode: none`. Note that all entries added should omit `xpack.security.authc.realms.ldap.$realm_id` prefix, as ECE will insert this itself and automatically account for any differences in format across Elasticsearch versions. +You can add any additional settings to the **Advanced configuration** YAML file. For example, if you need to ignore the SSL check in a testing environment, you might add `ssl.verification_mode: none`. + +:::{note} +All entries added should omit the `xpack.security.authc.realms.ldap.$realm_id` prefix, as ECE will insert this itself and automatically account for any differences in format across {{es}} versions. +::: ::::{important} API keys created by LDAP users are not automatically deleted or disabled when the user is deleted or disabled in LDAP. When you delete a user in LDAP, make sure to also remove the user’s API key or delete the user in ECE. diff --git a/deploy-manage/users-roles/cloud-enterprise-orchestrator/manage-system-passwords.md b/deploy-manage/users-roles/cloud-enterprise-orchestrator/manage-system-passwords.md index 71a47a1825..8d6a77b1fc 100644 --- a/deploy-manage/users-roles/cloud-enterprise-orchestrator/manage-system-passwords.md +++ b/deploy-manage/users-roles/cloud-enterprise-orchestrator/manage-system-passwords.md @@ -1,11 +1,13 @@ --- mapped_pages: - https://www.elastic.co/guide/en/cloud-enterprise/current/ece-manage-system-passwords.html +applies: + ece: all --- -# Manage system passwords [ece-manage-system-passwords] +# Manage system passwords[ece-manage-system-passwords] -At the end of the Elastic Cloud Enterprise installation process on the first host, you are provided with the URL and user credentials for the administration console users `admin` and `readonly`. You use this information to log into the Cloud UI. Both users can access all parts of the Cloud UI, but only the `admin` user can make changes. We recommend that you keep this information secure. +At the end of the {{ece}} installation process on the first host, you are provided with the URL and user credentials for the administration console users `admin` and `readonly`. You use this information to log into the Cloud UI. Both users can access all parts of the Cloud UI, but only the `admin` user can make changes. We recommend that you keep this information secure. ## Retrieve user passwords [ece-retrieve-passwords] @@ -33,7 +35,7 @@ You access the Cloud UI on port 12400 or port 12443 at IP address of the first You might need to reset the Cloud UI passwords for one of the following reasons: -* To change the passwords for the `admin` and `readonly` users after installing Elastic Cloud Enterprise or periodically as part of your standard operating procedures. +* To change the passwords for the `admin` and `readonly` users after installing {{ece}} or periodically as part of your standard operating procedures. * To reset passwords if you think they might have become compromised. The passwords for these users are stored in `/mnt/data/elastic/bootstrap-state/bootstrap-secrets.json` along with other secrets (unless you specified a different host storage path). diff --git a/deploy-manage/users-roles/cloud-enterprise-orchestrator/manage-users-roles.md b/deploy-manage/users-roles/cloud-enterprise-orchestrator/manage-users-roles.md index 5501d13d6f..e87e98e54e 100644 --- a/deploy-manage/users-roles/cloud-enterprise-orchestrator/manage-users-roles.md +++ b/deploy-manage/users-roles/cloud-enterprise-orchestrator/manage-users-roles.md @@ -1,15 +1,13 @@ --- mapped_pages: - https://www.elastic.co/guide/en/cloud-enterprise/current/ece-configure-rbac.html +applies: + ece: all --- # Manage users and roles [ece-configure-rbac] -:::{image} ../../../images/cloud-enterprise-ece-rbac-intro.png -:alt: User groups -::: - -Role-based access control (RBAC) provides a way to add multiple users and restrict their access to specific platform resources. In addition to the system `admin` and `readonly` users, you can utilize pre-built roles to control access to platform operations, deployment assets, or API calls. +Role-based access control (RBAC) provides a way to add multiple users and restrict their access to specific platform resources. In addition to the system `admin` and `readonly` users, you can create additional users and assign pre-built roles to control access to platform operations, deployment assets, or API calls. Implementing RBAC in your environment benefits you in several ways: @@ -19,19 +17,15 @@ Implementing RBAC in your environment benefits you in several ways: * Adds multiple users by: * Creating [native users](native-user-authentication.md) locally. - * Integrating with third-party authentication providers like [ActiveDirectory](active-directory.md), [LDAP](ldap.md) or [SAML](saml.md). - + * Integrating with third-party authentication providers like [Active Directory](active-directory.md), [LDAP](ldap.md) or [SAML](saml.md). ::::{important} -With RBAC, interacting with API endpoints now requires a [bearer token](https://www.elastic.co/guide/en/cloud-enterprise/current/ece-api-command-line.md) or [API key](../../api-keys/elastic-cloud-enterprise-api-keys.md#ece-api-keys). +With RBAC, interacting with API endpoints requires a [bearer token](https://www.elastic.co/guide/en/cloud-enterprise/current/ece-api-command-line.html) or [API key](/deploy-manage/api-keys/elastic-cloud-enterprise-api-keys.md#ece-api-keys). :::: - - ## Before you begin [ece_before_you_begin_8] -To prepare for RBAC, you should review the Elastic Cloud Enterprise [limitations and known issues](https://www.elastic.co/guide/en/cloud-enterprise/current/ece-limitations.md). - +To prepare for RBAC, you should review the {{ece}} [limitations and known issues](https://www.elastic.co/guide/en/cloud-enterprise/current/ece-limitations.html). ## Available roles and permissions [ece-user-role-permissions] @@ -50,30 +44,42 @@ Deployment viewer : Can view non-system deployments, including their activity. Can prepare the diagnostic bundle, inspect the files, and download the bundle as a ZIP file. -## Configure security deployment [ece-configure-security-deployment] +## Step 1: Configure the security deployment [ece-configure-security-deployment] -The security deployment is a system deployment that manages all of the Elastic Cloud Enterprise authentication and permissions. It is created automatically during installation. +The security deployment is a system deployment that manages all of the {{ece}} authentication and permissions. It is created automatically during installation. ::::{important} -We strongly recommend using three availability zones with at least 1 GB Elasticsearch nodes. You can scale up if you expect a heavy authentication workload. +We strongly recommend using three availability zones with at least 1 GB {{es}} nodes. You can scale up if you expect a heavy authentication workload. :::: -1. [Log into the Cloud UI](../../deploy/cloud-enterprise/log-into-cloud-ui.md). +1. [Log into the Cloud UI](/deploy-manage/deploy/cloud-enterprise/log-into-cloud-ui.md). 2. Go to **Deployments** a select the **security-cluster**. -3. Configure regular snapshots of the security deployment. This is critical if you plan to create any native users. -4. Optional: [Enable monitoring](../../monitor/stack-monitoring/ece-stack-monitoring.md) on the security deployment to a dedicated monitoring deployment. +3. Configure regular [snapshots](/deploy-manage/tools/snapshot-and-restore/create-snapshots.md) of the security deployment. This is critical if you plan to create any native users. +4. Optional: [Enable monitoring](/deploy-manage/monitor/stack-monitoring/ece-stack-monitoring.md) on the security deployment to a dedicated monitoring deployment. + +If you have authentication issues, you check out the security deployment {{es}} [logs](/deploy-manage/monitor/logging-configuration.md). + +## Step 2: Set up provider profiles + +Configure any third-party authentication providers that you want to use. + +If you want to use only [native user authentication](native-user-authentication.md), then no additional configuration is required. + +* [Active Directory](active-directory.md) +* [LDAP](ldap.md) +* [SAML](saml.md) -If you have authentication issues, you check out the security deployment Elasticsearch logs. +During setup, you can map users according to their properties to {{ece}} roles. -## Change the order of provider profiles [ece-provider-order] +## Step 3: Change the order of provider profiles [ece-provider-order] -Elastic Cloud Enterprise performs authentication checks against the configured providers, in order. When a match is found, the user search stops. The roles specified by that first profile match dictate which permissions the user is granted—​regardless of what permissions might be available in another, lower-order profile. +{{ece}} performs authentication checks against the configured providers, in order. When a match is found, the user search stops. The roles specified by that first profile match dictate which permissions the user is granted—​regardless of what permissions might be available in another, lower-order profile. To change the provider order: -1. [Log into the Cloud UI](../../deploy/cloud-enterprise/log-into-cloud-ui.md). +1. [Log into the Cloud UI](/deploy-manage/deploy/cloud-enterprise/log-into-cloud-ui.md). 2. Go to **Users** and then **Authentication providers**. 3. Use the carets to update the provider order. diff --git a/deploy-manage/users-roles/cloud-enterprise-orchestrator/native-user-authentication.md b/deploy-manage/users-roles/cloud-enterprise-orchestrator/native-user-authentication.md index 557730133e..cd7e77922c 100644 --- a/deploy-manage/users-roles/cloud-enterprise-orchestrator/native-user-authentication.md +++ b/deploy-manage/users-roles/cloud-enterprise-orchestrator/native-user-authentication.md @@ -1,16 +1,18 @@ --- mapped_pages: - https://www.elastic.co/guide/en/cloud-enterprise/current/ece-add-native-users.html +applies: + ece: all --- -# Native user authentication [ece-add-native-users] +# Native users [ece-add-native-users] -If you are adding a small number of users and don’t mind managing them manually, using the local *native* authentication might be the best fit for your team. +If you are adding a small number of users and don’t mind managing them manually, using native authentication might be the best fit for your team. -1. [Log into the Cloud UI](../../deploy/cloud-enterprise/log-into-cloud-ui.md). +1. [Log into the Cloud UI](/deploy-manage/deploy/cloud-enterprise/log-into-cloud-ui.md). 2. Go to **Users** and then **Native users**. 3. Select **Create user**. -4. Provide the user details, select the role, and set their password. +4. Provide the user details, select the [role](/deploy-manage/users-roles/cloud-enterprise-orchestrator/manage-users-roles.md#ece-user-role-permissions), and set their password. The password must be a minimum of eight characters. diff --git a/deploy-manage/users-roles/cloud-enterprise-orchestrator/saml.md b/deploy-manage/users-roles/cloud-enterprise-orchestrator/saml.md index 49a435a383..75fc035b3d 100644 --- a/deploy-manage/users-roles/cloud-enterprise-orchestrator/saml.md +++ b/deploy-manage/users-roles/cloud-enterprise-orchestrator/saml.md @@ -1,32 +1,36 @@ --- mapped_pages: - https://www.elastic.co/guide/en/cloud-enterprise/current/ece-create-saml-profiles.html +applies: + ece: all --- # SAML [ece-create-saml-profiles] -You can configure Elastic Cloud Enterprise to delegate authentication of users to a Security Assertion Markup Language (SAML) authentication provider. Elastic Cloud Enterprise supports the SAML 2.0 Web Browser Single Sign On Profile only and this requires the use of a web browser. Due to this, SAML profiles should not be used for standard API clients. The security deployment acts as a SAML 2.0 compliant *service provider*. +You can configure {{ece}} to delegate authentication of users to a Security Assertion Markup Language (SAML) authentication provider. {{ece}} supports the SAML 2.0 Web Browser Single Sign On Profile only, and this requires the use of a web browser. Due to this, SAML profiles should not be used for standard API clients. The security deployment acts as a SAML 2.0 compliant *service provider*. -There are several sections to the profile: +To set up SAML authentication, perform the following steps: -* Specify the [general SAML settings](#ece-saml-general-settings). -* Specify the necessary [attribute mappings](#ece-saml-attributes) -* Create [role mappings](#ece-saml-role-mapping), either to all users that match the profile or assign roles to specific attribute values. -* Add any [custom configuration](#ece-saml-custom-configuration) advanced settings to the YAML file. For example, if you need to ignore the SSL check for the SSL certificate of the Domain Controller in a testing environment, you might add `ssl.verification_mode: none`. Note that all entries added should omit `xpack.security.authc.realms.saml.$realm_id` prefix, as ECE will insert this itself and automatically account for any differences in format across Elasticsearch versions. -* Optional: Prepare the [trusted SSL certificate bundle](#ece-saml-ssl-certificates). -* Sign the [outgoing SAML messages](#ece-configure-saml-signing-certificates). -* [Encrypt SAML messages](#ece-encrypt-saml). +1. Specify the [general SAML settings](#ece-saml-general-settings). +2. Specify the necessary [attribute mappings](#ece-saml-attributes) +3. Create [role mappings](#ece-saml-role-mapping), either to all users that match the profile or assign roles to specific attribute values. +4. Add any [custom configuration](#ece-saml-custom-configuration) advanced settings to the YAML file. +5. Optional: Prepare the [trusted SSL certificate bundle](#ece-saml-ssl-certificates). +6. Sign the [outgoing SAML messages](#ece-configure-saml-signing-certificates). +7. [Encrypt SAML messages](#ece-encrypt-saml). -$$$ece-saml-general-settings$$$Begin the provider profile by adding the general settings: +## Add the general settings [ece-saml-general-settings] -1. [Log into the Cloud UI](../../deploy/cloud-enterprise/log-into-cloud-ui.md). +Begin the provider profile by adding the general settings: + +1. [Log into the Cloud UI](/deploy-manage/deploy/cloud-enterprise/log-into-cloud-ui.md). 2. Go to **Users** and then **Authentication providers**. 3. From the **Add provider** drop-down menu, select **SAML**. 4. Provide a unique profile name. This name becomes the realm ID, with any spaces replaced by hyphens. The name can be changed, but the realm ID cannot. The realm ID becomes part of the [certificate bundle](#ece-saml-ssl-certificates). -5. Enter the Assertion Consumer Service URL endpoint within Elastic Cloud Enterprise that receives the SAML assertion. +5. Enter the Assertion Consumer Service URL endpoint within {{ece}} that receives the SAML assertion. Example: `https://HOSTNAME_OR_IP_ADDRESS:12443/api/v1/users/auth/saml/_callback` @@ -38,7 +42,7 @@ $$$ece-saml-general-settings$$$Begin the provider profile by adding the general Example: `urn:example:idp` -8. Enter the URI for the SAML **service provider entity ID** that represents Elastic Cloud Enterprise. The only restriction is that this is a valid URI, but the common practice is to use the domain name where the Service Provider is available. +8. Enter the URI for the SAML **service provider entity ID** that represents {{ece}}. The only restriction is that this is a valid URI, but the common practice is to use the domain name where the Service Provider is available. Example: `http://SECURITY_DEPLOYMENT_IP:12443` @@ -48,21 +52,30 @@ $$$ece-saml-general-settings$$$Begin the provider profile by adding the general -## Map SAML attributes to User Properties [ece-saml-attributes] +## Map SAML attributes to user properties [ece-saml-attributes] + +The SAML assertion about a user usually includes attribute names and values that can be used for role mapping. The configuration in this section allows to configure a mapping between these SAML attribute values and [{{es}} user properties](https://www.elastic.co/guide/en/elasticsearch/reference/current/saml-guide-stack.html#saml-elasticsearch-authentication). -The SAML assertion about a user usually includes attribute names and values that can be used for role mapping. The configuration in this section allows to configure a mapping between these SAML attribute values and [Elasticsearch user properties](https://www.elastic.co/guide/en/elasticsearch/reference/current/saml-guide-stack.html#saml-elasticsearch-authentication). When the attributes have been mapped to user properties such as `groups`, these can then be used to configure [role mappings](#ece-saml-role-mapping). Mapping the `principal` user property is required and the `groups` property is recommended for a minimum configuration. +When the attributes have been mapped to user properties such as `groups`, these can then be used to configure [role mappings](#ece-saml-role-mapping). Mapping the `principal` user property is required and the `groups` property is recommended for a minimum configuration. -Note that some additional attention must be paid to the `principal` user property. Although the SAML specification does not have many restrictions on the type of value that is mapped, ECE requires that the mapped value is also a valid Elasticsearch native realm identifier. Specifically, this means the mapped identifier should not contain any commas or slashes, and should be otherwise URL friendly. +:::{note} +Although the SAML specification does not have many restrictions on the type of value that is mapped to the `principal` user property, ECE requires that the mapped value is also a valid {{es}} native realm identifier. + +This means the mapped identifier should not contain any commas or slashes, and should be otherwise URL friendly. +::: ## Create role mappings [ece-saml-role-mapping] -When a user is authenticated, the role mapping assigns them roles in Elastic Cloud Enterprise. You can assign roles by: +When a user is authenticated, the role mapping assigns them roles in {{ece}}. + +To assign all authenticated users a single role, select one of the **Default roles**. -* Assigning all authenticated users a single role, select one of the **Default roles**. -* Assigning roles according to the user properties (such as `dn`, `groups`, `username`), use the **Add role mapping rule** fields. +To assign roles according to the user properties (such as `dn`, `groups`, `username`), use the **Add role mapping rule** fields. -In the following example, you have configured the Elasticsearch user property `groups` to map to the SAML attribute with name `SAML_Roles` and you want only users whose SAML assertion contains the `SAML_Roles` attribute with value `p_viewer` to get the `Platform viewer` role in Elastic Cloud Enterprise. +For a list of roles, refer to [Available roles and permissions](/deploy-manage/users-roles/cloud-enterprise-orchestrator/manage-users-roles.md#ece-user-role-permissions). + +In the following example, you have configured the {{es}} user property `groups` to map to the SAML attribute with name `SAML_Roles` and you want only users whose SAML assertion contains the `SAML_Roles` attribute with value `p_viewer` to get the `Platform viewer` role in {{ece}}. To complete the role mapping: @@ -75,17 +88,23 @@ To complete the role mapping: ## Custom configuration [ece-saml-custom-configuration] -You can add any additional settings to the **Advanced configuration** YAML file. +You can add any additional settings to the **Advanced configuration** YAML file. + +For example, if you need to ignore the SSL check for the SSL certificate of the domain controller in a testing environment, you might add `ssl.verification_mode: none`. + +:::{note} +All entries added should omit the `xpack.security.authc.realms.ldap.$realm_id` prefix, as ECE will insert this itself and automatically account for any differences in format across {{es}} versions. +::: You can also enable some other options: -* **Use single logout (SLO)** makes sure that when a user logs out of Elastic Cloud Enterprise, they will also be redirected to the SAML Identity Provider so that they can logout there and subsequently logout from all of the other SAML sessions they might have with other SAML Service Providers. +* **Use single logout (SLO)** makes sure that when a user logs out of {{ece}}, they will also be redirected to the SAML Identity Provider so that they can logout there and subsequently log out from all of the other SAML sessions they might have with other SAML Service Providers. * **Enable force authentication** means that the Identity Provider must re-authenticate the user for each new session, even if the user has an existing, authenticated session with the Identity Provider. -## Prepare SAML SSL certificates [ece-saml-ssl-certificates] +## Prepare SAML SSL certificates (Optional) [ece-saml-ssl-certificates] -Though optional, you can add one or more certificate authorities (CAs) to validate the SSL/TLS certificate of the server that is hosting the metadata file. This might be useful when the Identity Provider uses a certificate for TLS that is signed by an organization specific Certification Authority, that is not trusted by default by Elastic Cloud Enterprise. +You can add one or more certificate authorities (CAs) to validate the SSL/TLS certificate of the server that is hosting the metadata file. This might be useful when the Identity Provider uses a certificate for TLS that is signed by an organization specific Certification Authority, that is not trusted by default by {{ece}}. 1. Expand the **Advanced settings**. 2. Provide the **SSL certificate URL** to the ZIP file. @@ -98,7 +117,7 @@ Though optional, you can add one or more certificate authorities (CAs) to valida ## Configure SAML signing certificates [ece-configure-saml-signing-certificates] -Elastic Cloud Enterprise can be configured to sign all outgoing SAML messages. Signing the outgoing messages provides assurance that the messages are coming from the expected service. +{{ece}} can be configured to sign all outgoing SAML messages. Signing the outgoing messages provides assurance that the messages are coming from the expected service. 1. Provide the **Signing certificate URL** to the ZIP file with the private key and certificate. @@ -110,7 +129,7 @@ Elastic Cloud Enterprise can be configured to sign all outgoing SAML messages. S ## Configure for the encryption of SAML messages [ece-encrypt-saml] -If your environment requires SAML messages to be encrypted communications, Elastic Cloud Enterprise can be configured with an encryption certificate and key pair. When the Identity Provider uses the public key in this certificate to encrypt the SAML Response ( or parts of it ), Elastic Cloud Enterprise will use the corresponding key to decrypt the message. +If your environment requires SAML messages to be encrypted communications, {{ece}} can be configured with an encryption certificate and key pair. When the Identity Provider uses the public key in this certificate to encrypt the SAML Response ( or parts of it ), {{ece}} will use the corresponding key to decrypt the message. 1. Provide the **Encryption certificate URL** to the ZIP file with the private key and certificate. diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth.md b/deploy-manage/users-roles/cluster-or-deployment-auth.md index 7152066a1e..5178bd5b98 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth.md @@ -20,7 +20,7 @@ This section only covers direct access to and communications with an Elasticsear ## Quickstart -If you plan to use native Elasticsearch user and role management, then [follow our quickstart](/deploy-manage/users-roles/cluster-or-deployment-auth/quickstart.md) to learn how to set up basic authentication and authorization features. +If you plan to use native Elasticsearch user and role management, then [follow our quickstart](/deploy-manage/users-roles/cluster-or-deployment-auth/quickstart.md) to learn how to set up basic authentication and authorization features, including [spaces](/deploy-manage/manage-spaces.md), [roles](/deploy-manage/users-roles/cluster-or-deployment-auth/user-roles.md), and [native users](/deploy-manage/users-roles/cluster-or-deployment-auth/native.md). ### User authentication diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/anonymous-access.md b/deploy-manage/users-roles/cluster-or-deployment-auth/anonymous-access.md index 8845955b16..7a63021dc0 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/anonymous-access.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/anonymous-access.md @@ -6,7 +6,7 @@ mapped_pages: # Anonymous access [anonymous-access] ::::{tip} -To embed {{kib}} dashboards or grant access to {{kib}} without requiring credentials, use {{kib}}'s [anonymous authentication](user-authentication.md#anonymous-authentication) feature instead. +To embed {{kib}} dashboards or grant access to {{kib}} without requiring credentials, use {{kib}}'s [anonymous authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md) feature instead. :::: diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/authentication-realms.md b/deploy-manage/users-roles/cluster-or-deployment-auth/authentication-realms.md index d015d658c9..1f2e3d4dbd 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/authentication-realms.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/authentication-realms.md @@ -1,51 +1,48 @@ --- mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/realms.html +applies: + stack: all + hosted: all + ece: all + eck: all --- # Authentication realms [realms] -The {{stack-security-features}} authenticate users by using realms and one or more [token-based authentication services](token-based-authentication-services.md). +Elastic authenticates users by using realms and one or more [token-based authentication services](token-based-authentication-services.md). -A *realm* is used to resolve and authenticate users based on authentication tokens. The {{security-features}} provide the following built-in realms: +A *realm* is used to resolve and authenticate users based on authentication tokens. There are two types of realms: -*native* -: An internal realm where users are stored in a dedicated {{es}} index. This realm supports an authentication token in the form of username and password, and is available by default when no realms are explicitly configured. The users are managed via the [user management APIs](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-security). See [Native user authentication](native.md). - -*ldap* -: A realm that uses an external LDAP server to authenticate the users. This realm supports an authentication token in the form of username and password, and requires explicit configuration in order to be used. See [LDAP user authentication](ldap.md). - -*active_directory* -: A realm that uses an external Active Directory Server to authenticate the users. With this realm, users are authenticated by usernames and passwords. See [Active Directory user authentication](active-directory.md). +Internal +: Realms that are internal to {{es}} and don’t require any communication with external parties. They are fully managed by {{es}}. There can only be a maximum of one configured realm per internal realm type. {{es}} provides two internal realm types: `native` and `file`. -*pki* -: A realm that authenticates users using Public Key Infrastructure (PKI). This realm works in conjunction with SSL/TLS and identifies the users through the Distinguished Name (DN) of the client’s X.509 certificates. See [PKI user authentication](pki.md). +External +: Realms that require interaction with parties and components external to {{es}}, typically with enterprise grade identity management systems. Unlike internal realms, you can have as many external realms as you would like, each with its own unique name and configuration. [View external realm types](#external-realms). -*file* -: An internal realm where users are defined in files stored on each node in the {{es}} cluster. This realm supports an authentication token in the form of username and password and is always available. See [File-based user authentication](file-based.md). +## Configuring realms -*saml* -: A realm that facilitates authentication using the SAML 2.0 Web SSO protocol. This realm is designed to support authentication through {{kib}} and is not intended for use in the REST API. See [SAML authentication](saml.md). +To learn how to configure and use a specific realm, follow the documentation for the realm that you want to use. You can also configure a custom realm by building a [custom realm plugin](/deploy-manage/users-roles/cluster-or-deployment-auth/custom.md). -*kerberos* -: A realm that authenticates a user using Kerberos authentication. Users are authenticated on the basis of Kerberos tickets. See [Kerberos authentication](kerberos.md). +You can also perform the following tasks to further configure your realms: -*oidc* -: A realm that facilitates authentication using OpenID Connect. It enables {{es}} to serve as an OpenID Connect Relying Party (RP) and provide single sign-on (SSO) support in {{kib}}. See [Configuring single sign-on to the {{stack}} using OpenID Connect](openid-connect.md). +* Prioritize your realms using [realm chains](/deploy-manage/users-roles/cluster-or-deployment-auth/realm-chains.md). +* Allow a single user to authenticate using multiple realms by grouping them together in a [security domain](/deploy-manage/users-roles/cluster-or-deployment-auth/security-domains.md). -*jwt* -: A realm that facilitates using JWT identity tokens as authentication bearer tokens. Compatible tokens are OpenID Connect ID Tokens, or custom JWTs containing the same claims. See [JWT authentication](jwt.md). +## Internal realms -The {{security-features}} also support custom realms. If you need to integrate with another authentication system, you can build a custom realm plugin. For more information, see [Integrating with other authentication systems](custom.md). +{{es}} provides the following built-in internal realms: -## Internal and external realms [_internal_and_external_realms] +:::{include} ../_snippets/internal-realms.md +::: -Realm types can roughly be classified in two categories: +## External realms -Internal -: Realms that are internal to Elasticsearch and don’t require any communication with external parties. They are fully managed by the {{stack}} {{security-features}}. There can only be a maximum of one configured realm per internal realm type. The {{security-features}} provide two internal realm types: `native` and `file`. +{{es}} provides the following built-in external realms: -External -: Realms that require interaction with parties/components external to {{es}}, typically, with enterprise grade identity management systems. Unlike internal realms, there can be as many external realms as one would like - each with its own unique name and configuration. The {{security-features}} provide the following external realm types: `ldap`, `active_directory`, `saml`, `kerberos`, and `pki`. +:::{include} ../_snippets/external-realms.md +::: +## Custom realms +If you need to integrate with another authentication system, you can build a custom realm plugin. For more information, see [Integrating with other authentication systems](custom.md). \ No newline at end of file diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/external-authentication.md b/deploy-manage/users-roles/cluster-or-deployment-auth/external-authentication.md index 9202a19c43..5bfaa4ca4f 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/external-authentication.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/external-authentication.md @@ -1,5 +1,24 @@ +--- +applies: + stack: all + hosted: all + ece: all + eck: all +--- + # External authentication -% What needs to be done: Write from scratch +External authentication in Elastic is any form of authentication that requires interaction with parties and components external to {{es}}, typically with enterprise grade identity management systems. + +Elastic offers several external [realm](authentication-realms.md) types, each of which represents a common authentication provider. You can have as many external realms as you would like, each with its own unique name and configuration. + +If the authentication provider that you want to use is not currently supported, then you can create a your own [custom realm plugin](custom.md) to integrate with additional systems. + +In this section, you'll learn how to configure different types of external realms, and use them to grant access to Elastic resources. + +## Available external realms + +{{es}} provides the following built-in external realms: -⚠️ **This page is a work in progress.** ⚠️ \ No newline at end of file +:::{include} ../_snippets/external-realms.md +::: \ No newline at end of file diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/file-based.md b/deploy-manage/users-roles/cluster-or-deployment-auth/file-based.md index b0940a1934..3158d9acc4 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/file-based.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/file-based.md @@ -2,23 +2,214 @@ mapped_urls: - https://www.elastic.co/guide/en/elasticsearch/reference/current/file-realm.html - https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-users-and-roles.html +applies_to: + deployment: + self: all + eck: all +navigation_title: "File-based" --- -# File-based +# File-based user authentication [file-realm] -% What needs to be done: Refine +You can manage and authenticate users with the built-in `file` realm. With the `file` realm, users are defined in local files on each node in the cluster. -% GitHub issue: https://github.com/elastic/docs-projects/issues/347 +The `file` realm is useful as a fallback or recovery realm. For example in cases where the cluster is unresponsive or the security index is unavailable, or when you forget the password for your administrative users. In this type of scenario, the `file` realm is a convenient workaround: you can define a new `admin` user in the `file` realm and use it to log in and reset the credentials of all other users. -% Use migrated content from existing pages that map to this page: +You can configure only one file realm on {{es}} nodes. -% - [ ] ./raw-migrated-files/elasticsearch/elasticsearch-reference/file-realm.md -% - [ ] ./raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-users-and-roles.md -% Notes: file realm content +::::{important} +* In self-managed deployments, as the administrator of the cluster, it is your responsibility to ensure the same users are defined on every node in the cluster. The {{stack}} {{security-features}} do not deliver any mechanism to guarantee this. +* You can't add or manage users in the `file` realm using the [user APIs](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-security), orusing the {{kib}} **Management > Security > Users** page. +:::: -$$$file-realm-configuration$$$ +## Configure a file realm [file-realm-configuration] -**This page is a work in progress.** The documentation team is working to combine content pulled from the following pages: +You don’t need to explicitly configure a `file` realm. The `file` and `native` realms are added to the realm chain by default. Unless configured otherwise, the `file` realm is added first, followed by the `native` realm. You can define only one `file` realm per node. -* [/raw-migrated-files/elasticsearch/elasticsearch-reference/file-realm.md](/raw-migrated-files/elasticsearch/elasticsearch-reference/file-realm.md) -* [/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-users-and-roles.md](/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-users-and-roles.md) \ No newline at end of file +1. (Optional) Add a realm configuration to `elasticsearch.yml` under the `xpack.security.authc.realms.file` namespace. At a minimum, you must set the realm’s `order` attribute. + + For example, the following snippet shows a `file` realm configuration that sets the `order` to zero so the realm is checked first: + + ```yaml + xpack: + security: + authc: + realms: + file: + file1: + order: 0 + ``` + +2. If you're using a self-managed {{es}} cluster, optionally change how often the `users` and `users_roles` files are checked. + + By default, {{es}} checks these files for changes every 5 seconds. You can change this default behavior by changing the `resource.reload.interval.high` setting in the `elasticsearch.yml` file + + :::{{warning}} + Because `resource.reload.interval.high` is a common setting in {{es}}, changing its value may effect other schedules in the system. + ::: + +3. Restart {{es}}. + + In {{eck}}, this change is propagated automatically. + + +## Add users + +**In a self-managed {{es}} cluster**, all the data about the users for the `file` realm is stored in two files on each node in the cluster: [`users` and `users_roles`](#using-users-and-users_roles-files). Both files are located in `ES_PATH_CONF` and are read on startup. + +**In an {{eck}} deployment**, you can pass file realm user information in two ways: + +1. Using [`users` and `user_roles`](#using-users-and-users_roles-files) files, which are passed using file realm content secrets +2. [Using Kubernetes basic authentication secrets](#k8s-basic) + +You can reference several secrets in the {{es}} specification. ECK aggregates their content into a single secret, mounted in every {{es}} Pod. + +::::{important} +In a self-managed cluster, the `users` and `users_roles` files are managed locally by the node and are **not** managed globally by the cluster. This means that with a typical multi-node cluster, the exact same changes need to be applied on each and every node in the cluster. + +A safer approach would be to apply the change on one of the nodes and have the files distributed or copied to all other nodes in the cluster (either manually or using a configuration management system such as Puppet or Chef). +:::: + +### Using `users` and `users_roles` files + +`users` and `users_roles` files contain all of the information about users in the file realm. + +#### `users` + +The `users` file stores all the users and their passwords. Each line in the file represents a single user entry consisting of the username and hashed and salted password. + +``` +rdeniro:$2a$10$BBJ/ILiyJ1eBTYoRKxkqbuDEdYECplvxnqQ47uiowE7yGqvCEgj9W +alpacino:$2a$10$cNwHnElYiMYZ/T3K4PvzGeJ1KbpXZp2PfoQD.gfaVdImnHOwIuBKS +jacknich:{PBKDF2}50000$z1CLJt0MEFjkIK5iEfgvfnA6xq7lF25uasspsTKSo5Q=$XxCVLbaKDimOdyWgLCLJiyoiWpA/XDMe/xtVgn1r5Sg= +``` + +:::{tip} +To limit exposure to credential theft and mitigate credential compromise, the file realm stores passwords and caches user credentials according to security best practices. By default, a hashed version of user credentials is stored in memory, using a salted sha-256 hash algorithm and a hashed version of passwords is stored on disk salted and hashed with the bcrypt hash algorithm. To use different hash algorithms, see [User cache and password hash algorithms](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-settings.html#hashing-settings). +::: + +#### `users_roles` + +The `users_roles` file stores the roles associated with the users. For example: + +``` +admin:rdeniro +power_user:alpacino,jacknich +user:jacknich +``` + +Each row maps a role to a comma-separated list of all the users that are associated with that role. + +#### Editing `users` and `users_roles` files + +You can edit files and secrets that contain `users` and `users_roles` manually, or you can edit them using a tool. + +**Manually** + +::::{tab-set} + +:::{tab-item} Self-managed +In a self-managed cluster, you can edit the contents of `ES_PATH_CONF/users` and `ES_PATH_CONF/users_roles` directly. +::: + +:::{tab-item} {{eck}} +You can pass `users` and `user_roles` files to {{eck}} using a file realm secret: + +```yaml +apiVersion: elasticsearch.k8s.elastic.co/v1 +kind: Elasticsearch +metadata: + name: elasticsearch-sample +spec: + version: 8.16.1 + auth: + fileRealm: + - secretName: my-filerealm-secret-1 + - secretName: my-filerealm-secret-2 + nodeSets: + - name: default + count: 1 +``` + +A file realm secret is composed of two entries: a `users` entry and a `users_roles` entry. You can provide either one entry or both entries in each secret. + +If you specify multiple users with the same name in more than one secret, the last one takes precedence. If you specify multiple roles with the same name in more than one secret, a single entry per role is derived from the concatenation of its corresponding users from all secrets. + +The following secret specifies three users and their respective roles: + +```yaml +kind: Secret +apiVersion: v1 +metadata: + name: my-filerealm-secret +stringData: + users: |- + rdeniro:$2a$10$BBJ/ILiyJ1eBTYoRKxkqbuDEdYECplvxnqQ47uiowE7yGqvCEgj9W + alpacino:$2a$10$cNwHnElYiMYZ/T3K4PvzGeJ1KbpXZp2PfoQD.gfaVdImnHOwIuBKS + jacknich:{PBKDF2}50000$z1CLJt0MEFjkIK5iEfgvfnA6xq7lF25uasspsTKSo5Q=$XxCVLbaKDimOdyWgLCLJiyoiWpA/XDMe/xtVgn1r5Sg= + users_roles: |- + admin:rdeniro + power_user:alpacino,jacknich + user:jacknich +``` +::: + +:::: + +**Using a tool** + +To avoid editing these files manually, you can use the [elasticsearch-users](https://www.elastic.co/guide/en/elasticsearch/reference/current/users-command.html) tool: + +::::{tab-set} + +:::{tab-item} Self-managed + +``` +bin/elasticsearch-users useradd myuser -p mypassword -r monitoring_user +``` +::: + +:::{tab-item} {{eck}} +The following is an example of invoking the `elasticsearch-users` tool in a Docker container: + +```sh +# create a folder with the 2 files +mkdir filerealm +touch filerealm/users filerealm/users_roles + +# create user 'myuser' with role 'monitoring_user' +docker run \ + -v $(pwd)/filerealm:/usr/share/elasticsearch/config \ + docker.elastic.co/elasticsearch/elasticsearch:8.16.1 \ + bin/elasticsearch-users useradd myuser -p mypassword -r monitoring_user + +# create a Kubernetes secret with the file realm content +kubectl create secret generic my-file-realm-secret --from-file filerealm +``` +::: + +:::: + +### Using {{k8s}} basic authentication secrets [k8s-basic] +```{applies_to} +eck: all +``` +You can also add file-based authentication users using [Kubernetes basic authentication secrets](https://kubernetes.io/docs/concepts/configuration/secret/#basic-authentication-secret). + +A basic authentication secret can optionally contain a [`roles`](#users_roles) entry. It must contain a comma separated list of roles to be associated with the user. The following example illustrates this combination: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: secret-basic-auth +type: kubernetes.io/basic-auth +stringData: + username: rdeniro # required field for kubernetes.io/basic-auth + password: mypassword # required field for kubernetes.io/basic-auth + roles: kibana_admin,ingest_admin # optional, not part of kubernetes.io/basic-auth +``` + +::::{note} +If you specify the password for the `elastic` user through a basic authentication secret, then the secret holding the password described in [](/deploy-manage/users-roles/cluster-or-deployment-auth/built-in-users.md) will not be created by the operator. +:::: diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/internal-authentication.md b/deploy-manage/users-roles/cluster-or-deployment-auth/internal-authentication.md index 5e442a92fd..45795ac553 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/internal-authentication.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/internal-authentication.md @@ -1,5 +1,22 @@ +--- +applies: + stack: all + hosted: all + ece: all + eck: all +--- + # Internal authentication -% What needs to be done: Write from scratch +Internal authentication methods are fully managed by {{es}}, and don't require any communication with external parties. + +{{es}} offers two internal authentication [realms](authentication-realms.md), both of which are enabled by default. There can only be a maximum of one configured realm per internal realm type. + +In this section, you'll learn how to configure internal realms, and manage users that authenticate using internal realms. + +## Available internal realms + +{{es}} provides two internal realm types: -⚠️ **This page is a work in progress.** ⚠️ \ No newline at end of file +:::{include} ../_snippets/internal-realms.md +::: diff --git a/raw-migrated-files/kibana/kibana/kibana-authentication.md b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md similarity index 78% rename from raw-migrated-files/kibana/kibana/kibana-authentication.md rename to deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md index 0c4ef33b83..419df5e4cf 100644 --- a/raw-migrated-files/kibana/kibana/kibana-authentication.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md @@ -1,24 +1,28 @@ --- -navigation_title: "Authentication" +navigation_title: "Kibana authentication" +applies: + hosted: all + ece: all + eck: all + stack: all --- # Authentication in {{kib}} [kibana-authentication] +After you configure an authentication method in {{es}}, you can configure an authentication mechanism to log in to {{kib}}. {{kib}} supports the following authentication mechanisms: -* [Multiple authentication providers](../../../deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md#multiple-authentication-providers) -* [Basic authentication](../../../deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md#basic-authentication) -* [Token authentication](../../../deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md#token-authentication) -* [Public key infrastructure (PKI) authentication](../../../deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md#pki-authentication) -* [SAML single sign-on](../../../deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md#saml) -* [OpenID Connect single sign-on](../../../deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md#oidc) -* [Kerberos single sign-on](../../../deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md#kerberos) -* [Anonymous authentication](../../../deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md#anonymous-authentication) -* [HTTP authentication](../../../deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md#http-authentication) -* [Embedded content authentication](../../../deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md#embedded-content-authentication) - -For an introduction to {{kib}}'s security features, including the login process, refer to [*Securing access to {{kib}}*](../../../deploy-manage/users-roles/cluster-or-deployment-auth/quickstart.md). +* [Multiple authentication providers](#multiple-authentication-providers) +* [Basic authentication](#basic-authentication) +* [Token authentication](#token-authentication) +* [Public key infrastructure (PKI) authentication](#pki-authentication) +* [SAML single sign-on](#saml) +* [OpenID Connect single sign-on](#oidc) +* [Kerberos single sign-on](#kerberos) +* [Anonymous authentication](#anonymous-authentication) +* [HTTP authentication](#http-authentication) +* [Embedded content authentication](#embedded-content-authentication) ## Multiple authentication providers [multiple-authentication-providers] @@ -76,28 +80,23 @@ If you have multiple authentication providers configured, you can use the `auth_ ## Basic authentication [basic-authentication] -To successfully log in to {{kib}}, basic authentication requires a username and password. Basic authentication is enabled by default, and is based on the Native, LDAP, or Active Directory security realm that is provided by {{es}}. The basic authentication provider uses a {{kib}} provided login form, and supports authentication using the `Authorization` request header `Basic` scheme. +To successfully log in to {{kib}}, basic authentication requires a username and password. Basic authentication is enabled by default, and is based on the [Native](native.md), [LDAP](ldap.md), or [Active Directory](active-directory.md) security realm that is provided by {{es}}. The basic authentication provider uses a {{kib}} provided login form, and supports authentication using the `Authorization` request header `Basic` scheme. ::::{note} You can configure only one Basic provider per {{kib}} instance. :::: - -For more information about basic authentication and built-in users, see [User authentication](../../../deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md). - - ## Token authentication [token-authentication] -Token authentication is a [subscription feature](https://www.elastic.co/subscriptions). This allows users to log in using the same {{kib}} provided login form as basic authentication, and is based on the Native security realm or LDAP security realm that is provided by {{es}}. The token authentication provider is built on {{es}} token APIs. - -Prior to configuring {{kib}}, ensure token support is enabled in {{es}}. See the [{{es}} token API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-security-get-token) documentation for more information. +Token authentication is a [subscription feature](https://www.elastic.co/subscriptions). This allows users to log in using the same {{kib}} provided login form as basic authentication, and is based on the [Native](native.md) or [LDAP](ldap.md) security realm that is provided by {{es}}. The token authentication provider is built on {{es}} token APIs. -To enable the token authentication provider in {{kib}}, set the following value in your `kibana.yml`: +Prior to configuring {{kib}}, ensure that token support is enabled in {{es}}. See the [{{es}} token API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-security-get-token) documentation for more information. ::::{note} -You can configure only one Token provider per {{kib}} instance. +You can configure only one token provider per {{kib}} instance. :::: +To enable the token authentication provider in {{kib}}, set the following value in your `kibana.yml`: ```yaml xpack.security.authc.providers: @@ -105,7 +104,7 @@ xpack.security.authc.providers: order: 0 ``` -Switching to the token authentication provider from basic one will make {{kib}} to reject requests from applications like `curl` that usually use `Authorization` request header with the `Basic` scheme for authentication. If you still want to support such applications you’ll have to either switch to using `Bearer` scheme with the tokens [created by {{es}} token API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-security-get-token) or add `Basic` scheme to the list of supported schemes for the [HTTP authentication](../../../deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md#http-authentication). +Switching to the token authentication provider from the basic one will make {{kib}} to reject requests from applications like `curl` that usually use `Authorization` request header with the `Basic` scheme for authentication. If you still want to support such applications, you’ll have to either switch to using `Bearer` scheme with the tokens [created by {{es}} token API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-security-get-token), or add the `Basic` scheme to the list of supported schemes for the [HTTP authentication](#http-authentication). ## Public key infrastructure (PKI) authentication [pki-authentication] @@ -200,12 +199,12 @@ xpack.security.authc.providers: Basic authentication is supported *only* if the `basic` authentication provider is explicitly declared in `xpack.security.authc.providers` setting, in addition to `saml`. -To support basic authentication for the applications like `curl` or when the `Authorization: Basic base64(username:password)` HTTP header is included in the request (for example, by reverse proxy), add `Basic` scheme to the list of supported schemes for the [HTTP authentication](../../../deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md#http-authentication). +To support basic authentication for the applications like `curl` or when the `Authorization: Basic base64(username:password)` HTTP header is included in the request (for example, by reverse proxy), add `Basic` scheme to the list of supported schemes for the [HTTP authentication](#http-authentication). ## OpenID Connect single sign-on [oidc] -OpenID Connect (OIDC) authentication is part of single sign-on (SSO), a [subscription feature](https://www.elastic.co/subscriptions). Similar to SAML, authentication with OIDC allows users to log in to {{kib}} using an OIDC Provider such as Google, or Okta. OIDC should also be configured in {{es}}. For more details, see [Configuring single sign-on to the {{stack}} using OpenID Connect](../../../deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md). +OpenID Connect (OIDC) authentication is part of single sign-on (SSO), a [subscription feature](https://www.elastic.co/subscriptions). Similar to SAML, authentication with OIDC allows users to log in to {{kib}} using an OIDC Provider such as Google, or Okta. OIDC should also be configured in {{es}}. For more details, see [Configuring single sign-on to the {{stack}} using OpenID Connect](/deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md). Enable OIDC authentication by specifying which OIDC realm in {{es}} to use: @@ -249,12 +248,12 @@ xpack.security.authc.providers: Basic authentication is supported *only* if the `basic` authentication provider is explicitly declared in `xpack.security.authc.providers` setting, in addition to `oidc`. -To support basic authentication for the applications like `curl` or when the `Authorization: Basic base64(username:password)` HTTP header is included in the request (for example, by reverse proxy), add `Basic` scheme to the list of supported schemes for the [HTTP authentication](../../../deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md#http-authentication). +To support basic authentication for the applications like `curl` or when the `Authorization: Basic base64(username:password)` HTTP header is included in the request (for example, by reverse proxy), add `Basic` scheme to the list of supported schemes for the [HTTP authentication](#http-authentication). ### Single sign-on provider details [_single_sign_on_provider_details] -The following sections apply both to [SAML single sign-on](../../../deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md#saml) and [OpenID Connect single sign-on](../../../deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md#oidc) +The following sections apply both to [SAML single sign-on](#saml) and [OpenID Connect single sign-on](#oidc). #### Access and refresh tokens [_access_and_refresh_tokens] @@ -275,7 +274,7 @@ During logout, both the {{kib}} session and {{es}} access/refresh token pair are ## Kerberos single sign-on [kerberos] -Kerberos authentication is part of single sign-on (SSO), a [subscription feature](https://www.elastic.co/subscriptions). Make sure that Kerberos is enabled and configured in {{es}} before setting it up in {{kib}}. See [Kerberos authentication](../../../deploy-manage/users-roles/cluster-or-deployment-auth/kerberos.md). +Kerberos authentication is part of single sign-on (SSO), a [subscription feature](https://www.elastic.co/subscriptions). Make sure that Kerberos is enabled and configured in {{es}} before setting it up in {{kib}}. See [Kerberos authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/kerberos.md). Next, to enable Kerberos in {{kib}}, you will need to enable the Kerberos authentication provider in the `kibana.yml` configuration file, as follows: @@ -306,7 +305,6 @@ xpack.security.authc.providers: :::: - ## Anonymous authentication [anonymous-authentication] ::::{important} @@ -324,7 +322,7 @@ You can configure only one anonymous authentication provider per {{kib}} instanc :::: -You must have a user account that can authenticate to {{es}} using a username and password, for instance from the Native or LDAP security realms, so that you can use these credentials to impersonate the anonymous users. Here is how your `kibana.yml` might look: +You must have a user account that can authenticate to {{es}} using a username and password, for instance from the [Native](native.md) or [LDAP](ldap.md) security realms, so that you can use these credentials to impersonate the anonymous users. Here is how your `kibana.yml` might look: ```yaml xpack.security.authc.providers: @@ -361,9 +359,9 @@ For information on how to embed, refer to [Embed {{kib}} content in a web page]( #### Anonymous access session [anonymous-access-session] -{{kib}} maintains a separate [session](../../../deploy-manage/security/kibana-session-management.md) for every anonymous user, as it does for all other authentication mechanisms. +{{kib}} maintains a separate [session](/deploy-manage/security/kibana-session-management.md) for every anonymous user, as it does for all other authentication mechanisms. -You can configure [session idle timeout](../../../deploy-manage/security/kibana-session-management.md#session-idle-timeout) and [session lifespan](../../../deploy-manage/security/kibana-session-management.md#session-lifespan) for anonymous sessions the same as you do for any other session with the exception that idle timeout is explicitly disabled for anonymous sessions by default. The global [`xpack.security.session.idleTimeout`](https://www.elastic.co/guide/en/kibana/current/security-settings-kb.html#security-session-and-cookie-settings) setting doesn’t affect anonymous sessions. To change the idle timeout for anonymous sessions, you must configure the provider-level [`xpack.security.authc.providers.anonymous..session.idleTimeout`](https://www.elastic.co/guide/en/kibana/current/security-settings-kb.html#anonymous-authentication-provider-settings) setting. +You can configure [session idle timeout](/deploy-manage/security/kibana-session-management.md#session-idle-timeout) and [session lifespan](/deploy-manage/security/kibana-session-management.md#session-lifespan) for anonymous sessions the same as you do for any other session with the exception that idle timeout is explicitly disabled for anonymous sessions by default. The global [`xpack.security.session.idleTimeout`](https://www.elastic.co/guide/en/kibana/current/security-settings-kb.html#security-session-and-cookie-settings) setting doesn’t affect anonymous sessions. To change the idle timeout for anonymous sessions, you must configure the provider-level [`xpack.security.authc.providers.anonymous..session.idleTimeout`](https://www.elastic.co/guide/en/kibana/current/security-settings-kb.html#anonymous-authentication-provider-settings) setting. ## HTTP authentication [http-authentication] @@ -384,7 +382,7 @@ API keys are intended for programmatic access to {{kib}} and {{es}}. Do not use :::: -By default {{kib}} supports [`ApiKey`](../../../deploy-manage/api-keys/elasticsearch-api-keys.md) authentication scheme *and* any scheme supported by the currently enabled authentication provider. For example, `Basic` authentication scheme is automatically supported when basic authentication provider is enabled, or `Bearer` scheme when any of the token based authentication providers is enabled (Token, SAML, OpenID Connect, PKI or Kerberos). But it’s also possible to add support for any other authentication scheme in the `kibana.yml` configuration file, as follows: +By default {{kib}} supports [`ApiKey`](/deploy-manage/api-keys/elasticsearch-api-keys.md) authentication scheme *and* any scheme supported by the currently enabled authentication provider. For example, `Basic` authentication scheme is automatically supported when basic authentication provider is enabled, or `Bearer` scheme when any of the token based authentication providers is enabled (Token, SAML, OpenID Connect, PKI or Kerberos). But it’s also possible to add support for any other authentication scheme in the `kibana.yml` configuration file, as follows: ::::{note} Don’t forget to explicitly specify the default `apikey` and `bearer` schemes when you just want to add a new one to the list. @@ -432,6 +430,4 @@ To make this iframe leverage anonymous access automatically, you will need to mo :::: -For more information, refer to [Embed code](../../../explore-analyze/report-and-share.md#embed-code). - - +For more information, refer to [Embed code](../../../explore-analyze/report-and-share.md#embed-code). \ No newline at end of file diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/native.md b/deploy-manage/users-roles/cluster-or-deployment-auth/native.md index 8292c14550..60731b459d 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/native.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/native.md @@ -4,31 +4,102 @@ mapped_urls: - https://www.elastic.co/guide/en/cloud-on-k8s/current/k8s-users-and-roles.html - https://www.elastic.co/guide/en/elasticsearch/reference/current/change-passwords-native-users.html - https://www.elastic.co/guide/en/kibana/current/tutorial-secure-access-to-kibana.html +applies_to: + deployment: + self: all + hosted: all + ece: all + eck: all +navigation_title: "Native" --- -# Native +# Native user authentication [native-realm] -% What needs to be done: Refine +The easiest way to manage and authenticate users is with the internal `native` realm. You can use [Elasticsearch REST APIs](#native-users-api) or [Kibana](#managing-native-users) to add and remove users, assign user roles, and manage user passwords. -% GitHub issue: https://github.com/elastic/docs-projects/issues/347 +In self-managed {{es}} clusters, you can also reset passwords for users in the native realm [using the command line](#reset-pw-cmd-line). -% Use migrated content from existing pages that map to this page: +## Configure a native realm [native-realm-configuration] -% - [ ] ./raw-migrated-files/elasticsearch/elasticsearch-reference/native-realm.md -% - [ ] ./raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-users-and-roles.md -% Notes: native realm content -% - [ ] ./raw-migrated-files/elasticsearch/elasticsearch-reference/change-passwords-native-users.md -% - [ ] ./raw-migrated-files/kibana/kibana/tutorial-secure-access-to-kibana.md +The native realm is available and enabled by default. You can disable it explicitly with the following setting. -% Internal links rely on the following IDs being on this page (e.g. as a heading ID, paragraph ID, etc): +```yaml +xpack.security.authc.realms.native.native1: + enabled: false +``` -$$$k8s-default-elastic-user$$$ +You can configure a `native` realm in the `xpack.security.authc.realms.native` namespace in `elasticsearch.yml`. Explicitly configuring a native realm enables you to set the order in which it appears in the realm chain, temporarily disable the realm, and control its cache options. -$$$managing-native-users$$$ +1. Add a realm configuration to `elasticsearch.yml` under the `xpack.security.authc.realms.native` namespace. It is recommended that you explicitly set the `order` attribute for the realm. -**This page is a work in progress.** The documentation team is working to combine content pulled from the following pages: + ::::{note} + You can configure only one native realm on {{es}} nodes. + :::: -* [/raw-migrated-files/elasticsearch/elasticsearch-reference/native-realm.md](/raw-migrated-files/elasticsearch/elasticsearch-reference/native-realm.md) -* [/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-users-and-roles.md](/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-users-and-roles.md) -* [/raw-migrated-files/elasticsearch/elasticsearch-reference/change-passwords-native-users.md](/raw-migrated-files/elasticsearch/elasticsearch-reference/change-passwords-native-users.md) -* [/raw-migrated-files/kibana/kibana/tutorial-secure-access-to-kibana.md](/raw-migrated-files/kibana/kibana/tutorial-secure-access-to-kibana.md) \ No newline at end of file + + See [Native realm settings](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-settings.html#ref-native-settings) for all of the options you can set for the `native` realm. For example, the following snippet shows a `native` realm configuration that sets the `order` to zero so the realm is checked first: + + ```yaml + xpack.security.authc.realms.native.native1: + order: 0 + ``` + + ::::{note} + To limit exposure to credential theft and mitigate credential compromise, the native realm stores passwords and caches user credentials according to security best practices. By default, a hashed version of user credentials is stored in memory, using a salted `sha-256` hash algorithm and a hashed version of passwords is stored on disk salted and hashed with the `bcrypt` hash algorithm. To use different hash algorithms, see [User cache and password hash algorithms](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-settings.html#hashing-settings). + :::: + +2. Restart {{es}}. + + +## Manage native users using {{kib}} [managing-native-users] + +The Elastic enables you to easily manage users in {{kib}} on the **Stack Management > Security > Users** page. From this page, you can create users, edit users, assign roles to users, and change user passwords. You can also deactivate or delete existing users. + +### Example: Create a user [_create_a_user] + +1. Navigate to **Stack Management**, and under **Security**, select **Users**. +2. Click **Create user**. +3. Give the user a descriptive username, and choose a secure password. +4. Optional: assign [roles](/deploy-manage/users-roles/cluster-or-deployment-auth/user-roles.md) to the user. +5. Click **Create user**. + +:::{image} ../../../images/kibana-tutorial-secure-access-example-1-user.png +:alt: Create user UI +:class: screenshot +::: + +## Manage native users using the `user` API [native-users-api] + +You can manage users through the Elasticsearch `user` API. + +For example, you can change a user's password: + +```console +POST /_security/user/user1/_password +{ + "password" : "new-test-password" +} +``` + +For more information and examples, see [Users](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-security). + +## Reset passwords for native users using the command line [reset-pw-cmd-line] + +:::{applies} +:stack: all +:eck: all +::: + +You can also reset passwords for users in the native realm through the command line using the [`elasticsearch-reset-password`](https://www.elastic.co/guide/en/elasticsearch/reference/current/reset-password.html) tool. + +For example, the following command changes the password for a user with the username `user1` to an auto-generated value, and prints the new password to the terminal: + +```shell +bin/elasticsearch-reset-password -u user1 +``` + +To explicitly set a password for a user, include the `-i` parameter with the intended password. + +```shell +bin/elasticsearch-reset-password -u user1 -i +``` diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/pki.md b/deploy-manage/users-roles/cluster-or-deployment-auth/pki.md index 5c537ae6dc..c2abdecc68 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/pki.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/pki.md @@ -166,7 +166,7 @@ xpack: path: "pki1_truststore.jks" ``` -After you restart {{es}}, this realm can validate delegated PKI authentication. You must then [configure {{kib}} to allow PKI certificate authentication](user-authentication.md#pki-authentication). +After you restart {{es}}, this realm can validate delegated PKI authentication. You must then [configure {{kib}} to allow PKI certificate authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md#pki-authentication). A PKI realm with `delegation.enabled` still works unchanged for clients connecting directly to {{es}}. Directly authenticated users and users that are PKI authenticated by delegation to {{kib}} both follow the same [role mapping rules](mapping-users-groups-to-roles.md) or [authorization realms configurations](realm-chains.md#authorization_realms). diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/quickstart.md b/deploy-manage/users-roles/cluster-or-deployment-auth/quickstart.md index d55b311605..833d1fdb48 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/quickstart.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/quickstart.md @@ -1,59 +1,63 @@ --- mapped_pages: - https://www.elastic.co/guide/en/kibana/current/tutorial-secure-access-to-kibana.html +applies: + stack: all + hosted: all + ece: all + eck: all --- # Quickstart [tutorial-secure-access-to-kibana] -{{kib}} is home to an ever-growing suite of powerful features, which help you get the most out of your data. Your data is important, and should be protected. {{kib}} allows you to secure access to your data and control how users are able to interact with your data. +If you plan to use native Elasticsearch user and role management, then you can manage your users and roles completely within your {{kib}} instance. -For example, some users might only need to view your stunning dashboards, while others might need to manage your fleet of Elastic agents and run machine learning jobs to detect anomalous behavior in your network. - -This guide introduces you to three of {{kib}}'s security features: spaces, roles, and users. By the end of this tutorial, you will learn how to manage these entities, and how you can leverage them to secure access to both {{kib}} and your data. +You can use native access management features to give your users access to only the surfaces and features they need. For example, some users might only need to view your dashboards, while others might need to manage your fleet of Elastic agents and run machine learning jobs to detect anomalous behavior in your network. +This guide introduces you to three basic user and access management features: [spaces](/deploy-manage/manage-spaces.md), [roles](/deploy-manage/users-roles/cluster-or-deployment-auth/user-roles.md), and [native users](/deploy-manage/users-roles/cluster-or-deployment-auth/native.md). By the end of this tutorial, you will learn how to manage these entities, and how you can leverage them to secure access to {{es}}, {{kib}}, and your data. ## Spaces [_spaces] Do you have multiple teams using {{kib}}? Do you want a “playground” to experiment with new visualizations or rules? If so, then [{{kib}} Spaces](../../manage-spaces.md) can help. -Think of a space as another instance of {{kib}}. A space allows you to organize your [dashboards](../../../explore-analyze/dashboards.md), [rules](../../../explore-analyze/alerts-cases/alerts.md), [machine learning jobs](../../../explore-analyze/machine-learning/machine-learning-in-kibana.md), and much more into their own categories. For example, you might have a Marketing space for your marketeers to track the results of their campaigns, and an Engineering space for your developers to [monitor application performance](/solutions/observability/apps/application-performance-monitoring-apm.md). +Think of a space as another instance of {{kib}}. A space allows you to organize your [dashboards](../../../explore-analyze/dashboards.md), [rules](../../../explore-analyze/alerts-cases/alerts.md), [machine learning jobs](../../../explore-analyze/machine-learning/machine-learning-in-kibana.md), and much more into their own categories. For example, you might have a **Marketing** space for your marketers to track the results of their campaigns, and an **Engineering** space for your developers to [monitor application performance](/solutions/observability/apps/application-performance-monitoring-apm.md). The assets you create in one space are isolated from other spaces, so when you enter a space, you only see the assets that belong to that space. -Refer to the [Spaces documentation](../../manage-spaces.md) for more information. +Refer to the [Spaces documentation](/deploy-manage/manage-spaces.md) for more information. ## Roles [_roles] -Once your spaces are setup, the next step to securing access is to provision your roles. Roles are a collection of privileges that allow you to perform actions in {{kib}} and Elasticsearch. Roles are assigned to users, and to [system accounts](built-in-users.md) that power the Elastic Stack. +After your spaces are set up, the next step to securing access is to provision your roles. Roles are a collection of privileges that allow you to perform actions in {{kib}} and Elasticsearch. Roles are assigned to users, and to [system accounts](built-in-users.md) that power the Elastic Stack. You can create your own roles, or use any of the [built-in roles](built-in-roles.md). Some built-in roles are intended for Elastic Stack components and should not be assigned to end users directly. -One of the more useful built-in roles is `kibana_admin`. Assigning this role to your users will grant access to all of {{kib}}'s features. This includes the ability to manage Spaces. +An example of a built-in role is `kibana_admin`. Assigning this role to your users will grant access to all of {{kib}}'s features. This includes the ability to manage spaces. -The built-in roles are great for getting started with the Elastic Stack, and for system administrators who do not need more restrictive access. With so many features, it’s not possible to ship more granular roles to accommodate everyone’s needs. This is where custom roles come in. +Built-in roles are great for getting started with the Elastic Stack, and for system administrators who do not need more restrictive access. However, if you need to control access with more precision, you can create [custom roles](/deploy-manage/users-roles/cluster-or-deployment-auth/defining-roles.md). As an administrator, you have the ability to create your own roles to describe exactly the kind of access your users should have. For example, you might create a `marketing_user` role, which you then assign to all users in your marketing department. This role would grant access to all of the necessary data and features for this team to be successful, without granting them access they don’t require. ## Users [_users] -Once your roles are setup, the next step to securing access is to create your users, and assign them one or more roles. {{kib}}'s user management allows you to provision accounts for each of your users. +After your roles are set up, the next step to securing access is to create your users, and assign them one or more roles. {{kib}}'s user management allows you to provision accounts for each of your users. ::::{tip} -Want Single Sign-on? {{kib}} supports a wide range of SSO implementations, including SAML, OIDC, LDAP/AD, and Kerberos. [Learn more about {{kib}}'s SSO features](user-authentication.md). +Want Single Sign-on? {{kib}} supports a wide range of SSO implementations, including SAML, OIDC, LDAP/AD, and Kerberos. [Learn more about SSO options](/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md). :::: ## Example: Create a user with access only to dashboards [tutorial-secure-kibana-dashboards-only] -Let’s work through an example together. Consider a marketing analyst who wants to monitor the effectiveness of their campaigns. They should be able to see their team’s dashboards, but not be allowed to view or manage anything else in {{kib}}. All of the team’s dashboards are located in the Marketing space. +Let’s work through an example together. Consider a marketing analyst who wants to monitor the effectiveness of their campaigns. They should be able to see their team’s dashboards, but not be allowed to view or manage anything else in {{kib}}. ### Create a space [_create_a_space] -Create a Marketing space for your marketing analysts to use. +Create a **Marketing** space for your marketing analysts to use. 1. Go to the **Spaces** management page using the navigation menu or the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). 2. Click **Create a space**. @@ -93,7 +97,7 @@ To create the role: 5. To grant access to dashboards in the `Marketing` space, locate the {{kib}} section, and click **Add {{kib}} privilege**: 1. From the **Spaces** dropdown, select the `Marketing` space. - 2. Expand the **Analytics*** section, and select the ***Read*** privilege for ***Dashboard**. + 2. Expand the **Analytics** section, and select the **Read** privilege for **Dashboard**. 3. Click **Add Kibana privilege**. 6. Click **Create role**. @@ -127,7 +131,7 @@ Now that you created a role, create a user account. Verify that the user and role are working correctly. -1. Logout of {{kib}} if you are already logged in. +1. Log out of {{kib}} if you are already logged in. 2. In the login screen, enter the username and password for the account you created. You’re taken into the `Marketing` space, and the main navigation shows only the **Dashboard** application. @@ -139,11 +143,9 @@ Verify that the user and role are working correctly. -## What’s next? [_whats_next_2] +## Next steps -This guide is an introduction to {{kib}}'s security features. Check out these additional resources to learn more about authenticating and authorizing your users. +This guide is an introduction to basic auth features. Check out these additional resources to learn more about authenticating and authorizing your users. * View the [authentication guide](user-authentication.md) to learn more about single-sign on and other login features. * View the [authorization guide](defining-roles.md) to learn more about authorizing access to {{kib}}'s features. - -Still have questions? Ask on our [Kibana discuss forum](https://discuss.elastic.co/c/kibana) and a fellow community member or Elastic engineer will help out. diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/realm-chains.md b/deploy-manage/users-roles/cluster-or-deployment-auth/realm-chains.md index eef6143b7c..439c637a18 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/realm-chains.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/realm-chains.md @@ -1,22 +1,34 @@ --- mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/realm-chains.html +applies: + stack: all + hosted: all + ece: all + eck: all --- # Realm chains [realm-chains] -[Realms](authentication-realms.md) live within a *realm chain*. It is essentially a prioritized list of configured realms (typically of various types). Realms are consulted in ascending order (that is to say, the realm with the lowest `order` value is consulted first). You must make sure each configured realm has a distinct `order` setting. In the event that two or more realms have the same `order`, the node will fail to start. +[Realms](authentication-realms.md) live within a *realm chain*. It is essentially a prioritized list of configured realms typically of various types. Realms are consulted in ascending order: the realm with the lowest `order` value is consulted first. -During the authentication process, {{stack}} {{security-features}} consult and try to authenticate the request one realm at a time. Once one of the realms successfully authenticates the request, the authentication is considered to be successful. The authenticated user is associated with the request, which then proceeds to the authorization phase. If a realm cannot authenticate the request, the next realm in the chain is consulted. If all realms in the chain cannot authenticate the request, the authentication is considered to be unsuccessful and an authentication error is returned (as HTTP status code `401`). +You must make sure each configured realm has a distinct `order` setting. In the event that two or more realms have the same `order`, the node will fail to start. + +During the authentication process, {{es}} consults and tries to authenticate the request one realm at a time. Once one of the realms successfully authenticates the request, the authentication is considered to be successful. The authenticated user is associated with the request, which then proceeds to the authorization phase. If a realm can't authenticate the request, the next realm in the chain is consulted. If none of the realms in the chain can authenticate the request, the authentication is considered to be unsuccessful and an authentication error is returned (as HTTP status code `401`). ::::{note} -Some systems (e.g. Active Directory) have a temporary lock-out period after several successive failed login attempts. If the same username exists in multiple realms, unintentional account lockouts are possible. For more information, see [Users are frequently locked out of Active Directory](../../../troubleshoot/elasticsearch/security/trouble-shoot-active-directory.md). +Some systems, such as Active Directory, have a temporary lock-out period after several successive failed login attempts. If the same username exists in multiple realms, unintentional account lockouts are possible. For more information, see [Users are frequently locked out of Active Directory](/troubleshoot/elasticsearch/security/trouble-shoot-active-directory.md). :::: +## Configure a realm chain + +The default realm chain contains the `file` and `native` realms. To explicitly configure a realm chain, specify the chain in the `elasticsearch.yml` file. -The default realm chain contains the `file` and `native` realms. To explicitly configure a realm chain, you specify the chain in the `elasticsearch.yml` file. If your realm chain does not contain `file` or `native` realm or does not disable them explicitly, `file` and `native` realms will be added automatically to the beginning of the realm chain in that order. To opt-out from the automatic behaviour, you can explicitly configure the `file` and `native` realms with the `order` and `enabled` settings. +If your realm chain does not contain `file` or `native` realm or does not disable them explicitly, `file` and `native` realms will be added automatically to the beginning of the realm chain in that order. To opt out from this automatic behavior, you can explicitly configure the `file` and `native` realms with the `order` and `enabled` settings. -The following snippet configures a realm chain that enables the `file` realm as well as two LDAP realms and an Active Directory realm, but disables the `native` realm. +Each realm has a unique name that identifies it. Each type of realm dictates its own set of required and optional settings. There are also settings that are common to all realms. To explore these settings, refer to [Realm settings](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-settings.html#realm-settings). + +The following snippet configures a realm chain that enables the `file` realm, two LDAP realms, and an Active Directory realm, and disables the `native` realm. ```yaml xpack.security.authc.realms: @@ -42,19 +54,17 @@ xpack.security.authc.realms: enabled: false ``` -As can be seen above, each realm has a unique name that identifies it. Each type of realm dictates its own set of required and optional settings. That said, there are [settings that are common to all realms](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-settings.html#ref-realm-settings). - ## Delegating authorization to another realm [authorization_realms] -Some realms have the ability to perform *authentication* internally, but delegate the lookup and assignment of roles (that is, *authorization*) to another realm. +Some realms have the ability to perform authentication internally, but delegate the lookup and assignment of roles (authorization) to another realm. -For example, you may wish to use a PKI realm to authenticate your users with TLS client certificates, then lookup that user in an LDAP realm and use their LDAP group assignments to determine their roles in Elasticsearch. +For example, you might want to use a PKI realm to authenticate your users with TLS client certificates, then look up that user in an LDAP realm and use their LDAP group assignments to determine their roles in {{es}}. -Any realm that supports retrieving users (without needing their credentials) can be used as an *authorization realm* (that is, its name may appear as one of the values in the list of `authorization_realms`). See [Looking up users without authentication](looking-up-users-without-authentication.md) for further explanation on which realms support this. +Any realm that supports retrieving users without needing their credentials can be used as an authorization realm. Refer to [Looking up users without authentication](looking-up-users-without-authentication.md) to learn which realms can be used as authorization realms. For realms that support this feature, it can be enabled by configuring the `authorization_realms` setting on the authenticating realm. Check the list of [supported settings](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-settings.html#realm-settings) for each realm to see if they support the `authorization_realms` setting. -If delegated authorization is enabled for a realm, it authenticates the user in its standard manner (including relevant caching) then looks for that user in the configured list of authorization realms. It tries each realm in the order they are specified in the `authorization_realms` setting. The user is retrieved by principal - the user must have identical usernames in the *authentication* and *authorization realms*. If the user cannot be found in any of the authorization realms, authentication fails. +If delegated authorization is enabled for a realm, it authenticates the user in its standard manner, including relevant caching, then looks for that user in the configured list of authorization realms. It tries each realm in the order they are specified in the `authorization_realms` setting. The user is retrieved by principal - the user must have identical usernames in the authentication and authorization realms. If the user can't be found in any of the authorization realms, then authentication fails. See [Configuring authorization delegation](authorization-delegation.md) for more details. diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/security-domains.md b/deploy-manage/users-roles/cluster-or-deployment-auth/security-domains.md index 1c1f0237c4..7accd50ee5 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/security-domains.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/security-domains.md @@ -1,6 +1,11 @@ --- mapped_pages: - https://www.elastic.co/guide/en/elasticsearch/reference/current/security-domain.html +applies: + stack: all + hosted: all + ece: all + eck: all --- # Security domains [security-domain] @@ -21,7 +26,7 @@ Security domains make resource sharing across realms possible by grouping those ### Managing roles across realms [security-domain-realm-roles] -{{es}} provides multiple ways to consistently apply roles across realms. For example, you can use [authorization delegation](authorization-delegation.md) to ensure that a user is assigned the same roles from multiple realms. You can also manually configure multiple realms that are backed by the same directory service. Though it’s possible to configure different [roles](user-roles.md#roles) for the same user when authenticating with different realms, it is *not* recommended. +{{es}} provides multiple ways to consistently apply roles across realms. For example, you can use [authorization delegation](authorization-delegation.md) to ensure that a user is assigned the same roles from multiple realms. You can also manually configure multiple realms that are backed by the same directory service. Though it’s possible to configure different [roles](user-roles.md#roles) for the same user when authenticating with different realms, it is not recommended. @@ -65,7 +70,7 @@ To configure a security domain: 2. Restart {{es}}. ::::{important} - {{es}} can fail to start if the domain configuration is invalid, such as: + {{es}} can fail to start if the domain configuration is invalid. Invalid configurations include: * The same realm is configured under multiple domains. * Any undefined realm, synthetic realm, or the reserved realm is configured to be under a domain. diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md b/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md index b6b7406dcf..039d02c490 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md @@ -19,61 +19,54 @@ applies: % Use migrated content from existing pages that map to this page: -% - [ ] ./raw-migrated-files/elasticsearch/elasticsearch-reference/setting-up-authentication.md % - [ ] ./raw-migrated-files/kibana/kibana/kibana-authentication.md -% Notes: this is a good overview -% Internal links rely on the following IDs being on this page (e.g. as a heading ID, paragraph ID, etc): +Authentication identifies an individual. To gain access to restricted resources, a user must prove their identity, using passwords, credentials, or some other means (typically referred to as authentication tokens). -$$$pki-authentication$$$ +The {{stack}} authenticates users by identifying the users behind the requests that hit the cluster and verifying that they are who they claim to be. The authentication process is handled by one or more authentication services called [*realms*](/deploy-manage/users-roles/cluster-or-deployment-auth/authentication-realms.md). -$$$anonymous-authentication$$$ +You can manage and authenticate users natively, or integrate with external user management systems such as LDAP and Active Directory. If none of the built-in realms meet your needs, you can also build your own custom realm and plug it into the {{stack}}. -$$$basic-authentication$$$ +When {{security-features}} are enabled, depending on the realms you’ve configured, you must attach your user credentials to requests sent to {{es}}. For example, when using realms that support usernames and passwords, you can attach a [basic auth](https://en.wikipedia.org/wiki/Basic_access_authentication) header to the requests. -$$$embedded-content-authentication$$$ +The {{security-features}} provide two services: the token service and the API key service. You can use these services to exchange the current authentication for a token or key. This token or key can then be used as credentials for authenticating new requests. The API key service is enabled by default. The token service is enabled by default when TLS/SSL is enabled for HTTP. -$$$http-authentication$$$ +Review the following topics to learn about authentication in your {{es}} cluster. -$$$kerberos$$$ +:::{tip} +If you use {{ece}} or {{ech}}, then you can also manage authentication at the level of your [{{ece}} orchestrator](/deploy-manage/users-roles/cloud-enterprise-orchestrator.md) or [{{ecloud}} organization](/deploy-manage/users-roles/cloud-organization.md). -$$$multiple-authentication-providers$$$ - -$$$oidc$$$ - -$$$saml$$$ - -$$$token-authentication$$$ - - - -Review the following topics to learn about authentication in your Elasticsearch cluster: +If you use {{serverless-full}}, then you can only manage authentication at the [{{ecloud}} organization level](/deploy-manage/users-roles/cloud-organization.md). +::: ### Set up user authentication -* Learn about the available [realms](/deploy-manage/users-roles/cluster-or-deployment-auth/authentication-realms.md) that you can use to authenticate users -* Manage passwords for [built-in users](/deploy-manage/users-roles/cluster-or-deployment-auth/built-in-users.md) -* Manage users [natively](/deploy-manage/users-roles/cluster-or-deployment-auth/native.md) -* Integrate with external authentication providers using [external realms](/deploy-manage/users-roles/cluster-or-deployment-auth/external-authentication.md): - * [Active Directory](/deploy-manage/users-roles/cluster-or-deployment-auth/active-directory.md) - * [JWT](/deploy-manage/users-roles/cluster-or-deployment-auth/jwt.md) - * [Kerberos](/deploy-manage/users-roles/cluster-or-deployment-auth/kerberos.md) - * [LDAP](/deploy-manage/users-roles/cluster-or-deployment-auth/ldap.md) - * [OpenID Connect](/deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md) - * [SAML](/deploy-manage/users-roles/cluster-or-deployment-auth/saml.md) - * [PKI](/deploy-manage/users-roles/cluster-or-deployment-auth/pki.md) - * [Implement a custom realm](/deploy-manage/users-roles/cluster-or-deployment-auth/custom.md) -* Configure [file-based authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/file-based.md) -* Enable [anonymous access](/deploy-manage/users-roles/cluster-or-deployment-auth/anonymous-access.md) -* Set up a [user access agreement](/deploy-manage/users-roles/cluster-or-deployment-auth/access-agreement.md) +* Set up an authentication method: + * Learn about the available [realms](/deploy-manage/users-roles/cluster-or-deployment-auth/authentication-realms.md) that you can use to authenticate users. + * Manage passwords for [default users](/deploy-manage/users-roles/cluster-or-deployment-auth/built-in-users.md). + * Manage users using [internal realms](/deploy-manage/users-roles/cluster-or-deployment-auth/internal-authentication.md): + * Manage users [natively](/deploy-manage/users-roles/cluster-or-deployment-auth/native.md) + * Configure [file-based authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/file-based.md) + * Integrate with external authentication providers using [external realms](/deploy-manage/users-roles/cluster-or-deployment-auth/external-authentication.md): + * [Active Directory](/deploy-manage/users-roles/cluster-or-deployment-auth/active-directory.md) + * [JWT](/deploy-manage/users-roles/cluster-or-deployment-auth/jwt.md) + * [Kerberos](/deploy-manage/users-roles/cluster-or-deployment-auth/kerberos.md) + * [LDAP](/deploy-manage/users-roles/cluster-or-deployment-auth/ldap.md) + * [OpenID Connect](/deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md) + * [SAML](/deploy-manage/users-roles/cluster-or-deployment-auth/saml.md) + * [PKI](/deploy-manage/users-roles/cluster-or-deployment-auth/pki.md) + * [Implement a custom realm](/deploy-manage/users-roles/cluster-or-deployment-auth/custom.md) +* Configure [authentication mechanisms for {{kib}}](kibana-authentication.md). +* Enable [anonymous access](/deploy-manage/users-roles/cluster-or-deployment-auth/anonymous-access.md). +* Set up a [user access agreement](/deploy-manage/users-roles/cluster-or-deployment-auth/access-agreement.md). ### Advanced topics * Learn about [internal users](/deploy-manage/users-roles/cluster-or-deployment-auth/internal-users.md), which are responsible for the operations that take place inside an Elasticsearch cluster. -* Learn about [service accounts](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md), which are used for integration with external services that connect to Elasticsearch -* Learn about the [services used for token-based authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/token-based-authentication-services.md) -* Learn about the [services used by orchestrators](/deploy-manage/users-roles/cluster-or-deployment-auth/operator-privileges.md) (applies to {{ece}}, {{ech}}, and {{eck}}) -* Manage [user profiles](/deploy-manage/users-roles/cluster-or-deployment-auth/user-profiles.md) -* Learn about [user lookup technologies](/deploy-manage/users-roles/cluster-or-deployment-auth/looking-up-users-without-authentication.md) -* [Manage the user cache](/deploy-manage/users-roles/cluster-or-deployment-auth/controlling-user-cache.md) +* Learn about [service accounts](/deploy-manage/users-roles/cluster-or-deployment-auth/service-accounts.md), which are used for integration with external services that connect to Elasticsearch. +* Learn about the [services used for token-based authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/token-based-authentication-services.md). +* Learn about the [services used by orchestrators](/deploy-manage/users-roles/cluster-or-deployment-auth/operator-privileges.md). +* Manage [user profiles](/deploy-manage/users-roles/cluster-or-deployment-auth/user-profiles.md). +* Learn about [user lookup technologies](/deploy-manage/users-roles/cluster-or-deployment-auth/looking-up-users-without-authentication.md). +* [Manage the user cache](/deploy-manage/users-roles/cluster-or-deployment-auth/controlling-user-cache.md). * Manage authentication for [multiple clusters](/deploy-manage/users-roles/cluster-or-deployment-auth/manage-authentication-for-multiple-clusters.md) using {{stack}} configuration policies ({{eck}} only) diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/user-roles.md b/deploy-manage/users-roles/cluster-or-deployment-auth/user-roles.md index 8ab0b9ab52..b03cc11823 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/user-roles.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/user-roles.md @@ -83,7 +83,7 @@ The method for assigning roles to users varies depending on which realms you use The {{security-features}} also provide an attribute-based access control (ABAC) mechanism, which enables you to use attributes to restrict access to documents in search queries and aggregations. For example, you can assign attributes to users and documents, then implement an access policy in a role definition. Users with that role can read a specific document only if they have all the required attributes. -For more information, see [Document-level attribute-based access control with X-Pack 6.1](https://www.elastic.co/blog/attribute-based-access-control-with-xpack). +For more information, see [Document-level attribute-based access control with {{es}}](https://www.elastic.co/blog/attribute-based-access-control-elasticsearch). diff --git a/explore-analyze/report-and-share.md b/explore-analyze/report-and-share.md index 3a699a3cd5..390b9133ae 100644 --- a/explore-analyze/report-and-share.md +++ b/explore-analyze/report-and-share.md @@ -56,7 +56,7 @@ When sharing an object with unsaved changes, you get a temporary link that might To access the object shared with the link, users need to authenticate. -Anonymous users can also access the link if you have configured [Anonymous authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md#anonymous-authentication) and your anonymous service account has privileges to access what you want to share. +Anonymous users can also access the link if you have configured [Anonymous authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md#anonymous-authentication) and your anonymous service account has privileges to access what you want to share. :::{image} ../images/share-dashboard.gif :alt: getting a shareable link for a dashboard diff --git a/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-users-and-roles.md b/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-users-and-roles.md index c42f06ae36..d4bd8cf843 100644 --- a/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-users-and-roles.md +++ b/raw-migrated-files/cloud-on-k8s/cloud-on-k8s/k8s-users-and-roles.md @@ -33,111 +33,6 @@ spec: ``` - -## Creating custom users [k8s_creating_custom_users] - -::::{warning} -Do not run the `elasticsearch-service-tokens` command inside an Elasticsearch Pod managed by the operator. This would overwrite the service account tokens used internally to authenticate the Elastic stack applications. -:::: - - -### Native realm [k8s_native_realm] - -You can create custom users in the [Elasticsearch native realm](https://www.elastic.co/guide/en/elasticsearch/reference/current/native-realm.html) using [Elasticsearch user management APIs](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-security). - - -### File realm [k8s_file_realm] - -Custom users can also be created by providing the desired [file realm content](https://www.elastic.co/guide/en/elasticsearch/reference/current/file-realm.html) or a username and password in Kubernetes secrets, referenced in the Elasticsearch resource. - -```yaml -apiVersion: elasticsearch.k8s.elastic.co/v1 -kind: Elasticsearch -metadata: - name: elasticsearch-sample -spec: - version: 8.16.1 - auth: - fileRealm: - - secretName: my-filerealm-secret-1 - - secretName: my-filerealm-secret-2 - nodeSets: - - name: default - count: 1 -``` - -You can reference several secrets in the Elasticsearch specification. ECK aggregates their content into a single secret, mounted in every Elasticsearch Pod. - -Referenced secrets may be of one of two types: - -1. a combination of username and password as in [Kubernetes basic authentication secrets](https://kubernetes.io/docs/concepts/configuration/secret/#basic-authentication-secret) -2. a raw file realm content secret - -A basic authentication secret can optionally also contain a `roles` file. It must contain a comma separated list of roles to be associated with the user. The following example illustrates this combination: - -```yaml -apiVersion: v1 -kind: Secret -metadata: - name: secret-basic-auth -type: kubernetes.io/basic-auth -stringData: - username: rdeniro # required field for kubernetes.io/basic-auth - password: mypassword # required field for kubernetes.io/basic-auth - roles: kibana_admin,ingest_admin # optional, not part of kubernetes.io/basic-auth -``` - -::::{note} -If you specify the password for the `elastic` user through such a basic authentication secret then the secret holding the password described in [Default elastic user](../../../deploy-manage/users-roles/cluster-or-deployment-auth/native.md#k8s-default-elastic-user) will not be created by the operator. -:::: - - -The second option, a file realm secret, is composed of 2 entries. You can provide either one entry or both entries in each secret: - -* `users`: content of the `users` file. It specifies user names and password hashes, as described in the [file realm documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/file-realm.html). -* `users_roles`: content of the `users_roles` file. It associates each role to a list of users, as described in the [file realm documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/file-realm.html). - -If you specify multiple users with the same name in more than one secret, the last one takes precedence. If you specify multiple roles with the same name in more than one secret, a single entry per role is derived from the concatenation of its corresponding users from all secrets. - -The following Secret specifies three users and their respective roles: - -```yaml -kind: Secret -apiVersion: v1 -metadata: - name: my-filerealm-secret -stringData: - users: |- - rdeniro:$2a$10$BBJ/ILiyJ1eBTYoRKxkqbuDEdYECplvxnqQ47uiowE7yGqvCEgj9W - alpacino:$2a$10$cNwHnElYiMYZ/T3K4PvzGeJ1KbpXZp2PfoQD.gfaVdImnHOwIuBKS - jacknich:{PBKDF2}50000$z1CLJt0MEFjkIK5iEfgvfnA6xq7lF25uasspsTKSo5Q=$XxCVLbaKDimOdyWgLCLJiyoiWpA/XDMe/xtVgn1r5Sg= - users_roles: |- - admin:rdeniro - power_user:alpacino,jacknich - user:jacknich -``` - -You can populate the content of both `users` and `users_roles` using the [elasticsearch-users](https://www.elastic.co/guide/en/elasticsearch/reference/current/users-command.html) tool. - -For example, invoking the tool in a Docker container: - -```sh -# create a folder with the 2 files -mkdir filerealm -touch filerealm/users filerealm/users_roles - -# create user 'myuser' with role 'monitoring_user' -docker run \ - -v $(pwd)/filerealm:/usr/share/elasticsearch/config \ - docker.elastic.co/elasticsearch/elasticsearch:8.16.1 \ - bin/elasticsearch-users useradd myuser -p mypassword -r monitoring_user - -# create a Kubernetes secret with the file realm content -kubectl create secret generic my-file-realm-secret --from-file filerealm -``` - - - ## Creating custom roles [k8s_creating_custom_roles] [Roles](https://www.elastic.co/guide/en/elasticsearch/reference/current/defining-roles.html) can be specified using the [Role management API](https://www.elastic.co/guide/en/elasticsearch/reference/current/defining-roles.html#roles-management-api), or the [Role management UI in Kibana](https://www.elastic.co/guide/en/elasticsearch/reference/current/defining-roles.html#roles-management-ui). diff --git a/raw-migrated-files/elasticsearch/elasticsearch-reference/file-realm.md b/raw-migrated-files/elasticsearch/elasticsearch-reference/file-realm.md deleted file mode 100644 index ff9dde5a97..0000000000 --- a/raw-migrated-files/elasticsearch/elasticsearch-reference/file-realm.md +++ /dev/null @@ -1,89 +0,0 @@ -# File-based user authentication [file-realm] - -You can manage and authenticate users with the built-in `file` realm. With the `file` realm, users are defined in local files on each node in the cluster. - -::::{important} -As the administrator of the cluster, it is your responsibility to ensure the same users are defined on every node in the cluster. The {{stack}} {{security-features}} do not deliver any mechanism to guarantee this. You should also be aware that you cannot add or manage users in the `file` realm via the [user APIs](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-security) and you cannot add or manage them in {{kib}} on the **Management / Security / Users** page -:::: - - -The `file` realm is very useful as a fallback or recovery realm. For example in cases where the cluster is unresponsive or the security index is unavailable, or when you forget the password for your administrative users. In this type of scenario, the `file` realm is a convenient way out - you can define a new `admin` user in the `file` realm and use it to log in and reset the credentials of all other users. - -To define users, the {{security-features}} provide the [users](https://www.elastic.co/guide/en/elasticsearch/reference/current/users-command.html) command-line tool. This tool enables you to add and remove users, assign user roles, and manage user passwords. - -## Configuring a file realm [file-realm-configuration] - -You don’t need to explicitly configure a `file` realm. The `file` and `native` realms are added to the realm chain by default. Unless configured otherwise, the `file` realm is added first, followed by the `native` realm. - -::::{important} -While it is possible to define multiple instances of some other realms, you can define only *one* `file` realm per node. -:::: - - -All the data about the users for the `file` realm is stored in two files on each node in the cluster: `users` and `users_roles`. Both files are located in `ES_PATH_CONF` and are read on startup. - -::::{important} -The `users` and `users_roles` files are managed locally by the node and are **not** managed globally by the cluster. This means that with a typical multi-node cluster, the exact same changes need to be applied on each and every node in the cluster. - -A safer approach would be to apply the change on one of the nodes and have the files distributed or copied to all other nodes in the cluster (either manually or using a configuration management system such as Puppet or Chef). - -:::: - - -1. (Optional) Add a realm configuration to `elasticsearch.yml` under the `xpack.security.authc.realms.file` namespace. At a minimum, you must set the realm’s `order` attribute. - - For example, the following snippet shows a `file` realm configuration that sets the `order` to zero so the realm is checked first: - - ```yaml - xpack: - security: - authc: - realms: - file: - file1: - order: 0 - ``` - - ::::{note} - You can configure only one file realm on {{es}} nodes. - :::: - -2. Restart {{es}}. -3. Add user information to the `ES_PATH_CONF/users` file on each node in the cluster. - - The `users` file stores all the users and their passwords. Each line in the file represents a single user entry consisting of the username and **hashed** and **salted** password. - - ```bash - rdeniro:$2a$10$BBJ/ILiyJ1eBTYoRKxkqbuDEdYECplvxnqQ47uiowE7yGqvCEgj9W - alpacino:$2a$10$cNwHnElYiMYZ/T3K4PvzGeJ1KbpXZp2PfoQD.gfaVdImnHOwIuBKS - jacknich:{PBKDF2}50000$z1CLJt0MEFjkIK5iEfgvfnA6xq7lF25uasspsTKSo5Q=$XxCVLbaKDimOdyWgLCLJiyoiWpA/XDMe/xtVgn1r5Sg= - ``` - - ::::{note} - To limit exposure to credential theft and mitigate credential compromise, the file realm stores passwords and caches user credentials according to security best practices. By default, a hashed version of user credentials is stored in memory, using a salted `sha-256` hash algorithm and a hashed version of passwords is stored on disk salted and hashed with the `bcrypt` hash algorithm. To use different hash algorithms, see [User cache and password hash algorithms](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-settings.html#hashing-settings). - :::: - - - While it is possible to modify the `users` files directly using any standard text editor, we strongly recommend using the [*elasticsearch-users*](https://www.elastic.co/guide/en/elasticsearch/reference/current/users-command.html) tool to apply the required changes. - - ::::{important} - As the administrator of the cluster, it is your responsibility to ensure the same users are defined on every node in the cluster. The {{es}} {{security-features}} do not deliver any mechanisms to guarantee this. - :::: - -4. Add role information to the `ES_PATH_CONF/users_roles` file on each node in the cluster. - - The `users_roles` file stores the roles associated with the users. For example: - - ```shell - admin:rdeniro - power_user:alpacino,jacknich - user:jacknich - ``` - - Each row maps a role to a comma-separated list of all the users that are associated with that role. - - You can use the [*elasticsearch-users*](https://www.elastic.co/guide/en/elasticsearch/reference/current/users-command.html) tool to update this file. You must ensure that the same changes are made on every node in the cluster. - -5. (Optional) Change how often the `users` and `users_roles` files are checked. - - By default, {{es}} checks these files for changes every 5 seconds. You can change this default behavior by changing the `resource.reload.interval.high` setting in the `elasticsearch.yml` file (as this is a common setting in {{es}}, changing its value may effect other schedules in the system). diff --git a/raw-migrated-files/elasticsearch/elasticsearch-reference/kerberos-realm.md b/raw-migrated-files/elasticsearch/elasticsearch-reference/kerberos-realm.md index f86ede2d4e..3f67a91145 100644 --- a/raw-migrated-files/elasticsearch/elasticsearch-reference/kerberos-realm.md +++ b/raw-migrated-files/elasticsearch/elasticsearch-reference/kerberos-realm.md @@ -173,7 +173,7 @@ To configure a Kerberos realm in {{es}}: ### Configure Kibana for Kerberos [kerberos-realm-kibana] -If you want to use Kerberos to authenticate via your browser and {{kib}}, you need to enable the relevant authentication provider in {{kib}} configuration. See [kerberos single sign-on](../../../deploy-manage/users-roles/cluster-or-deployment-auth/user-authentication.md#kerberos) +If you want to use Kerberos to authenticate via your browser and {{kib}}, you need to enable the relevant authentication provider in {{kib}} configuration. See [kerberos single sign-on](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md#kerberos) diff --git a/raw-migrated-files/elasticsearch/elasticsearch-reference/native-realm.md b/raw-migrated-files/elasticsearch/elasticsearch-reference/native-realm.md index 8982ab4c40..4d3decb266 100644 --- a/raw-migrated-files/elasticsearch/elasticsearch-reference/native-realm.md +++ b/raw-migrated-files/elasticsearch/elasticsearch-reference/native-realm.md @@ -38,6 +38,4 @@ You can configure a `native` realm in the `xpack.security.authc.realms.native` n The {{stack}} {{security-features}} enable you to easily manage users in {{kib}} on the **Management / Security / Users** page. -Alternatively, you can manage users through the `user` API. For more information and examples, see [Users](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-security). - - +Alternatively, you can manage users through the `user` API. For more information and examples, see [Users](https://www.elastic.co/docs/api/doc/elasticsearch/group/endpoint-security). \ No newline at end of file diff --git a/raw-migrated-files/elasticsearch/elasticsearch-reference/setting-up-authentication.md b/raw-migrated-files/elasticsearch/elasticsearch-reference/setting-up-authentication.md deleted file mode 100644 index dda6a355f4..0000000000 --- a/raw-migrated-files/elasticsearch/elasticsearch-reference/setting-up-authentication.md +++ /dev/null @@ -1,37 +0,0 @@ -# User authentication [setting-up-authentication] - -Authentication identifies an individual. To gain access to restricted resources, a user must prove their identity, via passwords, credentials, or some other means (typically referred to as authentication tokens). - -The {{stack}} authenticates users by identifying the users behind the requests that hit the cluster and verifying that they are who they claim to be. The authentication process is handled by one or more authentication services called [*realms*](../../../deploy-manage/users-roles/cluster-or-deployment-auth/authentication-realms.md). - -You can use the native support for managing and authenticating users, or integrate with external user management systems such as LDAP and Active Directory. - -The {{stack-security-features}} provide built-in realms such as `native`,`ldap`, `active_directory`, `pki`, `file`, `saml`, `kerberos`, `oidc`, and `jwt`. If none of the built-in realms meet your needs, you can also build your own custom realm and plug it into the {{stack}}. - -When {{security-features}} are enabled, depending on the realms you’ve configured, you must attach your user credentials to the requests sent to {{es}}. For example, when using realms that support usernames and passwords you can simply attach [basic auth](https://en.wikipedia.org/wiki/Basic_access_authentication) header to the requests. - -The {{security-features}} provide two services: the token service and the API key service. You can use these services to exchange the current authentication for a token or key. This token or key can then be used as credentials for authenticating new requests. The API key service is enabled by default. The token service is enabled by default when TLS/SSL is enabled for HTTP. - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/raw-migrated-files/kibana/kibana/elasticsearch-mutual-tls.md b/raw-migrated-files/kibana/kibana/elasticsearch-mutual-tls.md index 08dbb19b67..bab7457452 100644 --- a/raw-migrated-files/kibana/kibana/elasticsearch-mutual-tls.md +++ b/raw-migrated-files/kibana/kibana/elasticsearch-mutual-tls.md @@ -124,5 +124,5 @@ If you haven’t already, start {{kib}} and connect it to {{es}} using the [enro 9. Restart {{kib}}. -These steps enable {{kib}} to authenticate to {{es}} using a certificate. However, end users will only be able to authenticate to {{kib}} with a username and password. To allow end users to authenticate to {{kib}} using a client certificate, see [{{kib}} PKI authentication](kibana-authentication.md#pki-authentication). +These steps enable {{kib}} to authenticate to {{es}} using a certificate. However, end users will only be able to authenticate to {{kib}} with a username and password. To allow end users to authenticate to {{kib}} using a client certificate, see [{{kib}} PKI authentication](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md#pki-authentication). diff --git a/raw-migrated-files/toc.yml b/raw-migrated-files/toc.yml index ea25216be3..315d0e1131 100644 --- a/raw-migrated-files/toc.yml +++ b/raw-migrated-files/toc.yml @@ -469,7 +469,6 @@ toc: - file: elasticsearch/elasticsearch-reference/esql-using.md - file: elasticsearch/elasticsearch-reference/field-and-document-access-control.md - file: elasticsearch/elasticsearch-reference/field-level-security.md - - file: elasticsearch/elasticsearch-reference/file-realm.md - file: elasticsearch/elasticsearch-reference/fips-140-compliance.md - file: elasticsearch/elasticsearch-reference/how-monitoring-works.md - file: elasticsearch/elasticsearch-reference/index-mgmt.md @@ -503,7 +502,6 @@ toc: - file: elasticsearch/elasticsearch-reference/security-files.md - file: elasticsearch/elasticsearch-reference/security-limitations.md - file: elasticsearch/elasticsearch-reference/semantic-search-inference.md - - file: elasticsearch/elasticsearch-reference/setting-up-authentication.md - file: elasticsearch/elasticsearch-reference/setup.md - file: elasticsearch/elasticsearch-reference/shard-allocation-filtering.md - file: elasticsearch/elasticsearch-reference/shard-request-cache.md @@ -525,7 +523,6 @@ toc: - file: kibana/kibana/elasticsearch-mutual-tls.md - file: kibana/kibana/esql.md - file: kibana/kibana/install.md - - file: kibana/kibana/kibana-authentication.md - file: kibana/kibana/kibana-role-management.md - file: kibana/kibana/logging-settings.md - file: kibana/kibana/management.md