diff --git a/deploy-manage/deploy/cloud-enterprise/edit-stack-settings-apm.md b/deploy-manage/deploy/cloud-enterprise/edit-stack-settings-apm.md index f39bb89a40..e4572e73ba 100644 --- a/deploy-manage/deploy/cloud-enterprise/edit-stack-settings-apm.md +++ b/deploy-manage/deploy/cloud-enterprise/edit-stack-settings-apm.md @@ -21,7 +21,7 @@ Starting in {{stack}} version 8.0, how you change APM settings and the settings Standalone APM Server (legacy) : Deployments created prior to {{stack}} version 8.0 are in legacy mode. Upgrading to or past {{stack}} 8.0 does not remove you from legacy mode. - Check [Edit standalone APM settings (legacy)](#ece-edit-apm-standalone-settings-ece)for information on how to configure Elastic APM in this mode. + Check [Edit standalone APM settings (legacy)](#ece-edit-apm-standalone-settings-ece) for information on how to configure Elastic APM in this mode. To learn more about the differences between these modes, or to switch from Standalone APM Server (legacy) mode to {{fleet}}-managed, check [Switch to the Elastic APM integration](/solutions/observability/apm/switch-to-elastic-apm-integration.md). diff --git a/deploy-manage/deploy/cloud-on-k8s/_snippets/es-config.md b/deploy-manage/deploy/cloud-on-k8s/_snippets/es-config.md new file mode 100644 index 0000000000..4936ab799f --- /dev/null +++ b/deploy-manage/deploy/cloud-on-k8s/_snippets/es-config.md @@ -0,0 +1,39 @@ +{{es}} settings that are typically defined in the `elasticsearch.yml` configuration file can be specified for a set of nodes in the `spec.nodeSets[?].config` section of the {{es}} resource manifest. + +Some settings are managed by ECK. It is not recommended to change these managed settings. For a complete list, refer to [Settings managed by ECK](/deploy-manage/deploy/cloud-on-k8s/settings-managed-by-eck.md). + +```yaml +spec: + nodeSets: + - name: masters + count: 3 + config: + # On Elasticsearch versions before 7.9.0, replace the node.roles configuration with the following: + # node.master: true + node.roles: ["master"] + xpack.ml.enabled: true + - name: data + count: 10 + config: + # On Elasticsearch versions before 7.9.0, replace the node.roles configuration with the following: + # node.master: false + # node.data: true + # node.ingest: true + # node.ml: true + # node.transform: true + node.roles: ["data", "ingest", "ml", "transform"] +``` + +:::{warning} +ECK parses {{es}} configuration and normalizes it to YAML. Consequently, some {{es}} configuration schema are impossible to express with ECK and, therefore, must be set using [dynamic cluster settings](/deploy-manage/deploy/self-managed/configure-elasticsearch.md#cluster-setting-types). For example: +```yaml +spec: + nodeSets: + - name: data + # ... + config: + cluster.max_shards_per_node: 1000 + cluster.max_shards_per_node.frozen: 1000 # This won't work because cluster.max_shards_per_node is defined as a scalar value on the previous line + # ... +``` +::: \ No newline at end of file diff --git a/deploy-manage/deploy/cloud-on-k8s/_snippets/kib-config.md b/deploy-manage/deploy/cloud-on-k8s/_snippets/kib-config.md new file mode 100644 index 0000000000..fb6209c224 --- /dev/null +++ b/deploy-manage/deploy/cloud-on-k8s/_snippets/kib-config.md @@ -0,0 +1,18 @@ +You can add your own {{kib}} settings to the `spec.config` section. + +The following example demonstrates how to set the [`elasticsearch.requestHeadersWhitelist`](kibana://reference/configuration-reference/general-settings.md#elasticsearch-requestheaderswhitelist) configuration option. + +```yaml +apiVersion: kibana.k8s.elastic.co/v1 +kind: Kibana +metadata: + name: kibana-sample +spec: + version: 8.16.1 + count: 1 + elasticsearchRef: + name: "elasticsearch-sample" + config: + elasticsearch.requestHeadersWhitelist: + - authorization +``` \ No newline at end of file diff --git a/deploy-manage/deploy/cloud-on-k8s/elastic-stack-configuration-policies.md b/deploy-manage/deploy/cloud-on-k8s/elastic-stack-configuration-policies.md index e2e5999f0a..132a8bd805 100644 --- a/deploy-manage/deploy/cloud-on-k8s/elastic-stack-configuration-policies.md +++ b/deploy-manage/deploy/cloud-on-k8s/elastic-stack-configuration-policies.md @@ -28,7 +28,7 @@ Starting from ECK `2.6.1` and {{es}} `8.6.1`, {{stack}} configuration policies a * [Index templates](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-indices-put-index-template) * [Components templates](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-component-template) * [Role mappings](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-security-put-role-mapping) -* [{{es}} Configuration](/deploy-manage/deploy/self-managed/configure-elasticsearch.md) (configuration settings for {{es}} that will go into `elasticsearch.yml`) [ECK 2.11.0] +* [{{es}} Configuration](/deploy-manage/deploy/self-managed/configure-elasticsearch.md) (configuration settings for {{es}} that will go into [`elasticsearch.yml`](/deploy-manage/stack-settings.md)) [ECK 2.11.0] * [{{es}} Secure Settings](../../security/secure-settings.md) [ECK 2.11.0] * [Secret Mounts](#k8s-stack-config-policy-specifics-secret-mounts) [ECK 2.11.0] @@ -58,13 +58,13 @@ At least one of `spec.elasticsearch` or `spec.kibana` needs to be defined with a * `indexLifecyclePolicies` are index lifecycle policies, to automatically manage the index lifecycle. * `indexTemplates.componentTemplates` are component templates that are building blocks for constructing index templates that specify index mappings, settings, and aliases. * `indexTemplates.composableIndexTemplates` are index templates to define settings, mappings, and aliases that can be applied automatically to new indices. - * `config` are the settings that go into the `elasticsearch.yml` file. + * `config` are the settings that go into the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file. * `secretMounts` are the additional user created secrets that need to be mounted to the {{es}} Pods. * `secureSettings` is a list of Secrets containing Secure Settings to inject into the keystore(s) of the {{es}} cluster(s) to which this policy applies, similar to the [{{es}} Secure Settings](../../security/secure-settings.md). * `spec.kibana` describes the settings to configure for {{kib}}. - * `config` are the settings that go into the `kibana.yml` file. + * `config` are the settings that go into the [`kibana.yml`](/deploy-manage/stack-settings.md) file. * `secureSettings` is a list of Secrets containing Secure Settings to inject into the keystore(s) of the {{kib}} instance(s) to which this policy applies, similar to the [{{kib}} Secure Settings](../../security/k8s-secure-settings.md). diff --git a/deploy-manage/deploy/cloud-on-k8s/k8s-kibana-advanced-configuration.md b/deploy-manage/deploy/cloud-on-k8s/k8s-kibana-advanced-configuration.md index 1c2aaebb80..3e6e26c265 100644 --- a/deploy-manage/deploy/cloud-on-k8s/k8s-kibana-advanced-configuration.md +++ b/deploy-manage/deploy/cloud-on-k8s/k8s-kibana-advanced-configuration.md @@ -57,24 +57,8 @@ Check [Set compute resources for {{kib}}, Elastic Maps Server, APM Server and Lo ## {{kib}} configuration [k8s-kibana-configuration] -You can add your own {{kib}} settings to the `spec.config` section. - -The following example demonstrates how to set the [`elasticsearch.requestHeadersWhitelist`](kibana://reference/configuration-reference/general-settings.md#elasticsearch-requestheaderswhitelist) configuration option. - -```yaml -apiVersion: kibana.k8s.elastic.co/v1 -kind: Kibana -metadata: - name: kibana-sample -spec: - version: 8.16.1 - count: 1 - elasticsearchRef: - name: "elasticsearch-sample" - config: - elasticsearch.requestHeadersWhitelist: - - authorization -``` +:::{include} _snippets/kib-config.md +::: ## Scale out a {{kib}} deployment [k8s-kibana-scaling] diff --git a/deploy-manage/deploy/cloud-on-k8s/node-configuration.md b/deploy-manage/deploy/cloud-on-k8s/node-configuration.md index c630b9161d..4a4676c015 100644 --- a/deploy-manage/deploy/cloud-on-k8s/node-configuration.md +++ b/deploy-manage/deploy/cloud-on-k8s/node-configuration.md @@ -8,45 +8,7 @@ mapped_pages: # Node configuration [k8s-node-configuration] -Any setting defined in the `elasticsearch.yml` configuration file can also be defined for a set of {{es}} nodes in the `spec.nodeSets[?].config` section. - -Some settings are managed by ECK, it is not recommended to change them, refer to [Settings managed by ECK](settings-managed-by-eck.md) for more details. - -```yaml -spec: - nodeSets: - - name: masters - count: 3 - config: - # On Elasticsearch versions before 7.9.0, replace the node.roles configuration with the following: - # node.master: true - node.roles: ["master"] - xpack.ml.enabled: true - - name: data - count: 10 - config: - # On Elasticsearch versions before 7.9.0, replace the node.roles configuration with the following: - # node.master: false - # node.data: true - # node.ingest: true - # node.ml: true - # node.transform: true - node.roles: ["data", "ingest", "ml", "transform"] -``` - -::::{warning} -ECK parses {{es}} configuration and normalizes it to YAML. Consequently, some {{es}} configuration schema are impossible to express with ECK and, therefore, must be set using [dynamic cluster settings](/deploy-manage/deploy/self-managed/configure-elasticsearch.md#cluster-setting-types). For example: -```yaml -spec: - nodeSets: - - name: data - # ... - config: - cluster.max_shards_per_node: 1000 - cluster.max_shards_per_node.frozen: 1000 # This won't work because cluster.max_shards_per_node is defined as a scalar value on the previous line - # ... -``` -:::: - -For more information on {{es}} settings, check [Configuring Elasticsearch](/deploy-manage/deploy/self-managed/configure-elasticsearch.md). +:::{include} _snippets/es-config.md +::: +For more information on {{es}} settings, check [Configuring Elasticsearch](/deploy-manage/deploy/self-managed/configure-elasticsearch.md). \ No newline at end of file diff --git a/deploy-manage/deploy/elastic-cloud/edit-stack-settings.md b/deploy-manage/deploy/elastic-cloud/edit-stack-settings.md index 073bfed222..5531400f87 100644 --- a/deploy-manage/deploy/elastic-cloud/edit-stack-settings.md +++ b/deploy-manage/deploy/elastic-cloud/edit-stack-settings.md @@ -17,45 +17,11 @@ mapped_pages: # Edit {{stack}} settings -% What needs to be done: Refine +From the {{ecloud}} Console you can customize {{es}}, {{kib}}, and related products to suit your needs. These editors append your changes to the appropriate YAML configuration file and they affect all users of that cluster. -% Use migrated content from existing pages that map to this page: +## Available settings -% - [ ] ./raw-migrated-files/cloud/cloud/ec-add-user-settings.md -% - [ ] ./raw-migrated-files/cloud/cloud/ec-editing-user-settings.md -% - [ ] ./raw-migrated-files/cloud/cloud-heroku/ech-add-user-settings.md -% - [ ] ./raw-migrated-files/cloud/cloud/ec-manage-kibana-settings.md -% - [ ] ./raw-migrated-files/cloud/cloud-heroku/ech-manage-kibana-settings.md -% - [ ] ./raw-migrated-files/cloud/cloud-heroku/ech-editing-user-settings.md -% - [ ] ./raw-migrated-files/cloud/cloud/ec-manage-apm-settings.md -% - [ ] ./raw-migrated-files/cloud/cloud-heroku/ech-manage-apm-settings.md -% - [ ] ./raw-migrated-files/cloud/cloud/ec-manage-appsearch-settings.md -% Notes: specify cluster 8.x or lower -% - [ ] ./raw-migrated-files/cloud/cloud/ec-manage-enterprise-search-settings.md -% Notes: specify cluster 8.x or lower - -$$$ec-add-user-settings$$$ - -$$$ech-es-elasticsearch-settings$$$ - -$$$xpack-monitoring-history-duration$$$ - -$$$ech-edit-apm-standalone-settings$$$ - -$$$ech-apm-settings$$$ - -$$$csp-strict$$$ - -$$$ec-appsearch-settings$$$ - -$$$ec-es-elasticsearch-settings$$$ - -From the {{ecloud}} Console you can customize {{es}}, {{kib}}, and related products to suit your needs. These editors append your changes to the appropriate YAML configuration file and they affect all users of that cluster. In each editor you can: - - -## Edit {{es}} user settings [ec-add-user-settings] - -Change how {{es}} runs by providing your own user settings. {{ech}} appends these settings to each node’s `elasticsearch.yml` configuration file. +### Elasticsearch settings :::{important} If a feature requires both standard `elasticsearch.yml` settings and [secure settings](/deploy-manage/security/secure-settings.md), configure the secure settings first. Updating standard user settings can trigger a cluster rolling restart, and if the required secure settings are not yet in place, the nodes may fail to start. In contrast, adding secure settings does not trigger a restart. @@ -63,56 +29,38 @@ If a feature requires both standard `elasticsearch.yml` settings and [secure set {{ech}} automatically rejects `elasticsearch.yml` settings that could break your cluster. -For a list of supported settings, check [Supported {{es}} settings](elasticsearch://reference/elasticsearch/configuration-reference/index.md). - -::::{warning} -You can also update [dynamic cluster settings](../../../deploy-manage/deploy/self-managed/configure-elasticsearch.md#dynamic-cluster-setting) using {{es}}'s [update cluster settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings). However, {{ech}} doesn’t reject unsafe setting changes made using this API. Use it with caution. -:::: - - -To add or edit user settings: +For a list of supported settings, refer to the [{{es}} configuration reference](elasticsearch://reference/elasticsearch/configuration-reference/index.md). Settings supported on {{ech}} are indicated by an {{ecloud}} icon (![logo cloud](https://doc-icons.s3.us-east-2.amazonaws.com/logo_cloud.svg "Supported on {{ecloud}}")). -1. Log in to the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body). -2. Find your deployment on the home page or on the **Hosted deployments** page, then select **Manage** to access its settings menus. - - On the **Hosted deployments** page you can narrow your deployments by name, ID, or choose from several other filters. To customize your view, use a combination of filters, or change the format from a grid to a list. +### Kibana settings -3. From your deployment menu, go to the **Edit** page. -4. In the **Elasticsearch** section, select **Manage user settings and extensions**. -5. Update the user settings. -6. Select **Save changes**. +{{ech}} supports most of the standard {{kib}} settings. -::::{note} -In some cases, you may get a warning saying "User settings are different across {{es}} instances". To fix this issue, ensure that your user settings (including the comments sections and whitespaces) are identical across all {{es}} nodes (not only the data tiers, but also the Master, Machine Learning, and Coordinating nodes). -:::: +Be aware that some settings that could break your cluster if set incorrectly and that the syntax might change between major versions. -## Edit {{kib}} user settings [ec-manage-kibana-settings] +For a list of supported settings, check [{{kib}} settings](kibana://reference/cloud/elastic-cloud-kibana-settings.md). -{{ech}} supports most of the standard {{kib}} and X-Pack settings. Through a YAML editor in the console, you can append {{kib}} properties to the `kibana.yml` file. Your changes to the configuration file are read on startup. +### APM settings -Be aware that some settings that could break your cluster if set incorrectly and that the syntax might change between major versions. +Refer to [APM configuration reference](/solutions/observability/apm/configure-apm-server.md) for information on how to configure the {{fleet}}-managed APM integration. -For a list of supported settings, check [{{kib}} settings](kibana://reference/cloud/elastic-cloud-kibana-settings.md). +## Edit settings [ec-add-user-settings] -To change {{kib}} settings: +To add or edit user settings: 1. Log in to the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body). 2. Find your deployment on the home page or on the **Hosted deployments** page, then select **Manage** to access its settings menus. On the **Hosted deployments** page you can narrow your deployments by name, ID, or choose from several other filters. To customize your view, use a combination of filters, or change the format from a grid to a list. -3. From your deployment menu, go to the **Edit** page. -4. In the **Kibana** section, select **Edit user settings**. For deployments with existing user settings, you may have to expand the **Edit kibana.yml** caret instead. -5. Update the user settings. -6. Select **Save changes**. - -Saving your changes initiates a configuration plan change that restarts {{kib}} automatically for you. +1. Under the deployment's name in the navigation menu, select **Edit**. +2. Look for the **Manage user settings and extensions** and **Edit user settings** links for each deployment, and select the one corresponding to the component you want to update, such as {{es}} or {{kib}}. +3. Apply the necessary settings in the **Users Settings** tab of the editor and select **Back** when finished. +4. Select **Save** to apply the changes to the deployment. Saving your changes initiates a configuration plan change that restarts the affected components for you. ::::{note} -If a setting is not supported by {{ech}}, you will get an error message when you try to save. +In some cases, you may get a warning saying "User settings are different across {{es}} instances". To fix this issue, ensure that your user settings (including the comments sections and whitespaces) are identical across all {{es}} nodes (not only the data tiers, but also the Master, Machine Learning, and Coordinating nodes). :::: -## Edit APM user settings [ec-manage-apm-settings] - -Change how Elastic APM runs by providing your own user settings. -Check [APM configuration reference](/solutions/observability/apm/configure-apm-server.md) for information on how to configure the {{fleet}}-managed APM integration. \ No newline at end of file +::::{warning} +You can also update [dynamic cluster settings](../../../deploy-manage/deploy/self-managed/configure-elasticsearch.md#dynamic-cluster-setting) using {{es}}'s [update cluster settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings). However, {{ech}} doesn’t reject unsafe setting changes made using this API. Use it with caution. +:::: \ No newline at end of file diff --git a/deploy-manage/deploy/self-managed/_snippets/auto-security-config-rpm-deb.md b/deploy-manage/deploy/self-managed/_snippets/auto-security-config-rpm-deb.md index 77bd9bfc80..9ea39cdd43 100644 --- a/deploy-manage/deploy/self-managed/_snippets/auto-security-config-rpm-deb.md +++ b/deploy-manage/deploy/self-managed/_snippets/auto-security-config-rpm-deb.md @@ -1,10 +1,10 @@ When you start {{es}} for the first time, it automatically performs the following security setup: * Generates [TLS certificates](#stack-security-certificates) for the [transport and HTTP layers](/deploy-manage/security/secure-cluster-communications.md#communication-channels) -* Applies TLS configuration settings to `elasticsearch.yml` +* Applies TLS configuration settings to [`elasticsearch.yml`](/deploy-manage/stack-settings.md) * Creates an enrollment token to securely connect {{kib}} to {{es}} -You can then start {{kib}} and enter the enrollment token, which is valid for 30 minutes. This token automatically applies the security settings from your {{es}} cluster, authenticates to {{es}} with the built-in `kibana` service account, and writes the security configuration to `kibana.yml`. +You can then start {{kib}} and enter the enrollment token, which is valid for 30 minutes. This token automatically applies the security settings from your {{es}} cluster, authenticates to {{es}} with the built-in `kibana` service account, and writes the security configuration to [`kibana.yml`](/deploy-manage/stack-settings.md). ::::{note} There are [some cases](/deploy-manage/security/self-auto-setup.md#stack-skip-auto-configuration) where security can’t be configured automatically because the node startup process detects that the node is already part of a cluster, or that security is already configured or explicitly disabled. diff --git a/deploy-manage/deploy/self-managed/_snippets/auto-security-config.md b/deploy-manage/deploy/self-managed/_snippets/auto-security-config.md index f47f164982..2fc0c9d2bb 100644 --- a/deploy-manage/deploy/self-managed/_snippets/auto-security-config.md +++ b/deploy-manage/deploy/self-managed/_snippets/auto-security-config.md @@ -1,11 +1,11 @@ When you start your first {{es}} node for the first time, it automatically performs the following security setup: * Generates [TLS certificates](#stack-security-certificates) for the [transport and HTTP layers](/deploy-manage/security/secure-cluster-communications.md#communication-channels) -* Applies TLS configuration settings to `elasticsearch.yml` +* Applies TLS configuration settings to [`elasticsearch.yml`](/deploy-manage/stack-settings.md) * Sets a password for the `elastic` superuser * Creates an enrollment token to securely connect {{kib}} to {{es}} -You can then start {{kib}} and enter the enrollment token, which is valid for 30 minutes. This token automatically applies the security settings from your {{es}} cluster, authenticates to {{es}} with the built-in `kibana` service account, and writes the security configuration to `kibana.yml`. +You can then start {{kib}} and enter the enrollment token, which is valid for 30 minutes. This token automatically applies the security settings from your {{es}} cluster, authenticates to {{es}} with the built-in `kibana` service account, and writes the security configuration to [`kibana.yml`](/deploy-manage/stack-settings.md). ::::{note} There are [some cases](/deploy-manage/security/self-auto-setup.md#stack-skip-auto-configuration) where security can’t be configured automatically because the node startup process detects that the node is already part of a cluster, or that security is already configured or explicitly disabled. diff --git a/deploy-manage/deploy/self-managed/_snippets/clean-up-multinode.md b/deploy-manage/deploy/self-managed/_snippets/clean-up-multinode.md index ebf2d77477..a4ec46887e 100644 --- a/deploy-manage/deploy/self-managed/_snippets/clean-up-multinode.md +++ b/deploy-manage/deploy/self-managed/_snippets/clean-up-multinode.md @@ -1,6 +1,6 @@ Perform the following steps on each node in the cluster: -1. Open `elasticsearch.yml` in a text editor. +1. Open [`elasticsearch.yml`](/deploy-manage/deploy/self-managed/configure-elasticsearch.md) in a text editor. 2. Comment out or remove the `cluster.initial_master_nodes` setting, if present. 3. Update the `discovery.seed_hosts` value so it contains the IP address and port of each of the master-eligible {{es}} nodes in the cluster. In the first node in the cluster, you need to add the `discovery.seed_hosts` setting manually. 4. Optionally, [restart the {{es}} service](/deploy-manage/maintenance/start-stop-services/start-stop-elasticsearch.md) to validate your configuration changes. diff --git a/deploy-manage/deploy/self-managed/_snippets/config-file-format.md b/deploy-manage/deploy/self-managed/_snippets/config-file-format.md new file mode 100644 index 0000000000..91d8e2189a --- /dev/null +++ b/deploy-manage/deploy/self-managed/_snippets/config-file-format.md @@ -0,0 +1,29 @@ +The configuration format is [YAML](https://yaml.org/). Here is an example of changing the path of the data and logs directories in {{es}}: + +```yaml +path: + data: /var/lib/elasticsearch + logs: /var/log/elasticsearch +``` + +Settings can also be flattened as follows: + +```yaml +path.data: /var/lib/elasticsearch +path.logs: /var/log/elasticsearch +``` + +In YAML, you can format non-scalar values as sequences: + +```yaml +discovery.seed_hosts: + - 192.168.1.10:9300 + - 192.168.1.11 + - seeds.mydomain.com +``` + +Though less common, you can also format non-scalar values as arrays: + +```yaml +discovery.seed_hosts: ["192.168.1.10:9300", "192.168.1.11", "seeds.mydomain.com"] +``` \ No newline at end of file diff --git a/deploy-manage/deploy/self-managed/_snippets/dynamic-settings.md b/deploy-manage/deploy/self-managed/_snippets/dynamic-settings.md new file mode 100644 index 0000000000..d39b9e80ed --- /dev/null +++ b/deploy-manage/deploy/self-managed/_snippets/dynamic-settings.md @@ -0,0 +1,18 @@ +You can configure and update dynamic settings on a running cluster using the [cluster update settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings). You can also configure dynamic settings locally on an unstarted or shut down node using `elasticsearch.yml`. + +Updates made using the cluster update settings API can be *persistent*, which apply across cluster restarts, or *transient*, which reset after a cluster restart. You can also reset transient or persistent settings by assigning them a `null` value using the API. + +If you configure the same setting using multiple methods, {{es}} applies the settings in following order of precedence: + +1. Transient setting +2. Persistent setting +3. `elasticsearch.yml`setting +4. Default setting value + +For example, you can apply a transient setting to override a persistent setting or `elasticsearch.yml` setting. However, a change to an `elasticsearch.yml` setting will not override a defined transient or persistent setting. + +::::{warning} +We no longer recommend using transient cluster settings. Use persistent cluster settings instead. If a cluster becomes unstable, transient settings can clear unexpectedly, resulting in a potentially undesired cluster configuration. +:::: + +In a self-managed cluster, you should use the [cluster update settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings) to configure dynamic cluster settings, and only use `elasticsearch.yml` for static cluster settings and node settings. The API doesn’t require a restart and ensures a setting’s value is the same on all nodes. diff --git a/deploy-manage/deploy/self-managed/_snippets/enable-auto-indices.md b/deploy-manage/deploy/self-managed/_snippets/enable-auto-indices.md index c249af5120..4bb78d01aa 100644 --- a/deploy-manage/deploy/self-managed/_snippets/enable-auto-indices.md +++ b/deploy-manage/deploy/self-managed/_snippets/enable-auto-indices.md @@ -2,7 +2,7 @@ This section is only required if you have previously changed `action.auto_create_index` from its default value. ::: -Some features automatically create indices within {{es}}. By default, {{es}} is configured to allow automatic index creation, and no additional steps are required. However, if you have disabled automatic index creation in {{es}}, you must configure [`action.auto_create_index`](elasticsearch://reference/elasticsearch/configuration-reference/index-management-settings.md#auto-create-index) in `elasticsearch.yml` to allow features to create the following indices: +Some features automatically create indices within {{es}}. By default, {{es}} is configured to allow automatic index creation, and no additional steps are required. However, if you have disabled automatic index creation in {{es}}, you must configure [`action.auto_create_index`](elasticsearch://reference/elasticsearch/configuration-reference/index-management-settings.md#auto-create-index) in [`elasticsearch.yml`](/deploy-manage/deploy/self-managed/configure-elasticsearch.md) to allow features to create the following indices: ```yaml action.auto_create_index: .monitoring*,.watches,.triggered_watches,.watcher-history*,.ml* diff --git a/deploy-manage/deploy/self-managed/_snippets/enroll-nodes.md b/deploy-manage/deploy/self-managed/_snippets/enroll-nodes.md index 8280759eb8..1d58f6f204 100644 --- a/deploy-manage/deploy/self-managed/_snippets/enroll-nodes.md +++ b/deploy-manage/deploy/self-managed/_snippets/enroll-nodes.md @@ -6,7 +6,7 @@ Before you enroll your new node, make sure that it is able to access the first n If you can't access the first node, then modify your network configuration before proceeding. ::: -1. Using a text editor, update the `cluster.name` in `elasticsearch.yml` to match the other nodes in your cluster. +1. Using a text editor, update the `cluster.name` in [`elasticsearch.yml`](/deploy-manage/deploy/self-managed/configure-elasticsearch.md) to match the other nodes in your cluster. :::{note} If this value isn't updated and you attempt to join an existing cluster, then the connection will fail with the following error: diff --git a/deploy-manage/deploy/self-managed/_snippets/env-var-setting-subs.md b/deploy-manage/deploy/self-managed/_snippets/env-var-setting-subs.md new file mode 100644 index 0000000000..032c6d0ded --- /dev/null +++ b/deploy-manage/deploy/self-managed/_snippets/env-var-setting-subs.md @@ -0,0 +1,14 @@ +Environment variables referenced with the `${...}` notation within the configuration file will be replaced with the value of the environment variable. For example: + +```yaml +node.name: ${HOSTNAME} +network.host: ${ES_NETWORK_HOST} +``` + +Values for environment variables must be simple strings. Use a comma-separated string to provide values that the component will parse as a list. For example, {{es}} will split the following string into a list of values for the `${HOSTNAME}` environment variable: + +```yaml +export HOSTNAME="host1,host2" +``` + +By default, configuration validation will fail if an environment variable used in the config file is not present when the component starts. This behavior can be changed by using a default value for the environment variable, using the `${MY_ENV_VAR:defaultValue}` syntax. \ No newline at end of file diff --git a/deploy-manage/deploy/self-managed/_snippets/join-existing-cluster.md b/deploy-manage/deploy/self-managed/_snippets/join-existing-cluster.md index 0b0c01a95d..8b26ab1d43 100644 --- a/deploy-manage/deploy/self-managed/_snippets/join-existing-cluster.md +++ b/deploy-manage/deploy/self-managed/_snippets/join-existing-cluster.md @@ -25,7 +25,7 @@ If you can't access the first node, then modify your network configuration befor Answer the `Do you want to continue` prompt with `yes` (`y`). The new {{es}} node will be reconfigured. -4. Open the new Elasticsearch instance's `elasticsearch.yml` file in a text editor. +4. Open the new Elasticsearch instance's [`elasticsearch.yml`](/deploy-manage/deploy/self-managed/configure-elasticsearch.md) file in a text editor. The `elasticsearch-reconfigure-node` tool has updated several settings. For example: diff --git a/deploy-manage/deploy/self-managed/_snippets/static-settings.md b/deploy-manage/deploy/self-managed/_snippets/static-settings.md new file mode 100644 index 0000000000..8ae011b561 --- /dev/null +++ b/deploy-manage/deploy/self-managed/_snippets/static-settings.md @@ -0,0 +1,3 @@ +Static settings can only be configured on an unstarted or shut down node using `elasticsearch.yml`. + +Static settings must be set on every relevant node in the cluster. \ No newline at end of file diff --git a/deploy-manage/deploy/self-managed/bootstrap-checks.md b/deploy-manage/deploy/self-managed/bootstrap-checks.md index 160374c70a..e72c023a15 100644 --- a/deploy-manage/deploy/self-managed/bootstrap-checks.md +++ b/deploy-manage/deploy/self-managed/bootstrap-checks.md @@ -203,7 +203,7 @@ $$$bootstrap-checks-xpack-role-mappings$$$ If you authenticate users with realms other than `native` or `file` realms, you must create role mappings. These role mappings define which roles are assigned to each user. -If you use files to manage the role mappings, you must configure a YAML file and copy it to each node in the cluster. By default, role mappings are stored in `ES_PATH_CONF/role_mapping.yml`. Alternatively, you can specify a different role mapping file for each type of realm and specify its location in the `elasticsearch.yml` file. For more information, see [Using role mapping files](/deploy-manage/users-roles/cluster-or-deployment-auth/mapping-users-groups-to-roles.md#mapping-roles-file). +If you use files to manage the role mappings, you must configure a YAML file and copy it to each node in the cluster. By default, role mappings are stored in `ES_PATH_CONF/role_mapping.yml`. Alternatively, you can specify a different role mapping file for each type of realm and specify its location in the [`elasticsearch.yml`](/deploy-manage/deploy/self-managed/configure-elasticsearch.md) file. For more information, see [Using role mapping files](/deploy-manage/users-roles/cluster-or-deployment-auth/mapping-users-groups-to-roles.md#mapping-roles-file). To pass this bootstrap check, the role mapping files must exist and must be valid. The Distinguished Names (DNs) that are listed in the role mappings files must also be valid. ::: @@ -227,7 +227,7 @@ $$$bootstrap-checks-xpack-token-ssl$$$ If you use {{es}} {{security-features}} and the built-in token service is enabled, you must configure your cluster to use SSL/TLS for the HTTP interface. HTTPS is required in order to use the token service. -In particular, if `xpack.security.authc.token.enabled` is set to `true` in the `elasticsearch.yml` file, you must also set `xpack.security.http.ssl.enabled` to `true`. For more information about these settings, see [Security settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md) and [Advanced HTTP settings](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md#http-settings). +In particular, if `xpack.security.authc.token.enabled` is set to `true` in the [`elasticsearch.yml`](/deploy-manage/deploy/self-managed/configure-elasticsearch.md) file, you must also set `xpack.security.http.ssl.enabled` to `true`. For more information about these settings, see [Security settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md) and [Advanced HTTP settings](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md#http-settings). To pass this bootstrap check, you must enable HTTPS or disable the built-in token service. diff --git a/deploy-manage/deploy/self-managed/configure-elasticsearch.md b/deploy-manage/deploy/self-managed/configure-elasticsearch.md index 697a653444..bf74c397bd 100644 --- a/deploy-manage/deploy/self-managed/configure-elasticsearch.md +++ b/deploy-manage/deploy/self-managed/configure-elasticsearch.md @@ -12,6 +12,14 @@ applies_to: The configuration files should contain settings which are node-specific (such as `node.name` and paths), or settings which a node requires in order to be able to join a cluster, such as `cluster.name` and `network.host`. +:::{note} +This topic describes how to configure a self-managed {{es}} cluster. Other deployment types must be configured using different steps. + +To learn how to configure `elasticsearch.yml` for other deployment types, refer to [](/deploy-manage/stack-settings.md). + +JVM and log4j configuration is not available in all deployment types. To learn how to configure limited JVM options in {{eck}}, refer to [](/deploy-manage/deploy/cloud-on-k8s/manage-compute-resources.md). +::: + ## Available settings For a complete list of settings that you can apply to your {{es}} cluster, refer to the [{{es}} configuration reference](elasticsearch://reference/elasticsearch/configuration-reference/index.md). @@ -27,7 +35,7 @@ For a list of settings that must be configured before using your cluster in prod * `jvm.options` for configuring {{es}} JVM settings * `log4j2.properties` for configuring {{es}} logging -These files are located in the config directory, whose default location depends on whether or not the installation is from an archive distribution (`tar.gz` or `zip`) or a package distribution (Debian or RPM packages). +These files are located in the config directory, whose default location depends on whether the installation is from an archive distribution (`tar.gz` or `zip`) or a package distribution (Debian or RPM packages). ### Archive distributions @@ -50,54 +58,15 @@ The location of the config directory can be changed by setting the `ES_PATH_CONF You need to edit the `ES_PATH_CONF=/etc/elasticsearch` entry in the relevant file for your package to change the config directory location. - ## Config file format [_config_file_format] -The configuration format is [YAML](https://yaml.org/). Here is an example of changing the path of the data and logs directories: - -```yaml -path: - data: /var/lib/elasticsearch - logs: /var/log/elasticsearch -``` - -Settings can also be flattened as follows: - -```yaml -path.data: /var/lib/elasticsearch -path.logs: /var/log/elasticsearch -``` - -In YAML, you can format non-scalar values as sequences: - -```yaml -discovery.seed_hosts: - - 192.168.1.10:9300 - - 192.168.1.11 - - seeds.mydomain.com -``` - -Though less common, you can also format non-scalar values as arrays: - -```yaml -discovery.seed_hosts: ["192.168.1.10:9300", "192.168.1.11", "seeds.mydomain.com"] -``` - +:::{include} _snippets/config-file-format.md +::: ## Environment variable substitution [_environment_variable_substitution] -Environment variables referenced with the `${...}` notation within the configuration file will be replaced with the value of the environment variable. For example: - -```yaml -node.name: ${HOSTNAME} -network.host: ${ES_NETWORK_HOST} -``` - -Values for environment variables must be simple strings. Use a comma-separated string to provide values that {{es}} will parse as a list. For example, {{es}} will split the following string into a list of values for the `${HOSTNAME}` environment variable: - -```yaml -export HOSTNAME="host1,host2" -``` +:::{include} _snippets/env-var-setting-subs.md +::: ## Cluster and node setting types [cluster-setting-types] @@ -105,31 +74,13 @@ Cluster and node settings can be categorized based on how they are configured: ### Dynamic [dynamic-cluster-setting] -You can configure and update dynamic settings on a running cluster using the [cluster update settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings). You can also configure dynamic settings locally on an unstarted or shut down node using `elasticsearch.yml`. - -Updates made using the cluster update settings API can be *persistent*, which apply across cluster restarts, or *transient*, which reset after a cluster restart. You can also reset transient or persistent settings by assigning them a `null` value using the API. - -If you configure the same setting using multiple methods, {{es}} applies the settings in following order of precedence: - -1. Transient setting -2. Persistent setting -3. `elasticsearch.yml` setting -4. Default setting value - -For example, you can apply a transient setting to override a persistent setting or `elasticsearch.yml` setting. However, a change to an `elasticsearch.yml` setting will not override a defined transient or persistent setting. - -Use the [cluster update settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings) to configure dynamic cluster settings. Only use `elasticsearch.yml` for static cluster settings and node settings. The API doesn’t require a restart and ensures a setting’s value is the same on all nodes. - -::::{warning} -We no longer recommend using transient cluster settings. Use persistent cluster settings instead. If a cluster becomes unstable, transient settings can clear unexpectedly, resulting in a potentially undesired cluster configuration. -:::: - +:::{include} _snippets/dynamic-settings.md +::: ### Static [static-cluster-setting] -Static settings can only be configured on an unstarted or shut down node using `elasticsearch.yml`. - -Static settings must be set on every relevant node in the cluster. +:::{include} _snippets/static-settings.md +::: ## Additional topics diff --git a/deploy-manage/deploy/self-managed/configure-kibana.md b/deploy-manage/deploy/self-managed/configure-kibana.md index 2371aa3ee7..0494193880 100644 --- a/deploy-manage/deploy/self-managed/configure-kibana.md +++ b/deploy-manage/deploy/self-managed/configure-kibana.md @@ -10,7 +10,7 @@ applies_to: The {{kib}} server reads properties from the `kibana.yml` file on startup. -The location of this file differs depending on how you installed {{kib}} +The location of this file differs depending on how you installed {{kib}}: * **Archive distributions (`.tar.gz` or `.zip`)**: Default location is `$KIBANA_HOME/config` * **Package distributions (Debian or RPM)**: Default location is `/etc/kibana` diff --git a/deploy-manage/deploy/self-managed/important-settings-configuration.md b/deploy-manage/deploy/self-managed/important-settings-configuration.md index c478360a06..3a02c349f1 100644 --- a/deploy-manage/deploy/self-managed/important-settings-configuration.md +++ b/deploy-manage/deploy/self-managed/important-settings-configuration.md @@ -28,7 +28,7 @@ applies_to: For [macOS `.tar.gz`](install-elasticsearch-from-archive-on-linux-macos.md), [Linux `.tar.gz`](install-elasticsearch-from-archive-on-linux-macos.md), and [Windows `.zip`](install-elasticsearch-with-zip-on-windows.md) installations, `data` and `logs` are subdirectories of `$ES_HOME` by default. However, files in `$ES_HOME` risk deletion during an upgrade. -In production, we strongly recommend you set the `path.data` and `path.logs` in `elasticsearch.yml` to locations outside of `$ES_HOME`. [Docker](install-elasticsearch-with-docker.md), [Debian](install-elasticsearch-with-debian-package.md), and [RPM](install-elasticsearch-with-rpm.md) installations write data and log to locations outside of `$ES_HOME` by default. +In production, we strongly recommend you set the `path.data` and `path.logs` in [`elasticsearch.yml`](/deploy-manage/deploy/self-managed/configure-elasticsearch.md) to locations outside of `$ES_HOME`. [Docker](install-elasticsearch-with-docker.md), [Debian](install-elasticsearch-with-debian-package.md), and [RPM](install-elasticsearch-with-rpm.md) installations write data and log to locations outside of `$ES_HOME` by default. Supported `path.data` and `path.logs` values vary by platform: @@ -87,7 +87,7 @@ Changing the name of a cluster requires a [full cluster restart](../../maintenan ## Node name setting [node-name] -{{es}} uses `node.name` as a human-readable identifier for a particular instance of {{es}}. This name is included in the response of many APIs. The node name defaults to the hostname of the machine when {{es}} starts, but can be configured explicitly in `elasticsearch.yml`: +{{es}} uses `node.name` as a human-readable identifier for a particular instance of {{es}}. This name is included in the response of many APIs. The node name defaults to the hostname of the machine when {{es}} starts, but can be configured explicitly in [`elasticsearch.yml`](/deploy-manage/deploy/self-managed/configure-elasticsearch.md): ```yaml node.name: prod-data-2 diff --git a/deploy-manage/deploy/self-managed/install-elasticsearch-from-archive-on-linux-macos.md b/deploy-manage/deploy/self-managed/install-elasticsearch-from-archive-on-linux-macos.md index 9e6e9b3db0..ca1f3895ce 100644 --- a/deploy-manage/deploy/self-managed/install-elasticsearch-from-archive-on-linux-macos.md +++ b/deploy-manage/deploy/self-managed/install-elasticsearch-from-archive-on-linux-macos.md @@ -184,7 +184,7 @@ This is convenient because you don’t have to create any directories to start u | --- | --- | --- | --- | | home | {{es}} home directory or `$ES_HOME` | Directory created by unpacking the archive | | | bin | Binary scripts including `elasticsearch` to start a node and `elasticsearch-plugin` to install plugins | `$ES_HOME/bin` | | -| conf | Configuration files, including `elasticsearch.yml` | `$ES_HOME/config` | [`ES_PATH_CONF`](/deploy-manage/deploy/self-managed/configure-elasticsearch.md#config-files-location) | +| conf | Configuration files including `elasticsearch.yml` | `$ES_HOME/config` | [`ES_PATH_CONF`](/deploy-manage/deploy/self-managed/configure-elasticsearch.md#config-files-location) | | conf | Generated TLS keys and certificates for the transport and HTTP layer. | `$ES_HOME/config/certs` | | | data | The location of the data files of each index / shard allocated on the node. | `$ES_HOME/data` | [`path.data`](/deploy-manage/deploy/self-managed/important-settings-configuration.md#path-settings) | | logs | Log files location. | `$ES_HOME/logs` | [`path.logs`](/deploy-manage/deploy/self-managed/important-settings-configuration.md#path-settings) | diff --git a/deploy-manage/deploy/self-managed/setup-configuration-memory.md b/deploy-manage/deploy/self-managed/setup-configuration-memory.md index a84c980c05..843ada4440 100644 --- a/deploy-manage/deploy/self-managed/setup-configuration-memory.md +++ b/deploy-manage/deploy/self-managed/setup-configuration-memory.md @@ -45,7 +45,7 @@ Some platforms still swap off-heap memory when using a memory lock. To prevent o :::: -To enable a memory lock, set `bootstrap.memory_lock` to `true` in `elasticsearch.yml`: +To enable a memory lock, set `bootstrap.memory_lock` to `true` in [`elasticsearch.yml`](/deploy-manage/deploy/self-managed/configure-elasticsearch.md): ```yaml bootstrap.memory_lock: true diff --git a/deploy-manage/distributed-architecture/clusters-nodes-shards/node-roles.md b/deploy-manage/distributed-architecture/clusters-nodes-shards/node-roles.md index e6b989f724..5b253a394a 100644 --- a/deploy-manage/distributed-architecture/clusters-nodes-shards/node-roles.md +++ b/deploy-manage/distributed-architecture/clusters-nodes-shards/node-roles.md @@ -14,7 +14,7 @@ Each node performs one or more roles. Roles control the behavior of the node in ## Set node roles [set-node-roles] -You define a node’s roles by setting `node.roles` in [`elasticsearch.yml`](../../deploy/self-managed/configure-elasticsearch.md). If you set `node.roles`, the node is only assigned the roles you specify. If you don’t set `node.roles`, the node is assigned the following roles: +You define a node’s roles by setting `node.roles` in [`elasticsearch.yml`](/deploy-manage/stack-settings.md). If you set `node.roles`, the node is only assigned the roles you specify. If you don’t set `node.roles`, the node is assigned the following roles: * `master` * `data` @@ -62,7 +62,7 @@ Similarly, each master-eligible node maintains the following data on disk: Each node checks the contents of its data path at startup. If it discovers unexpected data then it will refuse to start. This is to avoid importing unwanted [dangling indices](elasticsearch://reference/elasticsearch/configuration-reference/local-gateway.md#dangling-indices) which can lead to a red cluster health. To be more precise, nodes without the `data` role will refuse to start if they find any shard data on disk at startup, and nodes without both the `master` and `data` roles will refuse to start if they have any index metadata on disk at startup. -It is possible to change the roles of a node by adjusting its `elasticsearch.yml` file and restarting it. This is known as *repurposing* a node. In order to satisfy the checks for unexpected data described above, you must perform some extra steps to prepare a node for repurposing when starting the node without the `data` or `master` roles. +It is possible to change the roles of a node by adjusting its [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file and restarting it. This is known as *repurposing* a node. In order to satisfy the checks for unexpected data described above, you must perform some extra steps to prepare a node for repurposing when starting the node without the `data` or `master` roles. * If you want to repurpose a data node by removing the `data` role then you should first use an [allocation filter](elasticsearch://reference/elasticsearch/configuration-reference/cluster-level-shard-allocation-routing-settings.md#cluster-shard-allocation-filtering) to safely migrate all the shard data onto other nodes in the cluster. * If you want to repurpose a node to have neither the `data` nor `master` roles then it is simplest to start a brand-new node with an empty data path and the desired roles. You may find it safest to use an [allocation filter](elasticsearch://reference/elasticsearch/configuration-reference/cluster-level-shard-allocation-routing-settings.md#cluster-shard-allocation-filtering) to migrate the shard data elsewhere in the cluster first. diff --git a/deploy-manage/distributed-architecture/discovery-cluster-formation/discovery-hosts-providers.md b/deploy-manage/distributed-architecture/discovery-cluster-formation/discovery-hosts-providers.md index bc649cac74..1a37d52d85 100644 --- a/deploy-manage/distributed-architecture/discovery-cluster-formation/discovery-hosts-providers.md +++ b/deploy-manage/distributed-architecture/discovery-cluster-formation/discovery-hosts-providers.md @@ -45,7 +45,7 @@ discovery.seed_hosts: The file-based seed hosts provider configures a list of hosts via an external file. {{es}} reloads this file when it changes, so that the list of seed nodes can change dynamically without needing to restart each node. For example, this gives a convenient mechanism for an {{es}} instance that is run in a Docker container to be dynamically supplied with a list of IP addresses to connect to when those IP addresses may not be known at node startup. -To enable file-based discovery, configure the `file` hosts provider as follows in the `elasticsearch.yml` file: +To enable file-based discovery, configure the `file` hosts provider as follows in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file: ```yaml discovery.seed_providers: file @@ -53,7 +53,7 @@ discovery.seed_providers: file Then create a file at `$ES_PATH_CONF/unicast_hosts.txt` in the format described below. Any time a change is made to the `unicast_hosts.txt` file the new changes will be picked up by {{es}} and the new hosts list will be used. -Note that the file-based discovery plugin augments the unicast hosts list in `elasticsearch.yml`: if there are valid seed addresses in `discovery.seed_hosts` then {{es}} uses those addresses in addition to those supplied in `unicast_hosts.txt`. +Note that the file-based discovery plugin augments the unicast hosts list in [`elasticsearch.yml`](/deploy-manage/stack-settings.md): if there are valid seed addresses in `discovery.seed_hosts` then {{es}} uses those addresses in addition to those supplied in `unicast_hosts.txt`. The `unicast_hosts.txt` file contains one node entry per line. Each node entry consists of the host (host name or IP address) and an optional transport port number. If the port number is specified, it must come immediately after the host (on the same line) separated by a `:`. If the port number is not specified, {{es}} will implicitly use the first port in the port range given by `transport.profiles.default.port`, or by `transport.port` if `transport.profiles.default.port` is not set. diff --git a/deploy-manage/distributed-architecture/shard-allocation-relocation-recovery/index-level-shard-allocation.md b/deploy-manage/distributed-architecture/shard-allocation-relocation-recovery/index-level-shard-allocation.md index 8042f726be..9fb10ec2fb 100644 --- a/deploy-manage/distributed-architecture/shard-allocation-relocation-recovery/index-level-shard-allocation.md +++ b/deploy-manage/distributed-architecture/shard-allocation-relocation-recovery/index-level-shard-allocation.md @@ -31,7 +31,7 @@ For example, you could use a custom node attribute to indicate a node’s perfor To filter based on a custom node attribute: -1. Specify the filter characteristics with a custom node attribute in each node’s `elasticsearch.yml` configuration file. For example, if you have `small`, `medium`, and `big` nodes, you could add a `size` attribute to filter based on node size. +1. Specify the filter characteristics with a custom node attribute in each node’s [`elasticsearch.yml`](/deploy-manage/stack-settings.md) configuration file. For example, if you have `small`, `medium`, and `big` nodes, you could add a `size` attribute to filter based on node size. ```yaml node.attr.size: medium diff --git a/deploy-manage/distributed-architecture/shard-allocation-relocation-recovery/shard-allocation-awareness.md b/deploy-manage/distributed-architecture/shard-allocation-relocation-recovery/shard-allocation-awareness.md index 36f85038f0..c8ed0e4cb9 100644 --- a/deploy-manage/distributed-architecture/shard-allocation-relocation-recovery/shard-allocation-awareness.md +++ b/deploy-manage/distributed-architecture/shard-allocation-relocation-recovery/shard-allocation-awareness.md @@ -30,7 +30,7 @@ To enable shard allocation awareness: You can set custom attributes in two ways: - * By editing the `elasticsearch.yml` config file: + * By editing the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) config file: ```yaml node.attr.rack_id: rack_one @@ -42,7 +42,7 @@ To enable shard allocation awareness: ./bin/elasticsearch -Enode.attr.rack_id=rack_one ``` -2. Tell {{es}} to take one or more awareness attributes into account when allocating shards by setting `cluster.routing.allocation.awareness.attributes` in **every** master-eligible node’s `elasticsearch.yml` config file. +2. Tell {{es}} to take one or more awareness attributes into account when allocating shards by setting `cluster.routing.allocation.awareness.attributes` in **every** master-eligible node’s [`elasticsearch.yml`](/deploy-manage/stack-settings.md) config file. ```yaml cluster.routing.allocation.awareness.attributes: rack_id <1> diff --git a/deploy-manage/kibana-reporting-configuration.md b/deploy-manage/kibana-reporting-configuration.md index 8a507df5fe..1817bd0162 100644 --- a/deploy-manage/kibana-reporting-configuration.md +++ b/deploy-manage/kibana-reporting-configuration.md @@ -229,7 +229,7 @@ To automatically generate reports with {{watcher}}, you must configure {{watcher 1. Enable {{stack-security-features}} on your {{es}} cluster. For more information, see [Getting started with security](/deploy-manage/security.md). 2. Configure TLS/SSL encryption for the {{kib}} server. For more information, see [*Encrypt TLS communications in {{kib}}*](/deploy-manage/security/set-up-basic-security-plus-https.md#encrypt-kibana-http). -3. Specify the {{kib}} server CA certificate chain in `elasticsearch.yml`: +3. Specify the {{kib}} server CA certificate chain in [`elasticsearch.yml`](/deploy-manage/stack-settings.md): If you are using your own CA to sign the {{kib}} server certificate, then you need to specify the CA certificate chain in {{es}} to properly establish trust in TLS connections between {{watcher}} and {{kib}}. If your CA certificate chain is contained in a PKCS #12 trust store, specify it like so: @@ -282,7 +282,7 @@ The screenshotting plugin used for {{report-features}} has a built-in utility to ### Set the `server.host` for the headless browser [set-reporting-server-host] -If using PNG/PDF {{report-features}} in a production environment, it is preferred to use the setting of `server.host: 0.0.0.0` in the `kibana.yml` configuration file. This allows the headless browser used for PDF/PNG reporting to reach {{kib}} over a local interface, while also allowing the {{kib}} server to listen on outward-facing network interfaces, as it makes the {{kib}} server accessible from any network interface on the machine. Make sure that no firewall rules or other routing rules prevent local services from accessing this address. +If using PNG/PDF {{report-features}} in a production environment, it is preferred to use the setting of `server.host: 0.0.0.0` in the [`kibana.yml`](/deploy-manage/stack-settings.md) configuration file. This allows the headless browser used for PDF/PNG reporting to reach {{kib}} over a local interface, while also allowing the {{kib}} server to listen on outward-facing network interfaces, as it makes the {{kib}} server accessible from any network interface on the machine. Make sure that no firewall rules or other routing rules prevent local services from accessing this address. ### Ensure {{es}} allows built-in templates [reporting-elasticsearch-configuration] diff --git a/deploy-manage/monitor/kibana-task-manager-health-monitoring.md b/deploy-manage/monitor/kibana-task-manager-health-monitoring.md index 267f76d5be..3141318ef0 100644 --- a/deploy-manage/monitor/kibana-task-manager-health-monitoring.md +++ b/deploy-manage/monitor/kibana-task-manager-health-monitoring.md @@ -67,7 +67,7 @@ deployment: eck: ``` -In self-managed deployments, you can configure health stats to be logged in the {{kib}} `DEBUG` logger at a regular cadence. To enable Task Manager debug logging in your {{kib}} instance, add the following to your `kibana.yml`: +In self-managed deployments, you can configure health stats to be logged in the {{kib}} `DEBUG` logger at a regular cadence. To enable Task Manager debug logging in your {{kib}} instance, add the following to your [`kibana.yml`](/deploy-manage/stack-settings.md): ```yaml logging: @@ -89,7 +89,7 @@ This message looks like: Detected potential performance issue with Task Manager. Set 'xpack.task_manager.monitored_stats_health_verbose_log.enabled: true' in your {{kib}}.yml to enable debug logging` ``` -If this message appears, set [`xpack.task_manager.monitored_stats_health_verbose_log.enabled`](kibana://reference/configuration-reference/task-manager-settings.md#task-manager-settings) to `true` in your `kibana.yml`. This will start logging the health metrics at either a `warn` or `error` log level, depending on the detected severity of the potential problem. +If this message appears, set [`xpack.task_manager.monitored_stats_health_verbose_log.enabled`](kibana://reference/configuration-reference/task-manager-settings.md#task-manager-settings) to `true` in your [`kibana.yml`](/deploy-manage/stack-settings.md). This will start logging the health metrics at either a `warn` or `error` log level, depending on the detected severity of the potential problem. ## Making sense of Task Manager health stats [making-sense-of-task-manager-health-stats] diff --git a/deploy-manage/monitor/logging-configuration/kib-advanced-logging.md b/deploy-manage/monitor/logging-configuration/kib-advanced-logging.md index cf5faa7588..5b94a69558 100644 --- a/deploy-manage/monitor/logging-configuration/kib-advanced-logging.md +++ b/deploy-manage/monitor/logging-configuration/kib-advanced-logging.md @@ -41,7 +41,7 @@ For additional information about the available logging settings, refer to the [{ Levels are ordered, so `off` > `fatal` > `error` > `warn` > `info` > `debug` > `trace` > `all`. -A log record will be logged by the logger if its level is higher than or equal to the level of its logger. For example: If the output of an API call is configured to log at the `info` level and the parameters passed to the API call are set to `debug`, with a global logging configuration in `kibana.yml` set to `debug`, both the output *and* parameters are logged. If the log level is set to `info`, the debug logs are ignored, meaning that you’ll only get a record for the API output and *not* for the parameters. +A log record will be logged by the logger if its level is higher than or equal to the level of its logger. For example: If the output of an API call is configured to log at the `info` level and the parameters passed to the API call are set to `debug`, with a global logging configuration in [`kibana.yml`](/deploy-manage/stack-settings.md) set to `debug`, both the output *and* parameters are logged. If the log level is set to `info`, the debug logs are ignored, meaning that you’ll only get a record for the API output and *not* for the parameters. Logging set at a plugin level is always respected, regardless of the `root` logger level. In other words, if root logger is set to fatal and pluginA logging is set to `debug`, debug logs are only shown for pluginA, with other logs only reporting on `fatal`. @@ -109,7 +109,7 @@ With `json` layout log messages will be formatted as JSON strings in [ECS format ## Logger hierarchy [logger-hierarchy] -Every logger has a unique name that follows a hierarchical naming rule. The logger is considered to be an ancestor of another logger if its name followed by a `.` is a prefix of the descendant logger. For example, a logger named `a.b` is an ancestor of logger `a.b.c`. All top-level loggers are descendants of a special `root` logger at the top of the logger hierarchy. The `root` logger always exists, is fully configured and logs to `info` level by default. The `root` logger must also be configured if any other logging configuration is specified in your `kibana.yml`. +Every logger has a unique name that follows a hierarchical naming rule. The logger is considered to be an ancestor of another logger if its name followed by a `.` is a prefix of the descendant logger. For example, a logger named `a.b` is an ancestor of logger `a.b.c`. All top-level loggers are descendants of a special `root` logger at the top of the logger hierarchy. The `root` logger always exists, is fully configured and logs to `info` level by default. The `root` logger must also be configured if any other logging configuration is specified in your [`kibana.yml`](/deploy-manage/stack-settings.md). You can configure *[log level](/deploy-manage/monitor/logging-configuration/kibana-log-levels.md)* and *appenders* for a specific logger. If a logger only has a *log level* configured, then the *appenders* configuration applied to the logger is inherited from the ancestor logger, up to the `root` logger. diff --git a/deploy-manage/monitor/logging-configuration/kibana-log-levels.md b/deploy-manage/monitor/logging-configuration/kibana-log-levels.md index 68968f55c2..06ba60065b 100644 --- a/deploy-manage/monitor/logging-configuration/kibana-log-levels.md +++ b/deploy-manage/monitor/logging-configuration/kibana-log-levels.md @@ -13,8 +13,8 @@ applies_to: Levels are ordered, so `off` > `fatal` > `error` > `warn` > `info` > `debug` > `trace` > `all`. -A record will be logged by the logger if its level is higher than or equal to the level of its logger. For example: If the output of an API call is configured to log at the `info` level and the parameters passed to the API call are set to `debug`, with a global logging configuration in `kibana.yml` set to `debug`, both the output *and* parameters are logged. If the log level is set to `info`, the debug logs are ignored, meaning that you’ll only get a record for the API output and *not* for the parameters. +A record will be logged by the logger if its level is higher than or equal to the level of its logger. For example: If the output of an API call is configured to log at the `info` level and the parameters passed to the API call are set to `debug`, with a global logging configuration in [`kibana.yml`](/deploy-manage/stack-settings.md) set to `debug`, both the output *and* parameters are logged. If the log level is set to `info`, the debug logs are ignored, meaning that you’ll only get a record for the API output and *not* for the parameters. -To set the log level, add the `logging.root.level` setting to `kibana.yml`, specifying the log level that you want. `logging.root.level` defaults to `info`. +To set the log level, add the `logging.root.level` setting to [`kibana.yml`](/deploy-manage/stack-settings.md), specifying the log level that you want. `logging.root.level` defaults to `info`. In a self-managed cluster, these levels can also be specified using [CLI arguments](/deploy-manage/monitor/logging-configuration/kib-advanced-logging.md#logging-cli-migration), and different log levels can be set for various loggers. [Learn more](/deploy-manage/monitor/logging-configuration/kib-advanced-logging.md). \ No newline at end of file diff --git a/deploy-manage/monitor/logging-configuration/update-elasticsearch-logging-levels.md b/deploy-manage/monitor/logging-configuration/update-elasticsearch-logging-levels.md index 77486ad86d..f3417c0d1c 100644 --- a/deploy-manage/monitor/logging-configuration/update-elasticsearch-logging-levels.md +++ b/deploy-manage/monitor/logging-configuration/update-elasticsearch-logging-levels.md @@ -57,7 +57,7 @@ PUT /_cluster/settings Other ways to change log levels include: -1. `elasticsearch.yml`: +1. [`elasticsearch.yml`](/deploy-manage/stack-settings.md): ```yaml logger.org.elasticsearch.discovery: DEBUG diff --git a/deploy-manage/monitor/monitoring-data/monitor-troubleshooting.md b/deploy-manage/monitor/monitoring-data/monitor-troubleshooting.md index f90a0a6e93..4bdfbfb385 100644 --- a/deploy-manage/monitor/monitoring-data/monitor-troubleshooting.md +++ b/deploy-manage/monitor/monitoring-data/monitor-troubleshooting.md @@ -48,7 +48,7 @@ The **Stack Monitoring** page in {{kib}} is empty. **Resolution:** -1. Confirm that {{kib}} is seeking monitoring data from the appropriate {{es}} URL. By default, data is retrieved from the cluster specified in the `elasticsearch.hosts` setting in the `kibana.yml` file. If you want to retrieve it from a different monitoring cluster, set `monitoring.ui.elasticsearch.hosts`. See [Monitoring settings](kibana://reference/configuration-reference/monitoring-settings.md). +1. Confirm that {{kib}} is seeking monitoring data from the appropriate {{es}} URL. By default, data is retrieved from the cluster specified in the `elasticsearch.hosts` setting in the [`kibana.yml`](/deploy-manage/stack-settings.md) file. If you want to retrieve it from a different monitoring cluster, set `monitoring.ui.elasticsearch.hosts`. See [Monitoring settings](kibana://reference/configuration-reference/monitoring-settings.md). 2. Confirm that there is monitoring data available at that URL. It is stored in indices such as `.monitoring-kibana-*` and `.monitoring-es-*` or `metrics-kibana.stack_monitoring.*`, depending on which method is used to collect monitoring data. At a minimum, you must have monitoring data for the {{es}} production cluster. Once that data exists, {{kib}} can display monitoring data for other products in the cluster. 3. Set the time filter to “Last 1 hour”. When monitoring data appears in your cluster, the page automatically refreshes with the monitoring summary. 4. If using {{agent}}, ensure that all integration assets have been installed in the monitoring cluster. diff --git a/deploy-manage/monitor/stack-monitoring/es-legacy-collection-methods.md b/deploy-manage/monitor/stack-monitoring/es-legacy-collection-methods.md index 4ac84607d5..4173f4b5e8 100644 --- a/deploy-manage/monitor/stack-monitoring/es-legacy-collection-methods.md +++ b/deploy-manage/monitor/stack-monitoring/es-legacy-collection-methods.md @@ -29,7 +29,7 @@ To learn about monitoring in general, see [Monitor a cluster](../../monitor.md). 1. Verify that the `xpack.monitoring.elasticsearch.collection.enabled` setting is `true`, which is its default value, on each node in the cluster. ::::{note} - You can specify this setting in either the `elasticsearch.yml` on each node or across the cluster as a dynamic cluster setting. If {{es}} {{security-features}} are enabled, you must have `monitor` cluster privileges to view the cluster settings and `manage` cluster privileges to change them. + You can specify this setting in either the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) on each node or across the cluster as a dynamic cluster setting. If {{es}} {{security-features}} are enabled, you must have `monitor` cluster privileges to view the cluster settings and `manage` cluster privileges to change them. :::: @@ -38,7 +38,7 @@ To learn about monitoring in general, see [Monitor a cluster](../../monitor.md). 2. Set the `xpack.monitoring.collection.enabled` setting to `true` on each node in the cluster. By default, it is disabled (`false`). ::::{note} - You can specify this setting in either the `elasticsearch.yml` on each node or across the cluster as a dynamic cluster setting. If {{es}} {{security-features}} are enabled, you must have `monitor` cluster privileges to view the cluster settings and `manage` cluster privileges to change them. + You can specify this setting in either the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) on each node or across the cluster as a dynamic cluster setting. If {{es}} {{security-features}} are enabled, you must have `monitor` cluster privileges to view the cluster settings and `manage` cluster privileges to change them. :::: @@ -86,7 +86,7 @@ To learn about monitoring in general, see [Monitor a cluster](../../monitor.md). 3. If you choose to use an `http` exporter: - 1. On the cluster that you want to monitor (often called the *production cluster*), configure each node to send metrics to your monitoring cluster. Configure an HTTP exporter in the `xpack.monitoring.exporters` settings in the `elasticsearch.yml` file. For example: + 1. On the cluster that you want to monitor (often called the *production cluster*), configure each node to send metrics to your monitoring cluster. Configure an HTTP exporter in the `xpack.monitoring.exporters` settings in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file. For example: ```yaml xpack.monitoring.exporters: @@ -98,7 +98,7 @@ To learn about monitoring in general, see [Monitor a cluster](../../monitor.md). 2. If the Elastic {{security-features}} are enabled on the monitoring cluster, you must provide appropriate credentials when data is shipped to the monitoring cluster: 1. Create a user on the monitoring cluster that has the [`remote_monitoring_agent` built-in role](../../users-roles/cluster-or-deployment-auth/built-in-roles.md). Alternatively, use the [`remote_monitoring_user` built-in user](../../users-roles/cluster-or-deployment-auth/built-in-users.md). - 2. Add the user ID and password settings to the HTTP exporter settings in the `elasticsearch.yml` file and keystore on each node.
+ 2. Add the user ID and password settings to the HTTP exporter settings in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file and keystore on each node.
For example: @@ -143,7 +143,7 @@ To learn about monitoring in general, see [Monitor a cluster](../../monitor.md). ``` 4. Configure your cluster to route monitoring data from sources such as {{kib}}, Beats, and {{ls}} to the monitoring cluster. For information about configuring each product to collect and send monitoring data, see [Monitor a cluster](../../monitor.md). -5. If you updated settings in the `elasticsearch.yml` files on your production cluster, restart {{es}}. See [*Stopping Elasticsearch*](../../maintenance/start-stop-services/start-stop-elasticsearch.md) and [*Starting Elasticsearch*](../../maintenance/start-stop-services/start-stop-elasticsearch.md). +5. If you updated settings in the `elasticsearch.yml` files on your production cluster, restart {{es}}. See [](../../maintenance/start-stop-services/start-stop-elasticsearch.md). ::::{tip} You may want to temporarily [disable shard allocation](elasticsearch://reference/elasticsearch/configuration-reference/cluster-level-shard-allocation-routing-settings.md) before you restart your nodes to avoid unnecessary shard reallocation during the install process. diff --git a/deploy-manage/monitor/stack-monitoring/es-monitoring-exporters.md b/deploy-manage/monitor/stack-monitoring/es-monitoring-exporters.md index 92b4343beb..cda2cbaca9 100644 --- a/deploy-manage/monitor/stack-monitoring/es-monitoring-exporters.md +++ b/deploy-manage/monitor/stack-monitoring/es-monitoring-exporters.md @@ -24,7 +24,7 @@ There are two types of exporters in {{es}}: Both exporters serve the same purpose: to set up the monitoring cluster and route monitoring data. However, they perform these tasks in very different ways. Even though things happen differently, both exporters are capable of sending all of the same data. -Exporters are configurable at both the node and cluster level. Cluster-wide settings, which are updated with the [`_cluster/settings` API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings), take precedence over settings in the `elasticsearch.yml` file on each node. When you update an exporter, it is completely replaced by the updated version of the exporter. +Exporters are configurable at both the node and cluster level. Cluster-wide settings, which are updated with the [`_cluster/settings` API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings), take precedence over settings in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file on each node. When you update an exporter, it is completely replaced by the updated version of the exporter. ::::{important} It is critical that all nodes share the same setup. Otherwise, monitoring data might be routed in different ways or to different places. diff --git a/deploy-manage/monitor/stack-monitoring/es-self-monitoring-prod.md b/deploy-manage/monitor/stack-monitoring/es-self-monitoring-prod.md index f4176c0b86..5d53d673cb 100644 --- a/deploy-manage/monitor/stack-monitoring/es-self-monitoring-prod.md +++ b/deploy-manage/monitor/stack-monitoring/es-self-monitoring-prod.md @@ -71,7 +71,7 @@ To store monitoring data in a separate cluster: :::: - 1. (Optional) Disable the collection of monitoring data in this {{kib}} instance. Set the `xpack.monitoring.kibana.collection.enabled` setting to `false` in the `kibana.yml` file. For more information about this setting, see [Monitoring settings in {{kib}}](kibana://reference/configuration-reference/monitoring-settings.md). + 1. (Optional) Disable the collection of monitoring data in this {{kib}} instance. Set the `xpack.monitoring.kibana.collection.enabled` setting to `false` in the [`kibana.yml`](/deploy-manage/stack-settings.md) file. For more information about this setting, see [Monitoring settings in {{kib}}](kibana://reference/configuration-reference/monitoring-settings.md). ## Send data to your cluster diff --git a/deploy-manage/monitor/stack-monitoring/kibana-monitoring-data.md b/deploy-manage/monitor/stack-monitoring/kibana-monitoring-data.md index b1f791e7ea..d259df6708 100644 --- a/deploy-manage/monitor/stack-monitoring/kibana-monitoring-data.md +++ b/deploy-manage/monitor/stack-monitoring/kibana-monitoring-data.md @@ -34,11 +34,11 @@ deployment: If the monitoring data is stored on a dedicated monitoring cluster, it is accessible even when the cluster you’re monitoring is not. If you have at least a gold license, you can send data from multiple clusters to the same monitoring cluster and view them all through the same instance of {{kib}}. - By default, data is retrieved from the cluster specified in the `elasticsearch.hosts` value in the `kibana.yml` file. If you want to retrieve it from a different cluster, set `monitoring.ui.elasticsearch.hosts`. + By default, data is retrieved from the cluster specified in the `elasticsearch.hosts` value in the [`kibana.yml`](/deploy-manage/stack-settings.md) file. If you want to retrieve it from a different cluster, set `monitoring.ui.elasticsearch.hosts`. To learn more about typical monitoring architectures, see [How monitoring works](../stack-monitoring.md) and [Monitoring in a production environment](elasticsearch-monitoring-self-managed.md). -2. Verify that `monitoring.ui.enabled` is set to `true`, which is the default value, in the `kibana.yml` file. For more information, see [Monitoring settings](kibana://reference/configuration-reference/monitoring-settings.md). +2. Verify that `monitoring.ui.enabled` is set to `true`, which is the default value, in the [`kibana.yml`](/deploy-manage/stack-settings.md) file. For more information, see [Monitoring settings](kibana://reference/configuration-reference/monitoring-settings.md). 3. If the Elastic {{security-features}} are enabled on the monitoring cluster, you must provide a user ID and password so {{kib}} can retrieve the data. 1. Create a user that has the `monitoring_user` [built-in role](../../users-roles/cluster-or-deployment-auth/built-in-roles.md) on the monitoring cluster. @@ -47,7 +47,7 @@ deployment: Make sure the `monitoring_user` role has read privileges on `metrics-*` indices. If it doesn’t, create a new role with `read` and `read_cross_cluster` index privileges on `metrics-*`, then assign the new role (along with `monitoring_user`) to your user. :::: - 2. Add the `monitoring.ui.elasticsearch.username` and `monitoring.ui.elasticsearch.password` settings in the `kibana.yml` file. If these settings are omitted, {{kib}} uses the `elasticsearch.username` and `elasticsearch.password` setting values. For more information, see [Configuring security in {{kib}}](../../security.md). + 2. Add the `monitoring.ui.elasticsearch.username` and `monitoring.ui.elasticsearch.password` settings in the [`kibana.yml`](/deploy-manage/stack-settings.md) file. If these settings are omitted, {{kib}} uses the `elasticsearch.username` and `elasticsearch.password` setting values. For more information, see [Configuring security in {{kib}}](../../security.md). 4. (Optional) If you're using a self-managed cluster, then optionally configure {{kib}} to encrypt communications between the {{kib}} server and the monitoring cluster. See [Encrypt TLS communications in {{kib}}](/deploy-manage/security/set-up-basic-security-plus-https.md#encrypt-kibana-http). 5. If the Elastic {{security-features}} are enabled on the {{kib}} server, only users that have the authority to access {{kib}} indices and to read the monitoring indices can use the monitoring dashboards. diff --git a/deploy-manage/monitor/stack-monitoring/kibana-monitoring-legacy.md b/deploy-manage/monitor/stack-monitoring/kibana-monitoring-legacy.md index 6a70604b73..9000025443 100644 --- a/deploy-manage/monitor/stack-monitoring/kibana-monitoring-legacy.md +++ b/deploy-manage/monitor/stack-monitoring/kibana-monitoring-legacy.md @@ -32,7 +32,7 @@ To learn about monitoring in general, refer to [](/deploy-manage/monitor/stack-m 1. Set the `xpack.monitoring.collection.enabled` setting to `true` on each node in the production cluster. By default, it is is disabled (`false`). ::::{note} - You can specify this setting in either the `elasticsearch.yml` on each node or across the cluster as a dynamic cluster setting. If {{stack-security-features}} are enabled, you must have `monitor` cluster privileges to view the cluster settings and `manage` cluster privileges to change them. + You can specify this setting in either the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) on each node or across the cluster as a dynamic cluster setting. If {{stack-security-features}} are enabled, you must have `monitor` cluster privileges to view the cluster settings and `manage` cluster privileges to change them. :::: @@ -63,8 +63,8 @@ To learn about monitoring in general, refer to [](/deploy-manage/monitor/stack-m For more information, see [Monitoring settings in {{es}}](elasticsearch://reference/elasticsearch/configuration-reference/monitoring-settings.md) and [Cluster update settings](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings). -2. Verify that `monitoring.enabled` and `monitoring.kibana.collection.enabled` are set to `true` in the `kibana.yml` file. These are the default values. For more information, see [Monitoring settings in {{kib}}](kibana://reference/configuration-reference/monitoring-settings.md). -3. Identify where to send monitoring data. {{kib}} automatically sends metrics to the {{es}} cluster specified in the `elasticsearch.hosts` setting in the `kibana.yml` file. This property has a default value of `http://localhost:9200`.
+2. Verify that `monitoring.enabled` and `monitoring.kibana.collection.enabled` are set to `true` in the [`kibana.yml`](/deploy-manage/stack-settings.md) file. These are the default values. For more information, see [Monitoring settings in {{kib}}](kibana://reference/configuration-reference/monitoring-settings.md). +3. Identify where to send monitoring data. {{kib}} automatically sends metrics to the {{es}} cluster specified in the `elasticsearch.hosts` setting in the [`kibana.yml`](/deploy-manage/stack-settings.md) file. This property has a default value of `http://localhost:9200`.
::::{tip} In production environments, we strongly recommend using a separate cluster (referred to as the *monitoring cluster*) to store the data. Using a separate monitoring cluster prevents production cluster outages from impacting your ability to access your monitoring data. It also prevents monitoring activities from impacting the performance of your production cluster. @@ -75,7 +75,7 @@ To learn about monitoring in general, refer to [](/deploy-manage/monitor/stack-m 4. If {{security-features}} are enabled on the production cluster: - 1. Verify that there is a valid user ID and password in the `elasticsearch.username` and `elasticsearch.password` settings in the `kibana.yml` file. These values are used when {{kib}} sends monitoring data to the production cluster. + 1. Verify that there is a valid user ID and password in the `elasticsearch.username` and `elasticsearch.password` settings in the [`kibana.yml`](/deploy-manage/stack-settings.md) file. These values are used when {{kib}} sends monitoring data to the production cluster. 2. [Configure encryption for traffic between {{kib}} and {{es}}](/deploy-manage/security/set-up-basic-security-plus-https.md#encrypt-kibana-http). 5. [Start {{kib}}](../../maintenance/start-stop-services/start-stop-kibana.md). diff --git a/deploy-manage/monitor/stack-monitoring/kibana-monitoring-metricbeat.md b/deploy-manage/monitor/stack-monitoring/kibana-monitoring-metricbeat.md index 8eaa2b1613..8bca337f14 100644 --- a/deploy-manage/monitor/stack-monitoring/kibana-monitoring-metricbeat.md +++ b/deploy-manage/monitor/stack-monitoring/kibana-monitoring-metricbeat.md @@ -24,7 +24,7 @@ To learn about monitoring in general, refer to [](/deploy-manage/monitor/stack-m 1. Disable the default collection of {{kib}} monitoring metrics. - Add the following setting in the {{kib}} configuration file (`kibana.yml`): + Add the following setting in the {{kib}} configuration file ([`kibana.yml`](/deploy-manage/stack-settings.md)): ```yaml monitoring.kibana.collection.enabled: false @@ -36,7 +36,7 @@ To learn about monitoring in general, refer to [](/deploy-manage/monitor/stack-m 3. Set the `xpack.monitoring.collection.enabled` setting to `true` on each node in the production cluster. By default, it is disabled (`false`). ::::{note} - You can specify this setting in either the `elasticsearch.yml` on each node or across the cluster as a dynamic cluster setting. If {{es}} {{security-features}} are enabled, you must have `monitor` cluster privileges to view the cluster settings and `manage` cluster privileges to change them. + You can specify this setting in either the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) on each node or across the cluster as a dynamic cluster setting. If {{es}} {{security-features}} are enabled, you must have `monitor` cluster privileges to view the cluster settings and `manage` cluster privileges to change them. :::: diff --git a/deploy-manage/production-guidance/kibana-reporting-production-considerations.md b/deploy-manage/production-guidance/kibana-reporting-production-considerations.md index 0883e19158..8a619c67aa 100644 --- a/deploy-manage/production-guidance/kibana-reporting-production-considerations.md +++ b/deploy-manage/production-guidance/kibana-reporting-production-considerations.md @@ -39,7 +39,7 @@ By default, if your system does support sandboxing, {{kib}} will **enable it aut #### Recommendation -Even if sandboxing is likely supported (e.g., kernel 3.8+), we recommend explicitly enabling it to ensure protection is active and avoid relying on auto-detection. To do that, add the following setting to your `kibana.yml` configuration file: +Even if sandboxing is likely supported (e.g., kernel 3.8+), we recommend explicitly enabling it to ensure protection is active and avoid relying on auto-detection. To do that, add the following setting to your [`kibana.yml`](/deploy-manage/stack-settings.md) configuration file: ```yaml xpack.screenshotting.browser.chromium.disableSandbox: false diff --git a/deploy-manage/remote-clusters/ec-remote-cluster-self-managed.md b/deploy-manage/remote-clusters/ec-remote-cluster-self-managed.md index a48a989c12..f7c89d426b 100644 --- a/deploy-manage/remote-clusters/ec-remote-cluster-self-managed.md +++ b/deploy-manage/remote-clusters/ec-remote-cluster-self-managed.md @@ -137,7 +137,7 @@ A deployment can be configured to trust all or specific deployments in any envir 7. Configure the self-managed cluster to trust this deployment, so that both deployments are configured to trust each other: * Download the Certificate Authority used to sign the certificates of your deployment nodes (it can be found in the Security page of your deployment) - * Trust this CA either using the [setting](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md) `xpack.security.transport.ssl.certificate_authorities` in `elasticsearch.yml` or by [adding it to the trust store](../security/different-ca.md). + * Trust this CA either using the [setting](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md) `xpack.security.transport.ssl.certificate_authorities` in [`elasticsearch.yml`](/deploy-manage/stack-settings.md) or by [adding it to the trust store](../security/different-ca.md). 8. Generate certificates with an `otherName` attribute using the {{es}} certutil. Create a file called `instances.yaml` with all the details of the nodes in your on-premise cluster like below. The `dns` and `ip` settings are optional, but `cn` is mandatory for use with the `trust_restrictions` path setting in the next step. Next, run `./bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12 -in instances.yaml` to create new certificates for all the nodes at once. You can then copy the resulting files into each node. diff --git a/deploy-manage/remote-clusters/ece-remote-cluster-self-managed.md b/deploy-manage/remote-clusters/ece-remote-cluster-self-managed.md index 7c44080bee..cf202d3b16 100644 --- a/deploy-manage/remote-clusters/ece-remote-cluster-self-managed.md +++ b/deploy-manage/remote-clusters/ece-remote-cluster-self-managed.md @@ -136,7 +136,7 @@ A deployment can be configured to trust all or specific deployments in any envir 7. Configure the self-managed cluster to trust this deployment, so that both deployments are configured to trust each other: * Download the Certificate Authority used to sign the certificates of your deployment nodes (it can be found in the Security page of your deployment) - * Trust this CA either using the [setting](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md) `xpack.security.transport.ssl.certificate_authorities` in `elasticsearch.yml` or by [adding it to the trust store](../security/different-ca.md). + * Trust this CA either using the [setting](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md) `xpack.security.transport.ssl.certificate_authorities` in [`elasticsearch.yml`](/deploy-manage/stack-settings.md) or by [adding it to the trust store](../security/different-ca.md). 8. Generate certificates with an `otherName` attribute using the {{es}} certutil. Create a file called `instances.yaml` with all the details of the nodes in your on-premise cluster like below. The `dns` and `ip` settings are optional, but `cn` is mandatory for use with the `trust_restrictions` path setting in the next step. Next, run `./bin/elasticsearch-certutil cert --ca elastic-stack-ca.p12 -in instances.yaml` to create new certificates for all the nodes at once. You can then copy the resulting files into each node. @@ -154,10 +154,10 @@ A deployment can be configured to trust all or specific deployments in any envir 9. Restrict the trusted clusters to allow only the ones which your self-managed cluster should trust. - * All the clusters in your {{ece}} environment are signed by the same certificate authority. Therefore, adding this CA would make the self-managed cluster trust all your clusters in your ECE environment. This should be limited using the setting `xpack.security.transport.ssl.trust_restrictions.path` in `elasticsearch.yml`, which points to a file that limits the certificates to trust based on their `otherName`-attribute. + * All the clusters in your {{ece}} environment are signed by the same certificate authority. Therefore, adding this CA would make the self-managed cluster trust all your clusters in your ECE environment. This should be limited using the setting `xpack.security.transport.ssl.trust_restrictions.path` in [`elasticsearch.yml`](/deploy-manage/stack-settings.md), which points to a file that limits the certificates to trust based on their `otherName`-attribute. * For example, the following file would trust: - ``` + ```yaml trust.subject_name: - *.node.aaaabbbbaaaabbbb.cluster.1053523734.account <1> - *.node.xxxxyyyyxxxxyyyy.cluster.1053523734.account <1> diff --git a/deploy-manage/remote-clusters/remote-clusters-api-key.md b/deploy-manage/remote-clusters/remote-clusters-api-key.md index 73174d25e5..26c70b3872 100644 --- a/deploy-manage/remote-clusters/remote-clusters-api-key.md +++ b/deploy-manage/remote-clusters/remote-clusters-api-key.md @@ -29,7 +29,7 @@ If you run into any issues, refer to [Troubleshooting](/troubleshoot/elasticsear ## Prerequisites [remote-clusters-prerequisites-api-key] -* The {{es}} security features need to be enabled on both clusters, on every node. Security is enabled by default. If it’s disabled, set `xpack.security.enabled` to `true` in `elasticsearch.yml`. Refer to [General security settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#general-security-settings). +* The {{es}} security features need to be enabled on both clusters, on every node. Security is enabled by default. If it’s disabled, set `xpack.security.enabled` to `true` in [`elasticsearch.yml`](/deploy-manage/stack-settings.md). Refer to [General security settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#general-security-settings). * The nodes of the local and remote clusters must be on {{stack}} 8.14 or later. * The local and remote clusters must have an appropriate license. For more information, refer to [https://www.elastic.co/subscriptions](https://www.elastic.co/subscriptions). @@ -43,7 +43,7 @@ If a remote cluster is part of an {{ech}} deployment, it has a valid certificate ### On the remote cluster [remote-clusters-security-api-key-remote-action] -1. Enable the remote cluster server on every node of the remote cluster. In `elasticsearch.yml`: +1. Enable the remote cluster server on every node of the remote cluster. In [`elasticsearch.yml`](/deploy-manage/stack-settings.md): 1. Set [`remote_cluster_server.enabled`](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md#remote-cluster-network-settings) to `true`. 2. Configure the bind and publish address for remote cluster server traffic, for example using [`remote_cluster.host`](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md#remote-cluster-network-settings). Without configuring the address, remote cluster traffic may be bound to the local interface, and remote clusters running on other machines can’t connect. @@ -86,7 +86,7 @@ If a remote cluster is part of an {{ech}} deployment, it has a valid certificate 3. On every node of the remote cluster: 1. Copy the `cross-cluster.p12` file from the earlier step to the `config` directory. If you didn’t create a wildcard certificate, make sure you copy the correct node-specific p12 file. - 2. Add following configuration to `elasticsearch.yml`: + 2. Add following configuration to [`elasticsearch.yml`](/deploy-manage/stack-settings.md): ```yaml xpack.security.remote_cluster_server.ssl.enabled: true @@ -111,7 +111,7 @@ If a remote cluster is part of an {{ech}} deployment, it has a valid certificate 1. On every node of the local cluster: 1. Copy the `ca.crt` file generated on the remote cluster earlier into the `config` directory, renaming the file `remote-cluster-ca.crt`. - 2. Add following configuration to `elasticsearch.yml`: + 2. Add following configuration to [`elasticsearch.yml`](/deploy-manage/stack-settings.md): ```yaml xpack.security.remote_cluster_client.ssl.enabled: true @@ -147,7 +147,7 @@ To add a remote cluster from Stack Management in {{kib}}: 2. Enter a name (*cluster alias*) for the remote cluster. 3. Specify the {{es}} endpoint URL, or the IP address or host name of the remote cluster followed by the remote cluster port (defaults to `9443`). For example, `cluster.es.eastus2.staging.azure.foundit.no:9443` or `192.168.1.1:9443`. -Alternatively, use the [cluster update settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings) to add a remote cluster. You can also use this API to dynamically configure remote clusters for *every* node in the local cluster. To configure remote clusters on individual nodes in the local cluster, define static settings in `elasticsearch.yml` for each node. +Alternatively, use the [cluster update settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings) to add a remote cluster. You can also use this API to dynamically configure remote clusters for *every* node in the local cluster. To configure remote clusters on individual nodes in the local cluster, define static settings in [`elasticsearch.yml`](/deploy-manage/stack-settings.md) for each node. The following request adds a remote cluster with an alias of `cluster_one`. This *cluster alias* is a unique identifier that represents the connection to the remote cluster and is used to distinguish between local and remote indices. @@ -288,7 +288,7 @@ PUT _cluster/settings ### Statically configure remote clusters [_statically_configure_remote_clusters] -If you specify settings in `elasticsearch.yml`, only the nodes with those settings can connect to the remote cluster and serve remote cluster requests. +If you specify settings in [`elasticsearch.yml`](/deploy-manage/stack-settings.md), only the nodes with those settings can connect to the remote cluster and serve remote cluster requests. ::::{note} Remote cluster settings that are specified using the [cluster update settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings) take precedence over settings that you specify in `elasticsearch.yml` for individual nodes. diff --git a/deploy-manage/remote-clusters/remote-clusters-cert.md b/deploy-manage/remote-clusters/remote-clusters-cert.md index a49125f5e1..b3266c84b9 100644 --- a/deploy-manage/remote-clusters/remote-clusters-cert.md +++ b/deploy-manage/remote-clusters/remote-clusters-cert.md @@ -26,7 +26,7 @@ If you run into any issues, refer to [Troubleshooting](/troubleshoot/elasticsear ## Prerequisites [remote-clusters-prerequisites-cert] -1. The {{es}} security features need to be enabled on both clusters, on every node. Security is enabled by default. If it’s disabled, set `xpack.security.enabled` to `true` in `elasticsearch.yml`. Refer to [General security settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#general-security-settings). +1. The {{es}} security features need to be enabled on both clusters, on every node. Security is enabled by default. If it’s disabled, set `xpack.security.enabled` to `true` in [`elasticsearch.yml`](/deploy-manage/stack-settings.md). Refer to [General security settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#general-security-settings). 2. The local and remote clusters versions must be compatible. :::{include} _snippets/remote-cluster-certificate-compatibility.md @@ -65,7 +65,7 @@ To add a remote cluster from Stack Management in {{kib}}: 2. Enter a name (*cluster alias*) for the remote cluster. 3. Specify the {{es}} endpoint URL, or the IP address or host name of the remote cluster followed by the transport port (defaults to `9300`). For example, `cluster.es.eastus2.staging.azure.foundit.no:9300` or `192.168.1.1:9300`. -Alternatively, use the [cluster update settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings) to add a remote cluster. You can also use this API to dynamically configure remote clusters for *every* node in the local cluster. To configure remote clusters on individual nodes in the local cluster, define static settings in `elasticsearch.yml` for each node. +Alternatively, use the [cluster update settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings) to add a remote cluster. You can also use this API to dynamically configure remote clusters for *every* node in the local cluster. To configure remote clusters on individual nodes in the local cluster, define static settings in [`elasticsearch.yml`](/deploy-manage/stack-settings.md) for each node. The following request adds a remote cluster with an alias of `cluster_one`. This *cluster alias* is a unique identifier that represents the connection to the remote cluster and is used to distinguish between local and remote indices. @@ -204,10 +204,10 @@ PUT _cluster/settings ### Statically configure remote clusters [_statically_configure_remote_clusters_2] -If you specify settings in `elasticsearch.yml`, only the nodes with those settings can connect to the remote cluster and serve remote cluster requests. +If you specify settings in [`elasticsearch.yml`](/deploy-manage/stack-settings.md), only the nodes with those settings can connect to the remote cluster and serve remote cluster requests. ::::{note} -Remote cluster settings that are specified using the [cluster update settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings) take precedence over settings that you specify in `elasticsearch.yml` for individual nodes. +Remote cluster settings that are specified using the [cluster update settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings) take precedence over settings that you specify in [`elasticsearch.yml`](/deploy-manage/stack-settings.md) for individual nodes. :::: diff --git a/deploy-manage/remote-clusters/remote-clusters-migrate.md b/deploy-manage/remote-clusters/remote-clusters-migrate.md index c5dfd2390c..fd8eec4249 100644 --- a/deploy-manage/remote-clusters/remote-clusters-migrate.md +++ b/deploy-manage/remote-clusters/remote-clusters-migrate.md @@ -40,7 +40,7 @@ If you run into any issues, refer to [Troubleshooting](/troubleshoot/elasticsear On the remote cluster: -1. Enable the remote cluster server on every node of the remote cluster. In `elasticsearch.yml`: +1. Enable the remote cluster server on every node of the remote cluster. In [`elasticsearch.yml`](/deploy-manage/stack-settings.md): 1. Set [`remote_cluster_server.enabled`](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md#remote-cluster-network-settings) to `true`. 2. Configure the bind and publish address for remote cluster server traffic, for example using [`remote_cluster.host`](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md#remote-cluster-network-settings). Without configuring the address, remote cluster traffic may be bound to the local interface, and remote clusters running on other machines can’t connect. @@ -83,7 +83,7 @@ On the remote cluster: 3. On every node of the remote cluster: 1. Copy the `cross-cluster.p12` file from the earlier step to the `config` directory. If you didn’t create a wildcard certificate, make sure you copy the correct node-specific p12 file. - 2. Add following configuration to `elasticsearch.yml`: + 2. Add following configuration to [`elasticsearch.yml`](/deploy-manage/stack-settings.md): ```yaml xpack.security.remote_cluster_server.ssl.enabled: true @@ -135,11 +135,11 @@ On the local cluster: 2. Remove the existing remote cluster definition by setting the remote cluster settings to `null`. -3. If you’ve statically configured the remote cluster (via `elasticsearch.yml`), copy the `cluster.remote` settings from `elasticsearch.yml`, and store them in a safe place. You may need them later in case you need to [roll back](#remote-clusters-migration-rollback). +3. If you’ve statically configured the remote cluster (via `elasticsearch.yml`), copy the `cluster.remote` settings from `elasticsearch.yml` and store them in a safe place. You may need them later in case you need to [roll back](#remote-clusters-migration-rollback). 4. On every node of the local cluster: 1. Copy the `ca.crt` file generated on the remote cluster earlier into the `config` directory, renaming the file `remote-cluster-ca.crt`. - 2. Add following configuration to `elasticsearch.yml`: + 2. Add following configuration to [`elasticsearch.yml`](/deploy-manage/stack-settings.md): ```yaml xpack.security.remote_cluster_client.ssl.enabled: true @@ -178,7 +178,7 @@ On the local cluster: 1. The remote cluster alias. Use the same alias that was used before the migration. 2. The remote cluster address with the remote cluster port, which defaults to `9443`. -6. If you’ve statically configured the remote cluster (via `elasticsearch.yml`): +6. If you’ve statically configured the remote cluster (via [`elasticsearch.yml`](/deploy-manage/stack-settings.md)): 1. Update the `cluster.remote` settings in `elasticsearch.yml` on each node of the local cluster. Change the port into the remote cluster port, which defaults to `9443`. 2. Restart the local cluster to load changes to the keystore and settings. diff --git a/deploy-manage/remote-clusters/remote-clusters-settings.md b/deploy-manage/remote-clusters/remote-clusters-settings.md index 683b3816ef..08ccce5559 100644 --- a/deploy-manage/remote-clusters/remote-clusters-settings.md +++ b/deploy-manage/remote-clusters/remote-clusters-settings.md @@ -17,7 +17,7 @@ The following settings apply to both [sniff mode](/deploy-manage/remote-clusters : The time to wait for remote connections to be established when the node starts. The default is `30s`. `remote_cluster_client` [role](elasticsearch://reference/elasticsearch/configuration-reference/node-settings.md#node-roles) -: By default, any node in the cluster can act as a cross-cluster client and connect to remote clusters. To prevent a node from connecting to remote clusters, specify the [node.roles](elasticsearch://reference/elasticsearch/configuration-reference/node-settings.md#node-roles) setting in `elasticsearch.yml` and exclude `remote_cluster_client` from the listed roles. Search requests targeting remote clusters must be sent to a node that is allowed to act as a cross-cluster client. Other features such as {{ml}} [data feeds](elasticsearch://reference/elasticsearch/configuration-reference/machine-learning-settings.md#general-ml-settings), [transforms](elasticsearch://reference/elasticsearch/configuration-reference/transforms-settings.md#general-transform-settings), and [{{ccr}}](../tools/cross-cluster-replication/set-up-cross-cluster-replication.md) require the `remote_cluster_client` role. +: By default, any node in the cluster can act as a cross-cluster client and connect to remote clusters. To prevent a node from connecting to remote clusters, specify the [node.roles](elasticsearch://reference/elasticsearch/configuration-reference/node-settings.md#node-roles) setting in [`elasticsearch.yml`](/deploy-manage/stack-settings.md) and exclude `remote_cluster_client` from the listed roles. Search requests targeting remote clusters must be sent to a node that is allowed to act as a cross-cluster client. Other features such as {{ml}} [data feeds](elasticsearch://reference/elasticsearch/configuration-reference/machine-learning-settings.md#general-ml-settings), [transforms](elasticsearch://reference/elasticsearch/configuration-reference/transforms-settings.md#general-transform-settings), and [{{ccr}}](../tools/cross-cluster-replication/set-up-cross-cluster-replication.md) require the `remote_cluster_client` role. `cluster.remote..skip_unavailable` : Per cluster boolean setting that allows to skip specific clusters when no nodes belonging to them are available and they are the target of a remote cluster request. diff --git a/deploy-manage/security/_snippets/kibana-client-https-setup.md b/deploy-manage/security/_snippets/kibana-client-https-setup.md index 82b69055a2..fe61c796e2 100644 --- a/deploy-manage/security/_snippets/kibana-client-https-setup.md +++ b/deploy-manage/security/_snippets/kibana-client-https-setup.md @@ -5,7 +5,7 @@ If you obtained the {{es}} certificates using a different method, you must provi :::: 1. Copy the `elasticsearch-ca.pem` file to the {{kib}} configuration directory, as defined by the `$KBN_PATH_CONF` path. -2. Open `kibana.yml` and add the following line to specify the location of the security certificate for the HTTP layer. +2. Open [`kibana.yml`](/deploy-manage/stack-settings.md) and add the following line to specify the location of the security certificate for the HTTP layer. ```yaml elasticsearch.ssl.certificateAuthorities: $KBN_PATH_CONF/elasticsearch-ca.pem diff --git a/deploy-manage/security/_snippets/kibana-https-setup.md b/deploy-manage/security/_snippets/kibana-https-setup.md index cf8d06282b..cdb23a72d3 100644 --- a/deploy-manage/security/_snippets/kibana-https-setup.md +++ b/deploy-manage/security/_snippets/kibana-https-setup.md @@ -24,7 +24,7 @@ The following steps guide you through creating a Certificate Signing Request (CS 2. Unzip the `csr-bundle.zip` file to obtain the `kibana-server.csr` unsigned security certificate and the `kibana-server.key` unencrypted private key. 3. Submit the `kibana-server.csr` certificate signing request to your organization’s security team or certificate authority to obtain a signed certificate. The resulting certificate might be in different formats, such as a `.crt` file like `kibana-server.crt`. -4. Open `kibana.yml` and add the following lines to configure {{kib}} HTTPS endpoint to use the server certificate and unencrypted private key. +4. Open [`kibana.yml`](/deploy-manage/stack-settings.md) and add the following lines to configure {{kib}} HTTPS endpoint to use the server certificate and unencrypted private key. ```yaml server.ssl.certificate: $KBN_PATH_CONF/kibana-server.crt @@ -35,7 +35,7 @@ The following steps guide you through creating a Certificate Signing Request (CS `$KBN_PATH_CONF` contains the path for the {{kib}} configuration files. If you installed {{kib}} using archive distributions (`zip` or `tar.gz`), the path defaults to `$KBN_HOME/config`. If you used package distributions (Debian or RPM), the path defaults to `/etc/kibana`. :::: -5. Add the following line to `kibana.yml` to enable HTTPS for incoming connections. +5. Add the following line to [`kibana.yml`](/deploy-manage/stack-settings.md) to enable HTTPS for incoming connections. ```yaml server.ssl.enabled: true diff --git a/deploy-manage/security/different-ca.md b/deploy-manage/security/different-ca.md index a0397e6b67..f116d820ab 100644 --- a/deploy-manage/security/different-ca.md +++ b/deploy-manage/security/different-ca.md @@ -207,7 +207,7 @@ This process is different for each client, so refer to your client’s documenta Each certificate will have its own private key, and will be issued for a specific hostname or IP address. - 7. When prompted, enter the name of the first node in your cluster. Use the same node name as the value for the `node.name` parameter in the `elasticsearch.yml` file. + 7. When prompted, enter the name of the first node in your cluster. Use the same node name as the value for the `node.name` parameter in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file. 8. Enter all hostnames used to connect to your first node. These hostnames will be added as DNS names in the Subject Alternative Name (SAN) field in your certificate. List every hostname and variant used to connect to your cluster over HTTPS. @@ -296,7 +296,7 @@ When you ran the `elasticsearch-certutil` tool with the `http` option, it create `KBN_PATH_CONF` contains the path for the {{kib}} configuration files. If you installed {{kib}} using archive distributions (`zip` or `tar.gz`), the path defaults to `KBN_HOME/config`. If you used package distributions (Debian or RPM), the path defaults to `/etc/kibana`. :::: -2. If you modified the filename for the `elasticsearch-ca.pem` file, edit `kibana.yml` and update the configuration to specify the location of the security certificate for the HTTP layer. +2. If you modified the filename for the `elasticsearch-ca.pem` file, edit [`kibana.yml`](/deploy-manage/stack-settings.md) and update the configuration to specify the location of the security certificate for the HTTP layer. ```yaml elasticsearch.ssl.certificateAuthorities: KBN_PATH_CONF/elasticsearch-ca.pem diff --git a/deploy-manage/security/fips-140-2.md b/deploy-manage/security/fips-140-2.md index 1452424b29..c211feaaa6 100644 --- a/deploy-manage/security/fips-140-2.md +++ b/deploy-manage/security/fips-140-2.md @@ -50,7 +50,7 @@ Compliance with FIPS 140-2 requires using only FIPS approved / NIST recommended * Installation and configuration of a FIPS certified Java security provider. * Ensuring the configuration of {{es}} is FIPS 140-2 compliant as documented below. -* Setting `xpack.security.fips_mode.enabled` to `true` in `elasticsearch.yml`. Note - this setting alone is not sufficient to be compliant with FIPS 140-2. +* Setting `xpack.security.fips_mode.enabled` to `true` in [`elasticsearch.yml`](/deploy-manage/stack-settings.md). Note - this setting alone is not sufficient to be compliant with FIPS 140-2. ### Configuring {{es}} for FIPS 140-2 [_configuring_es_for_fips_140_2] @@ -145,11 +145,11 @@ The user cache will be emptied upon node restart, so any existing hashes using n #### Configure {{es}} elasticsearch.yml [configuring-es-yml] -* Set `xpack.security.fips_mode.enabled` to `true` in `elasticsearch.yml`. This setting is used to ensure to configure some internal configuration to be FIPS 140-2 compliant and provides some additional verification. +* Set `xpack.security.fips_mode.enabled` to `true` in [`elasticsearch.yml`](/deploy-manage/stack-settings.md). This setting is used to ensure to configure some internal configuration to be FIPS 140-2 compliant and provides some additional verification. * Set `xpack.security.autoconfiguration.enabled` to `false`. This will disable the automatic configuration of the security settings. Users must ensure that the security settings are configured correctly for FIPS-140-2 compliance. This is only applicable for new installations. * Set `xpack.security.authc.password_hashing.algorithm` appropriately see [above](/deploy-manage/security/fips-140-2.md#fips-stored-password-hashing). * Other relevant security settings. For example, TLS for the transport and HTTP interfaces. (not explicitly covered here or in the example below) -* Optional: Set `xpack.security.fips_mode.required_providers` in `elasticsearch.yml` to ensure the required security providers (8.13+). see [below](/deploy-manage/security/fips-140-2.md#verify-security-provider). +* Optional: Set `xpack.security.fips_mode.required_providers` in [`elasticsearch.yml`](/deploy-manage/stack-settings.md) to ensure the required security providers (8.13+). see [below](/deploy-manage/security/fips-140-2.md#verify-security-provider). ```yaml xpack.security.fips_mode.enabled: true @@ -164,7 +164,7 @@ xpack.security.authc.password_hashing.algorithm: "pbkdf2_stretch" To verify that the security provider is installed and in use, you can use any of the following steps: * Verify the required security providers are configured with the lowest order in the file pointed to by `java.security.properties`. For example, `security.provider.1` is a lower order than `security.provider.2` -* Set `xpack.security.fips_mode.required_providers` in `elasticsearch.yml` to the list of required security providers. This setting is used to ensure that the correct security provider is installed and configured. (8.13+) If the security provider is not installed correctly, {{es}} will fail to start. `["BCFIPS", "BCJSSE"]` are the values to use for Bouncy Castle’s FIPS JCE and JSSE certified provider. +* Set `xpack.security.fips_mode.required_providers` in [`elasticsearch.yml`](/deploy-manage/stack-settings.md) to the list of required security providers. This setting is used to ensure that the correct security provider is installed and configured. (8.13+) If the security provider is not installed correctly, {{es}} will fail to start. `["BCFIPS", "BCJSSE"]` are the values to use for Bouncy Castle’s FIPS JCE and JSSE certified provider. ### Upgrade considerations [fips-upgrade-considerations] diff --git a/deploy-manage/security/ip-filtering-basic.md b/deploy-manage/security/ip-filtering-basic.md index 68a958785e..308c0bc81f 100644 --- a/deploy-manage/security/ip-filtering-basic.md +++ b/deploy-manage/security/ip-filtering-basic.md @@ -25,7 +25,7 @@ If a node’s IP address is on the denylist, the {{es}} {{security-features}} al The {{es}} {{security-features}} contain an access control feature that allows or rejects hosts, domains, or subnets. If the [{{operator-feature}}](/deploy-manage/users-roles/cluster-or-deployment-auth/operator-privileges.md) is enabled, only operator users can update these settings. -You configure IP filtering by specifying the `xpack.security.transport.filter.allow` and `xpack.security.transport.filter.deny` settings in `elasticsearch.yml`. Allow rules take precedence over the deny rules. +You configure IP filtering by specifying the `xpack.security.transport.filter.allow` and `xpack.security.transport.filter.deny` settings in [`elasticsearch.yml`](/deploy-manage/stack-settings.md). Allow rules take precedence over the deny rules. :::{important} Unless explicitly specified, `xpack.security.http.filter.*` and `xpack.security.remote_cluster.filter.*` settings default to the corresponding `xpack.security.transport.filter.*` setting’s value. @@ -61,7 +61,7 @@ xpack.security.transport.filter.deny: '*.google.com' ## Disable IP filtering -Disabling IP filtering can slightly improve performance under some conditions. To disable IP filtering entirely, set the value of the `xpack.security.transport.filter.enabled` setting in the `elasticsearch.yml` configuration file to `false`. +Disabling IP filtering can slightly improve performance under some conditions. To disable IP filtering entirely, set the value of the `xpack.security.transport.filter.enabled` setting in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) configuration file to `false`. ```yaml xpack.security.transport.filter.enabled: false diff --git a/deploy-manage/security/kibana-es-mutual-tls.md b/deploy-manage/security/kibana-es-mutual-tls.md index 24f9fb7438..de36dded8e 100644 --- a/deploy-manage/security/kibana-es-mutual-tls.md +++ b/deploy-manage/security/kibana-es-mutual-tls.md @@ -58,7 +58,7 @@ If you haven’t already, start {{kib}} and connect it to {{es}} using the [enro 3. Configure {{es}} with a PKI realm and a native realm. - By default, {{es}} provides a native realm for authenticating with a username and password. However, to support both a PKI realm (for {{kib}}) and a native realm (for end users), you must configure each realm in `elasticsearch.yml`: + By default, {{es}} provides a native realm for authenticating with a username and password. However, to support both a PKI realm (for {{kib}}) and a native realm (for end users), you must configure each realm in [`elasticsearch.yml`](/deploy-manage/stack-settings.md): ```yaml xpack.security.authc.realms.pki.realm1.order: 1 @@ -68,7 +68,7 @@ If you haven’t already, start {{kib}} and connect it to {{es}} using the [enro 4. Configure {{es}} to request client certificates. - By default, {{es}} will not request a client certificate when establishing a TLS connection. To change this, you must set up optional client certificate authentication in `elasticsearch.yml`: + By default, {{es}} will not request a client certificate when establishing a TLS connection. To change this, you must set up optional client certificate authentication in [`elasticsearch.yml`](/deploy-manage/stack-settings.md): ```yaml xpack.security.http.ssl.client_authentication: "optional" @@ -89,7 +89,7 @@ If you haven’t already, start {{kib}} and connect it to {{es}} using the [enro 1. If your certificate and private key are contained in a PKCS#12 file: - Specify your PKCS#12 file in `kibana.yml`: + Specify your PKCS#12 file in [`kibana.yml`](/deploy-manage/stack-settings.md): ```yaml elasticsearch.ssl.keystore.path: "/path/to/kibana-client.p12" @@ -107,7 +107,7 @@ If you haven’t already, start {{kib}} and connect it to {{es}} using the [enro 2. Otherwise, if your certificate and private key are in PEM format: - Specify your certificate and private key in `kibana.yml`: + Specify your certificate and private key in [`kibana.yml`](/deploy-manage/stack-settings.md): ```yaml elasticsearch.ssl.certificate: "/path/to/kibana-client.crt" @@ -122,7 +122,7 @@ If you haven’t already, start {{kib}} and connect it to {{es}} using the [enro 8. Configure {{kib}} *not* to use a username and password for {{es}}. - You must remove the `elasticsearch.username` and `elasticsearch.password` settings from `kibana.yml`. If these are present, {{kib}} will attempt to use them to authenticate to {{es}} via the native realm. + You must remove the `elasticsearch.username` and `elasticsearch.password` settings from [`kibana.yml`](/deploy-manage/stack-settings.md). If these are present, {{kib}} will attempt to use them to authenticate to {{es}} via the native realm. 9. Restart {{kib}}. diff --git a/deploy-manage/security/kibana-session-management.md b/deploy-manage/security/kibana-session-management.md index 08a7160be0..b3c47763ea 100644 --- a/deploy-manage/security/kibana-session-management.md +++ b/deploy-manage/security/kibana-session-management.md @@ -19,7 +19,7 @@ To manage user sessions programmatically, {{kib}} exposes [session management AP ## Session idle timeout [session-idle-timeout] -You can use `xpack.security.session.idleTimeout` to expire sessions after a period of inactivity. This and `xpack.security.session.lifespan` are both highly recommended. By default, sessions expire after 3 days of inactivity. To define another value for a sliding session expiration, set the property in the `kibana.yml` configuration file. The idle timeout is formatted as a duration of `[ms|s|m|h|d|w|M|Y]` (e.g. *20m*, *24h*, *7d*, *1w*). For example, set the idle timeout to expire sessions after 30 minutes of inactivity: +You can use `xpack.security.session.idleTimeout` to expire sessions after a period of inactivity. This and `xpack.security.session.lifespan` are both highly recommended. By default, sessions expire after 3 days of inactivity. To define another value for a sliding session expiration, set the property in the [`kibana.yml`](/deploy-manage/stack-settings.md) configuration file. The idle timeout is formatted as a duration of `[ms|s|m|h|d|w|M|Y]` (e.g. *20m*, *24h*, *7d*, *1w*). For example, set the idle timeout to expire sessions after 30 minutes of inactivity: ```yaml xpack.security.session.idleTimeout: "3d" @@ -28,7 +28,7 @@ xpack.security.session.idleTimeout: "3d" ## Session lifespan [session-lifespan] -You can use `xpack.security.session.lifespan` to configure the maximum session duration or "lifespan" — also known as the "absolute timeout". This and `xpack.security.session.idleTimeout` are both highly recommended. By default, a maximum session lifespan is 30 days. To define another lifespan, set the property in the `kibana.yml` configuration file. The lifespan is formatted as a duration of `[ms|s|m|h|d|w|M|Y]` (e.g. *20m*, *24h*, *7d*, *1w*). For example, set the lifespan to expire sessions after 7 days: +You can use `xpack.security.session.lifespan` to configure the maximum session duration or "lifespan" — also known as the "absolute timeout". This and `xpack.security.session.idleTimeout` are both highly recommended. By default, a maximum session lifespan is 30 days. To define another lifespan, set the property in the [`kibana.yml`](/deploy-manage/stack-settings.md) configuration file. The lifespan is formatted as a duration of `[ms|s|m|h|d|w|M|Y]` (e.g. *20m*, *24h*, *7d*, *1w*). For example, set the lifespan to expire sessions after 7 days: ```yaml xpack.security.session.lifespan: "7d" @@ -43,7 +43,7 @@ If you disable session idle timeout and lifespan, then {{kib}} will not automati :::: -You can configure the interval at which {{kib}} tries to remove expired and invalid sessions from the session index. By default, this value is 1 hour and cannot be less than 10 seconds. To define another interval, set the `xpack.security.session.cleanupInterval` property in the `kibana.yml` configuration file. The interval is formatted as a duration of `[ms|s|m|h|d|w|M|Y]` (e.g. *20m*, *24h*, *7d*, *1w*). For example, schedule the session index cleanup to perform once a day: +You can configure the interval at which {{kib}} tries to remove expired and invalid sessions from the session index. By default, this value is 1 hour and cannot be less than 10 seconds. To define another interval, set the `xpack.security.session.cleanupInterval` property in the [`kibana.yml`](/deploy-manage/stack-settings.md) configuration file. The interval is formatted as a duration of `[ms|s|m|h|d|w|M|Y]` (e.g. *20m*, *24h*, *7d*, *1w*). For example, schedule the session index cleanup to perform once a day: ```yaml xpack.security.session.cleanupInterval: "1d" diff --git a/deploy-manage/security/logging-configuration/auditing-search-queries.md b/deploy-manage/security/logging-configuration/auditing-search-queries.md index 3df3a50cd5..f46b1e9e0b 100644 --- a/deploy-manage/security/logging-configuration/auditing-search-queries.md +++ b/deploy-manage/security/logging-configuration/auditing-search-queries.md @@ -22,7 +22,7 @@ To make certain audit events include the request body, configure the following s xpack.security.audit.logfile.events.emit_request_body: true ``` -You can apply this setting through [cluster update settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings), as described in [](./configuring-audit-logs.md). Alternatively, you can modify `elasticsearch.yml` in all nodes and restart for the changes to take effect. +You can apply this setting through [cluster update settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings), as described in [](./configuring-audit-logs.md). Alternatively, you can modify [`elasticsearch.yml`](/deploy-manage/stack-settings.md) in all nodes and restart for the changes to take effect. ::::{important} No filtering is performed when auditing, so sensitive data might be audited in plain text when audit events include the request body. Also, the request body can contain malicious content that can break a parser consuming the audit logs. diff --git a/deploy-manage/security/logging-configuration/configuring-audit-logs.md b/deploy-manage/security/logging-configuration/configuring-audit-logs.md index 2e65efcc1a..9fe8c027e8 100644 --- a/deploy-manage/security/logging-configuration/configuring-audit-logs.md +++ b/deploy-manage/security/logging-configuration/configuring-audit-logs.md @@ -21,7 +21,7 @@ When auditing security events, a single client request might generate multiple a * [{{es}} ignore policies settings](elasticsearch://reference/elasticsearch/configuration-reference/auding-settings.md#audit-event-ignore-policies): Use ignore policies for fine-grained control over which audit events are printed to the log file. ::::{tip} - In {{es}}, all auditing settings except `xpack.security.audit.enabled` are dynamic. This means you can configure them using the [cluster update settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings), allowing changes to take effect immediately without requiring a restart. This approach is faster and more convenient than modifying `elasticsearch.yml`. + In {{es}}, all auditing settings except `xpack.security.audit.enabled` are dynamic. This means you can configure them using the [cluster update settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings), allowing changes to take effect immediately without requiring a restart. This approach is faster and more convenient than modifying [`elasticsearch.yml`](/deploy-manage/stack-settings.md). :::: For a complete description of event details and format, refer to the following resources: diff --git a/deploy-manage/security/logging-configuration/enabling-audit-logs.md b/deploy-manage/security/logging-configuration/enabling-audit-logs.md index 924944d658..278711ba5b 100644 --- a/deploy-manage/security/logging-configuration/enabling-audit-logs.md +++ b/deploy-manage/security/logging-configuration/enabling-audit-logs.md @@ -50,12 +50,12 @@ Audit logs are disabled by default and must be explicitly enabled. **To enable audit logging in {{es}}**: -1. In all nodes, set `xpack.security.audit.enabled` to `true` in `elasticsearch.yml`. +1. In all nodes, set `xpack.security.audit.enabled` to `true` in [`elasticsearch.yml`](/deploy-manage/stack-settings.md). 2. Restart the cluster by following the [rolling restart](/deploy-manage/maintenance/start-stop-services/full-cluster-restart-rolling-restart-procedures.md) procedure. **To enable audit logging in {{kib}}**: -1. Set `xpack.security.audit.enabled` to `true` in `kibana.yml`. +1. Set `xpack.security.audit.enabled` to `true` in [`kibana.yml`](/deploy-manage/stack-settings.md). 2. Restart {{kib}}. To learn how to consume these logs in an {{es}} cluster, refer to [](/deploy-manage/monitor/stack-monitoring/collecting-log-data-with-filebeat.md). diff --git a/deploy-manage/security/same-ca.md b/deploy-manage/security/same-ca.md index ea6e1b3a2e..f253b534c2 100644 --- a/deploy-manage/security/same-ca.md +++ b/deploy-manage/security/same-ca.md @@ -138,7 +138,7 @@ If your organization has its own CA, you’ll need to [generate Certificate Sign Each certificate will have its own private key, and will be issued for a specific hostname or IP address. - 7. When prompted, enter the name of the first node in your cluster. It’s helpful to use the same node name as the value for the `node.name` parameter in the `elasticsearch.yml` file. + 7. When prompted, enter the name of the first node in your cluster. It’s helpful to use the same node name as the value for the `node.name` parameter in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file. 8. Enter all hostnames used to connect to your first node. These hostnames will be added as DNS names in the Subject Alternative Name (SAN) field in your certificate. List every hostname and variant used to connect to your cluster over HTTPS. diff --git a/deploy-manage/security/secure-saved-objects.md b/deploy-manage/security/secure-saved-objects.md index 9cba04b2ba..6c48c06018 100644 --- a/deploy-manage/security/secure-saved-objects.md +++ b/deploy-manage/security/secure-saved-objects.md @@ -14,7 +14,7 @@ mapped_pages: Encrypting sensitive information means that a malicious party with access to the {{kib}} internal indices won’t be able to extract that information without also knowing the encryption key. -Example `kibana.yml`: +Example [`kibana.yml`](/deploy-manage/stack-settings.md): ```yaml xpack.encryptedSavedObjects: @@ -39,7 +39,7 @@ Many policies and best practices stipulate that encryption keys should be period When you change an encryption key, be sure to keep the old one for some time. Although {{kib}} only uses a new encryption key to encrypt all new and updated data, it still may need the old one to decrypt data that was encrypted using the old key. It’s possible to have multiple old keys used only for decryption. {{kib}} doesn’t automatically re-encrypt existing saved objects with the new encryption key. Re-encryption only happens when you update existing object or use the [rotate encryption key API](https://www.elastic.co/docs/api/doc/kibana/group/endpoint-saved-objects). -Here is how your `kibana.yml` might look if you use key rotation functionality: +Here is how your [`kibana.yml`](/deploy-manage/stack-settings.md) might look if you use key rotation functionality: ```yaml xpack.encryptedSavedObjects: diff --git a/deploy-manage/security/secure-settings.md b/deploy-manage/security/secure-settings.md index c9087e444d..15816a6831 100644 --- a/deploy-manage/security/secure-settings.md +++ b/deploy-manage/security/secure-settings.md @@ -17,7 +17,7 @@ mapped_pages: Some settings are sensitive, and relying on filesystem permissions to protect their values is not sufficient. For this use case, {{es}} and {{kib}} provide secure keystores to store sensitive configuration values such as passwords, API keys, and tokens. -Secure settings are often referred to as **keystore settings**, since they must be added to the product-specific keystore rather than the standard `elasticsearch.yml` or `kibana.yml` files. Unlike regular settings, they are encrypted and protected at rest, and they cannot be read or modified through the usual configuration files or environment variables. +Secure settings are often referred to as **keystore settings**, since they must be added to the product-specific keystore rather than the standard [`elasticsearch.yml` or `kibana.yml files](/deploy-manage/stack-settings.md). Unlike regular settings, they are encrypted and protected at rest, and they cannot be read or modified through the usual configuration files or environment variables. Keystore settings must be handled using a specific tool or method depending on the deployment type. The following table summarizes how {{es}} and {{kib}} keystores are supported and managed across different deployment models: @@ -33,6 +33,10 @@ This section describes how to configure and manage secure settings in each keyst * [{{es}} secure settings](./secure-settings.md#elasticsearch) * [{{kib}} secure settings](./secure-settings.md#kibana) +:::{tip} +For information about the APM keystore, refer to [](/solutions/observability/apm/secrets-keystore-for-secure-settings.md). +::: + ## {{es}} secure settings [elasticsearch] The {{es}} keystore has some important characteristics and limitations to be aware of: @@ -117,6 +121,8 @@ In self-managed deployments, you're responsible for configuring and maintaining {{es}} provides the [`elasticsearch-keystore`](elasticsearch://reference/elasticsearch/command-line-tools/elasticsearch-keystore.md) command-line tool to help with this task. It allows you to list, add, remove, and update secure settings, as well as protect the keystore with a password if wanted. +For docker examples, refer to [](/deploy-manage/deploy/self-managed/install-elasticsearch-docker-configure.md#docker-keystore-bind-mount). + :::{important} Secure settings must be specified on every node, and must have the same values across the cluster to ensure consistent behavior. @@ -133,7 +139,7 @@ bin/elasticsearch-keystore create -p You are prompted to enter a keystore password, but setting one is optional. If you press Enter without typing a password, the keystore file will be created without password protection. -The command creates a file named `elasticsearch.keystore` alongside the `elasticsearch.yml` file. +The command creates a file named `elasticsearch.keystore` alongside the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file. #### List settings in the keystore @@ -203,7 +209,7 @@ deployment: eck: ga ``` -{{kib}} supports secure settings through its own keystore, similar to the {{es}} keystore. It provides a way to protect sensitive configuration values, such as authentication credentials or encryption keys, by storing them securely outside of `kibana.yml`. +{{kib}} supports secure settings through its own keystore, similar to the {{es}} keystore. It provides a way to protect sensitive configuration values, such as authentication credentials or encryption keys, by storing them securely outside of [`kibana.yml`](/deploy-manage/stack-settings.md). ::::{note} Unlike with {{es}} keystore, any valid {{kib}} setting can be stored securely in the keystore. However, as with {{es}}, adding invalid, unsupported, or extraneous settings will cause {{kib}} to fail to start. Always ensure the setting exists and is properly formatted in the [configuration reference](kibana://reference/configuration-reference.md) before adding it to the keystore. diff --git a/deploy-manage/security/self-auto-setup.md b/deploy-manage/security/self-auto-setup.md index 44bf0ae8aa..aba1287b66 100644 --- a/deploy-manage/security/self-auto-setup.md +++ b/deploy-manage/security/self-auto-setup.md @@ -52,7 +52,7 @@ If certain directories already exist, there’s a strong indication that the nod The {{es}} `/data` directory exists and isn’t empty : The existence of this directory is a strong indicator that the node was started previously, and might already be part of a cluster. -The `elasticsearch.yml` file doesn’t exist (or isn’t readable), or the `elasticsearch.keystore` isn’t readable +The [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file doesn’t exist (or isn’t readable), or the [`elasticsearch.keystore`](/deploy-manage/security/secure-settings.md) isn’t readable : If either of these files aren’t readable, we can’t determine whether {{es}} security features are already enabled. This state can also indicate that the node startup process isn’t running as a user with sufficient privileges to modify the node configuration. The {{es}} configuration directory isn’t writable @@ -66,7 +66,7 @@ The following settings are incompatible with security auto configuration. If any * [`node.roles`](elasticsearch://reference/elasticsearch/configuration-reference/node-settings.md#node-roles) is set to a value where the node can’t be elected as `master`, or if the node can’t hold data * [`xpack.security.autoconfiguration.enabled`](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#general-security-settings) is set to `false` * [`xpack.security.enabled`](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#general-security-settings) has a value set -* Any of the [`xpack.security.transport.ssl.*`](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#transport-tls-ssl-settings) or [`xpack.security.http.ssl.*`](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#http-tls-ssl-settings) settings have a value set in the `elasticsearch.yml` configuration file or in the `elasticsearch.keystore` +* Any of the [`xpack.security.transport.ssl.*`](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#transport-tls-ssl-settings) or [`xpack.security.http.ssl.*`](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#http-tls-ssl-settings) settings have a value set in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) configuration file or in the [`elasticsearch.keystore`](/deploy-manage/security/secure-settings.md) * Any of the `discovery.type`, `discovery.seed_hosts`, or `cluster.initial_master_nodes` [discovery and cluster formation settings](elasticsearch://reference/elasticsearch/configuration-reference/discovery-cluster-formation-settings.md) have a value set ::::{note} diff --git a/deploy-manage/security/self-setup.md b/deploy-manage/security/self-setup.md index cabf058b0d..379fe8bd30 100644 --- a/deploy-manage/security/self-setup.md +++ b/deploy-manage/security/self-setup.md @@ -11,7 +11,7 @@ mapped_pages: % scope: initial security setup in self-managed deployments, following the automatic or manual (minimal, basic, https) procedures # Set up security in self-managed deployments -This section explains how to perform the initial security setup for self-managed deployments, including configuring TLS certificates to secure {{es}} and {{kib}} endpoints, setting passwords for built-in users, and generating enrollment tokens to connect {{kib}} or additional {{es}} nodes to the cluster. +This section explains the initial security setup for self-managed deployments, including configuring TLS certificates to secure {{es}} and {{kib}} endpoints, setting passwords for built-in users, and generating enrollment tokens to connect {{kib}} or additional {{es}} nodes to the cluster. Self-managed deployments support two approaches for the initial setup: automatic and manual. Note that securing {{kib}} always requires some manual configuration. @@ -24,11 +24,11 @@ Since version 8.0, {{es}} automatically enables security features on first start The automatic configuration: * Generates TLS certificates for the [transport and HTTP layers](./secure-cluster-communications.md#communication-channels) -* Applies TLS configuration settings to `elasticsearch.yml` +* Applies TLS configuration settings to [`elasticsearch.yml`](/deploy-manage/stack-settings.md) * Sets a password for the `elastic` superuser * Creates an enrollment token to securely connect {{kib}} to {{es}} -This automatic setup is the quickest way to get started and ensures your cluster is protected by default. +This automatic setup is the quickest way to get started and ensures your cluster is protected by default. To start this process, follow one of our [{{es}} installation guides](/deploy-manage/deploy/self-managed/installing-elasticsearch.md). ::::{warning} The automatic configuration does not enable TLS on the {{kib}} HTTP endpoint. To encrypt browser traffic to {{kib}}, follow the steps in [](./set-up-basic-security-plus-https.md#encrypt-kibana-browser). diff --git a/deploy-manage/security/set-up-basic-security-plus-https.md b/deploy-manage/security/set-up-basic-security-plus-https.md index 0721d2fb47..29254becb5 100644 --- a/deploy-manage/security/set-up-basic-security-plus-https.md +++ b/deploy-manage/security/set-up-basic-security-plus-https.md @@ -106,7 +106,7 @@ Once TLS is enabled, all client communications with the cluster will be encrypte 5. On **every** node in your cluster, complete the following steps: 1. Copy the relevant `http.p12` certificate to the `$ES_PATH_CONF` directory. - 2. Edit the `elasticsearch.yml` file to enable HTTPS security and specify the location of the `http.p12` security certificate. + 2. Edit the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file to enable HTTPS security and specify the location of the `http.p12` security certificate. ```yaml xpack.security.http.ssl.enabled: true diff --git a/deploy-manage/security/updating-certificates.md b/deploy-manage/security/updating-certificates.md index 1285ff53bc..1116c45587 100644 --- a/deploy-manage/security/updating-certificates.md +++ b/deploy-manage/security/updating-certificates.md @@ -21,7 +21,7 @@ Regardless of the scenario, {{es}} monitors the SSL resources for updates by def Because {{es}} doesn’t reload the `elasticsearch.yml` configuration, you must use **the same file names** if you want to take advantage of automatic certificate and key reloading. -If you need to update the `elasticsearch.yml` configuration or change passwords for keys or keystores that are stored in the [secure settings](secure-settings.md), then you must complete a [rolling restart](#use-rolling-restarts). {{es}} will not automatically reload changes for passwords stored in the secure settings. +If you need to update the `elasticsearch.yml`](/deploy-manage/stack-settings.md) configuration or change passwords for keys or keystores that are stored in the [secure settings](secure-settings.md), then you must complete a [rolling restart](#use-rolling-restarts). {{es}} will not automatically reload changes for passwords stored in the secure settings. ::::{admonition} Rolling restarts are preferred :name: use-rolling-restarts diff --git a/deploy-manage/security/using-kibana-with-security.md b/deploy-manage/security/using-kibana-with-security.md index 4fdd2cddd8..bb1a46003c 100644 --- a/deploy-manage/security/using-kibana-with-security.md +++ b/deploy-manage/security/using-kibana-with-security.md @@ -21,7 +21,7 @@ Set an encryption key so that sessions are not invalidated. You can optionally c When {{kib}} traffic is balanced across multiple instances connected to the same deployment, it is critical to configure these settings with identical values across all instances. Refer to [](/deploy-manage/production-guidance/kibana-load-balance-traffic.md) for more information. :::: -1. Set the `xpack.security.encryptionKey` property in the `kibana.yml` configuration file. You can use any text string that is 32 characters or longer as the encryption key. Refer to [`xpack.security.encryptionKey`](kibana://reference/configuration-reference/security-settings.md#xpack-security-encryptionkey). +1. Set the `xpack.security.encryptionKey` property in the [`kibana.yml`](/deploy-manage/stack-settings.md) configuration file. You can use any text string that is 32 characters or longer as the encryption key. Refer to [`xpack.security.encryptionKey`](kibana://reference/configuration-reference/security-settings.md#xpack-security-encryptionkey). ```yaml xpack.security.encryptionKey: "something_at_least_32_characters" @@ -38,7 +38,7 @@ The {{kib}} server can instruct browsers to enable additional security controls 1. Enable `HTTP Strict Transport Security (HSTS)`. - Use [`strictTransportSecurity`](https://www.elastic.co/guide/en/kibana/current/settings.html#server-securityResponseHeaders-strictTransportSecurity) to ensure that browsers will only attempt to access [{{kib}} with SSL/TLS encryption](./set-up-basic-security-plus-https.md#encrypt-kibana-browser). This is designed to prevent manipulator-in-the-middle attacks. To configure this with a lifetime of one year in your `kibana.yml`: + Use [`strictTransportSecurity`](https://www.elastic.co/guide/en/kibana/current/settings.html#server-securityResponseHeaders-strictTransportSecurity) to ensure that browsers will only attempt to access [{{kib}} with SSL/TLS encryption](./set-up-basic-security-plus-https.md#encrypt-kibana-browser). This is designed to prevent manipulator-in-the-middle attacks. To configure this with a lifetime of one year in your [`kibana.yml`](/deploy-manage/stack-settings.md): ```js server.securityResponseHeaders.strictTransportSecurity: "max-age=31536000" @@ -50,7 +50,7 @@ The {{kib}} server can instruct browsers to enable additional security controls 2. Disable embedding. - Use [`disableEmbedding`](https://www.elastic.co/guide/en/kibana/current/settings.html#server-securityResponseHeaders-disableEmbedding) to ensure that {{kib}} cannot be embedded in other websites. To configure this in your `kibana.yml`: + Use [`disableEmbedding`](https://www.elastic.co/guide/en/kibana/current/settings.html#server-securityResponseHeaders-disableEmbedding) to ensure that {{kib}} cannot be embedded in other websites. To configure this in your [`kibana.yml`](/deploy-manage/stack-settings.md): ```js server.securityResponseHeaders.disableEmbedding: true @@ -60,7 +60,7 @@ The {{kib}} server can instruct browsers to enable additional security controls {{kib}} uses a Content Security Policy (CSP) to prevent the browser from allowing unsafe scripting, but older browsers will silently ignore this policy. If your organization does not need to support very old versions of our supported browsers, we recommend that you enable {{kib}}'s `strict` mode for the CSP. This will block access to {{kib}} for any browser that does not enforce even a rudimentary set of CSP protections. -To do this, set `csp.strict` to `true` in your `kibana.yml`: +To do this, set `csp.strict` to `true` in your [`kibana.yml`](/deploy-manage/stack-settings.md): ```js csp.strict: true diff --git a/deploy-manage/stack-settings.md b/deploy-manage/stack-settings.md new file mode 100644 index 0000000000..099dbba131 --- /dev/null +++ b/deploy-manage/stack-settings.md @@ -0,0 +1,175 @@ +--- +applies_to: + deployment: + ece: + eck: + self: + ess: +navigation_title: "Stack settings" +--- + +# Elastic Stack settings + +{{stack}} settings allow you to customize {{es}}, {{kib}}, and other {{stack}} products to suit your needs. + +:::{admonition} Serverless manages these settings for you +In {{serverless-full}}, cluster-level settings and node-level settings are not required by end users, and are fully managed by Elastic. + +Certain [project settings](/deploy-manage/deploy/elastic-cloud/project-settings.md) allow you to customize your project’s performance and general data retention, and enable or disable project features. +::: + +## Available settings + +The available {{stack}} settings differ depending on your deployment type. + +### {{es}} settings + +{{es}} settings can be found in the [{{es}} configuration reference](elasticsearch://reference/elasticsearch/configuration-reference/index.md). + +| Deployment type | Applicable settings | +| --- | --- | +| Self managed | All {{es}} settings can be applied to a self-managed cluster. | +| {{ece}}

{{ech}} | Settings supported on {{ece}} and {{ech}} are indicated by an {{ecloud}} icon (![logo cloud](https://doc-icons.s3.us-east-2.amazonaws.com/logo_cloud.svg "Supported on {{ecloud}}")). However, some unmarked settings might also be supported.

{{ech}} and {{ece}} block the configuration of certain settings that could break your cluster if misconfigured. If a setting is not supported, you will get an error message when you try to save. We suggest changing one setting with each save, so you know which one is not supported. | +| {{eck}} | Most {{es}} settings can be applied to an ECK-managed {{es}} cluster.

Some settings are managed by ECK. It is not recommended to change these managed settings. For a complete list, refer to [Settings managed by ECK](/deploy-manage/deploy/cloud-on-k8s/settings-managed-by-eck.md). | + +### {{kib}} settings + +{{kib}} settings can be found in the [{{kib}} configuration reference](kibana://reference/configuration-reference.md). + +| Deployment type | Applicable settings | +| --- | --- | +| Self managed

{{eck}} | All {{kib}} settings can be applied to a self-managed or ECK instance. | +| {{ece}}

{{ech}} | Settings supported on {{ece}} and {{ech}} are indicated by an {{ecloud}} icon (![logo cloud](https://doc-icons.s3.us-east-2.amazonaws.com/logo_cloud.svg "Supported on {{ecloud}}")). However, some unmarked settings might also be supported.

{{ech}} and {{ece}} block the configuration of certain settings that could break your cluster if misconfigured. If a setting is not supported, you will get an error message when you try to save. We suggest changing one setting with each save, so you know which one is not supported. | +| {{eck}} | Most {{es}} settings can be applied to an ECK-managed {{es}} cluster.

Some settings are managed by ECK. It is not recommended to change these managed settings. For a complete list, refer to [Settings managed by ECK](/deploy-manage/deploy/cloud-on-k8s/settings-managed-by-eck.md). | + + +### Other + +For APM and Enterprise Search, refer to the product's documentation: + +* [APM](/reference/apm/observability/apm-settings.md) +* [Enterprise Search](https://www.elastic.co/guide/en/enterprise-search/8.18/configuration.html) + +## Configure {{stack}} settings + +The way that you configure your {{stack}} settings is determined by your deployment type. + +:::{warning} +* [Dynamic {{es}} cluster settings](#dynamic-cluster-setting) can also be updated using {{es}}'s [update cluster settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings). However, {{ech}} and {{ece}} don’t reject unsafe setting changes made using this API, and should be used with caution in these contexts. +* If a feature requires both standard `elasticsearch.yml` settings and [secure settings](/deploy-manage/security/secure-settings.md), configure the secure settings first. Updating standard user settings can trigger a cluster rolling restart in self managed clusters and ECH and ECE deployments. If the required secure settings are not yet in place, the nodes might fail to start. Adding secure settings does not trigger a restart. +::: + +:::::{tab-set} + +::::{tab-item} ECH and ECE + +For {{ech}} and {{ece}} deployments, you edit {{stack}} settings through the {{ecloud}} Console or ECE Cloud UI. These settings are internally mapped to the appropriate YAML configuration files, such as `elasticsearch.yml` and `kibana.yml`, and they affect all users of that cluster. + +{{ech}} and {{ece}} block the configuration of certain settings that could break your cluster if misconfigured. If a setting is not supported, you will get an error message when you try to save. We suggest changing one setting with each save, so you know which one is not supported. + +:::{include} /deploy-manage/_snippets/find-manage-deployment-ech-and-ece.md +::: +1. Under the deployment's name in the navigation menu, select **Edit**. +2. Look for the **Manage user settings and extensions** and **Edit user settings** links for each deployment, and select the one corresponding to the component you want to update, such as {{es}} or {{kib}}. +3. Apply the necessary settings in the **Users Settings** tab of the editor and select **Back** when finished. +4. Select **Save** to apply the changes to the deployment. Saving your changes initiates a configuration plan change that restarts the affected components for you. + +For further details and examples, refer to the resource for your deployment type: + +* [{{ech}}](/deploy-manage/deploy/elastic-cloud/edit-stack-settings.md) +* [{{ece}}](/deploy-manage/deploy/cloud-enterprise/edit-stack-settings.md) + +:::: + +::::{tab-item} ECK + +Stack settings are defined as part of your resource specification. + +#### {{es}} + +:::{include} /deploy-manage/deploy/cloud-on-k8s/_snippets/es-config.md +::: + +#### {{kib}} + +:::{include} /deploy-manage/deploy/cloud-on-k8s/_snippets/kib-config.md +::: + +:::: + +::::{tab-item} Self managed + +The method and location where you can update your {{stack}} settings depends on the component and installation method. + +#### Elasticsearch (`elasticsearch.yml`) + +Most settings can be changed on a running cluster using the [Cluster update settings](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings) API. + +You can also set {{es}} settings in `elasticsearch.yml`. Some settings require a cluster restart. To learn more, refer to [Dynamic and static {{es}} settings](#static-dynamic). + +To learn more about configuring {{es}} in a self-managed environment, refer to [](/deploy-manage/deploy/self-managed/configure-elasticsearch.md). + +| Installation method | Default location | +| --- | --- | +| Archive distribution (`tar.gz` or `zip`) | `$ES_HOME/config` ([override](/deploy-manage/deploy/self-managed/configure-elasticsearch.md#archive-distributions)) | +| Package distribution (Debian or RPM) | `/etc/elasticsearch` ([override](/deploy-manage/deploy/self-managed/configure-elasticsearch.md#package-distributions)) | +| Docker | `/usr/share/elasticsearch/config/` ([Learn more](/deploy-manage/deploy/self-managed/install-elasticsearch-docker-configure.md)) | + +#### Kibana (`kibana.yml`) + +To learn more about configuring {{kib}} in a self-managed environment, refer to [](/deploy-manage/deploy/self-managed/configure-kibana.md). + +| Installation method | Default location | +| --- | --- | +| Archive distribution (`tar.gz` or `zip`) | `$KIBANA_HOME/config` ([override](/deploy-manage/deploy/self-managed/configure-kibana.md)) | +| Package distribution (Debian or RPM) | `/etc/kibana` ([override](/deploy-manage/deploy/self-managed/configure-kibana.md)) | +| Docker | `/usr/share/kibana/config/` ([Learn more](/deploy-manage/deploy/self-managed/configure-kibana.md)) | + +#### Other + +For APM and Enterprise Search, refer to the product's documentation: + +* [APM](/reference/apm/observability/apm-settings.md) +* [Enterprise Search](https://www.elastic.co/guide/en/enterprise-search/8.18/configuration.html) + +#### Config file format + +:::{include} /deploy-manage/deploy/self-managed/_snippets/config-file-format.md +::: + +#### Environment variable substitution + +:::{include} /deploy-manage/deploy/self-managed/_snippets/env-var-setting-subs.md +::: + +:::: + +::::: + +## Secure your settings + +Some settings are sensitive, and relying on filesystem permissions to protect their values is not sufficient. For this use case, {{es}} and {{kib}} provide secure keystores to store sensitive configuration values such as passwords, API keys, and tokens. + +Secure settings are often referred to as **keystore settings**, since they must be added to the product-specific keystore rather than the standard `elasticsearch.yml` or `kibana.yml` files. Unlike regular settings, they are encrypted and protected at rest, and they cannot be read or modified through the usual configuration files or environment variables. + +If a feature requires both standard `elasticsearch.yml` settings and [secure settings](/deploy-manage/security/secure-settings.md), configure the secure settings first. Updating standard user settings can trigger a cluster rolling restart in self managed clusters and ECH and ECE deployments. If the required secure settings are not yet in place, the nodes might fail to start. Adding secure settings does not trigger a restart. + +To learn how to interact with secure settings, refer to [](/deploy-manage/security/secure-settings.md). + +## Dynamic and static {{es}} settings [static-dynamic] + +{{es}} cluster and node settings can be categorized based on how they are configured: + +### Dynamic [dynamic-cluster-setting] + +:::{include} /deploy-manage/deploy/self-managed/_snippets/dynamic-settings.md +::: + +{{ech}} and {{ece}} don’t reject unsafe setting changes made using this API, and should be used with caution in these contexts. + +### Static [static-cluster-setting] + +:::{include} /deploy-manage/deploy/self-managed/_snippets/static-settings.md +::: + +`elasticsearch.yml` should contain settings which are node-specific (such as `node.name` and paths), or settings which a node requires in order to be able to join a cluster, such as `cluster.name` and `network.host`. \ No newline at end of file diff --git a/deploy-manage/toc.yml b/deploy-manage/toc.yml index 3731310027..68a6ac3696 100644 --- a/deploy-manage/toc.yml +++ b/deploy-manage/toc.yml @@ -359,6 +359,7 @@ toc: - file: reference-architectures.md children: - file: reference-architectures/hotfrozen-high-availability.md + - file: stack-settings.md - file: tools.md children: - file: tools/snapshot-and-restore.md diff --git a/deploy-manage/tools/snapshot-and-restore/azure-repository.md b/deploy-manage/tools/snapshot-and-restore/azure-repository.md index 511e0d14e3..5cc1c161f8 100644 --- a/deploy-manage/tools/snapshot-and-restore/azure-repository.md +++ b/deploy-manage/tools/snapshot-and-restore/azure-repository.md @@ -36,7 +36,7 @@ bin/elasticsearch-keystore add azure.client.default.key bin/elasticsearch-keystore add azure.client.secondary.sas_token ``` -Other Azure repository client settings must be set in `elasticsearch.yml` before the node starts. For example: +Other Azure repository client settings must be set in [`elasticsearch.yml`](/deploy-manage/stack-settings.md) before the node starts. For example: ```yaml azure.client.default.timeout: 10s @@ -76,7 +76,7 @@ In progress snapshot or restore jobs will not be preempted by a **reload** of th ## Client settings [repository-azure-client-settings] -The following list describes the available client settings. Those that must be stored in the keystore are marked as ([Secure](/deploy-manage/security/secure-settings.md), [reloadable](../../security/secure-settings.md#reloadable-secure-settings)); the other settings must be stored in the `elasticsearch.yml` file. The default `CLIENT_NAME` is `default` but you may configure a client with a different name and specify that client by name when registering a repository. +The following list describes the available client settings. Those that must be stored in the keystore are marked as ([Secure](/deploy-manage/security/secure-settings.md), [reloadable](../../security/secure-settings.md#reloadable-secure-settings)); the other settings must be stored in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file. The default `CLIENT_NAME` is `default` but you may configure a client with a different name and specify that client by name when registering a repository. `azure.client.CLIENT_NAME.account` ([Secure](/deploy-manage/security/secure-settings.md), [reloadable](../../security/secure-settings.md#reloadable-secure-settings)) : The Azure account name, which is used by the repository’s internal Azure client. This setting is required for all clients. diff --git a/deploy-manage/tools/snapshot-and-restore/google-cloud-storage-repository.md b/deploy-manage/tools/snapshot-and-restore/google-cloud-storage-repository.md index 4914e5685c..06d6580beb 100644 --- a/deploy-manage/tools/snapshot-and-restore/google-cloud-storage-repository.md +++ b/deploy-manage/tools/snapshot-and-restore/google-cloud-storage-repository.md @@ -103,7 +103,7 @@ Snapshot or restore jobs that are in progress are not preempted by a **reload** ## Client settings [repository-gcs-client] -The client used to connect to Google Cloud Storage has a number of settings available. Client setting names are of the form `gcs.client.CLIENT_NAME.SETTING_NAME` and are specified inside `elasticsearch.yml`. The default client name looked up by a `gcs` repository is called `default`, but can be customized with the repository setting `client`. +The client used to connect to Google Cloud Storage has a number of settings available. Client setting names are of the form `gcs.client.CLIENT_NAME.SETTING_NAME` and are specified inside [`elasticsearch.yml`](/deploy-manage/stack-settings.md). The default client name looked up by a `gcs` repository is called `default`, but can be customized with the repository setting `client`. For example: diff --git a/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md b/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md index 6b91c16ea3..19f746edf2 100644 --- a/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md +++ b/deploy-manage/tools/snapshot-and-restore/restore-snapshot.md @@ -208,7 +208,7 @@ If you’re restoring to a different cluster, see [Restore to a different cluste 1. If you [backed up the cluster’s configuration files](../../../deploy-manage/tools/snapshot-and-restore/create-snapshots.md#back-up-config-files), you can restore them to each node. This step is optional and requires a [full cluster restart](../../../deploy-manage/maintenance/start-stop-services/full-cluster-restart-rolling-restart-procedures.md). - After you shut down a node, copy the backed-up configuration files over to the node’s `$ES_PATH_CONF` directory. Before restarting the node, ensure `elasticsearch.yml` contains the appropriate node roles, node name, and other node-specific settings. + After you shut down a node, copy the backed-up configuration files over to the node’s `$ES_PATH_CONF` directory. Before restarting the node, ensure [`elasticsearch.yml`](/deploy-manage/stack-settings.md) contains the appropriate node roles, node name, and other node-specific settings. If you choose to perform this step, you must repeat this process on each node in the cluster. diff --git a/deploy-manage/tools/snapshot-and-restore/s3-repository.md b/deploy-manage/tools/snapshot-and-restore/s3-repository.md index aff1a146e3..65ad90f207 100644 --- a/deploy-manage/tools/snapshot-and-restore/s3-repository.md +++ b/deploy-manage/tools/snapshot-and-restore/s3-repository.md @@ -48,7 +48,7 @@ PUT _snapshot/my_s3_repository } ``` -Most client settings can be added to the `elasticsearch.yml` configuration file with the exception of the secure settings, which you add to the {{es}} keystore. For more information about creating and updating the {{es}} keystore, see [Secure settings](../../security/secure-settings.md). +Most client settings can be added to the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) configuration file with the exception of the secure settings, which you add to the {{es}} keystore. For more information about creating and updating the {{es}} keystore, see [Secure settings](../../security/secure-settings.md). For example, if you want to use specific credentials to access S3 then run the following commands to add these credentials to the keystore. @@ -75,7 +75,7 @@ bin/elasticsearch-keystore remove s3.client.default.session_token Define the relevant secure settings in each node’s keystore before starting the node. The secure settings described here are all [reloadable](../../security/secure-settings.md#reloadable-secure-settings) so you may update the keystore contents on each node while the node is running and then call the [Nodes reload secure settings API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-nodes-reload-secure-settings) to apply the updated settings to the nodes in the cluster. After this API completes, {{es}} will use the updated setting values for all future snapshot operations, but ongoing operations may continue to use older setting values. -The following list contains the available client settings. Those that must be stored in the keystore are marked as "secure" and are **reloadable**; the other settings belong in the `elasticsearch.yml` file. +The following list contains the available client settings. Those that must be stored in the keystore are marked as "secure" and are **reloadable**; the other settings belong in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file. `access_key` ([Secure](/deploy-manage/security/secure-settings.md), [reloadable](../../security/secure-settings.md#reloadable-secure-settings)) : An S3 access key. If set, the `secret_key` setting must also be specified. If unset, the client will use the instance or container role instead. diff --git a/deploy-manage/tools/snapshot-and-restore/searchable-snapshots.md b/deploy-manage/tools/snapshot-and-restore/searchable-snapshots.md index f0bf290b34..52d3884aac 100644 --- a/deploy-manage/tools/snapshot-and-restore/searchable-snapshots.md +++ b/deploy-manage/tools/snapshot-and-restore/searchable-snapshots.md @@ -119,7 +119,7 @@ To illustrate how these settings work in concert let us look at two examples whe * A 4000 GB disk will result in a shared cache sized at 3900 GB. 90% of 4000 GB is 3600 GB, leaving 400 GB headroom. The default `max_headroom` of 100 GB takes effect, and the result is therefore 3900 GB. * A 400 GB disk will result in a shared cache sized at 360 GB. -You can configure the settings in `elasticsearch.yml`: +You can configure the settings in [`elasticsearch.yml`](/deploy-manage/stack-settings.md): ```yaml xpack.searchable.snapshot.shared_cache.size: 4TB diff --git a/deploy-manage/tools/snapshot-and-restore/shared-file-system-repository.md b/deploy-manage/tools/snapshot-and-restore/shared-file-system-repository.md index 5787a04c1b..fc22656e02 100644 --- a/deploy-manage/tools/snapshot-and-restore/shared-file-system-repository.md +++ b/deploy-manage/tools/snapshot-and-restore/shared-file-system-repository.md @@ -15,7 +15,7 @@ This repository type is only available if you run {{es}} on your own hardware. S Use a shared file system repository to store snapshots on a shared file system. -To register a shared file system repository, first mount the file system to the same location on all master and data nodes. Then add the file system’s path or parent directory to the `path.repo` setting in `elasticsearch.yml` for each master and data node. For running clusters, this requires a [rolling restart](../../maintenance/start-stop-services/full-cluster-restart-rolling-restart-procedures.md#restart-cluster-rolling) of each node. +To register a shared file system repository, first mount the file system to the same location on all master and data nodes. Then add the file system’s path or parent directory to the `path.repo` setting in [`elasticsearch.yml`](/deploy-manage/stack-settings.md) for each master and data node. For running clusters, this requires a [rolling restart](../../maintenance/start-stop-services/full-cluster-restart-rolling-restart-procedures.md#restart-cluster-rolling) of each node. Supported `path.repo` values vary by platform: diff --git a/deploy-manage/upgrade/deployment-or-cluster/archived-settings.md b/deploy-manage/upgrade/deployment-or-cluster/archived-settings.md index 63d27ef8d1..716761ee84 100644 --- a/deploy-manage/upgrade/deployment-or-cluster/archived-settings.md +++ b/deploy-manage/upgrade/deployment-or-cluster/archived-settings.md @@ -31,7 +31,7 @@ PUT _cluster/settings } ``` -{{es}} doesn’t archive transient cluster settings or settings in `elasticsearch.yml`. If a node includes an unsupported setting in `elasticsearch.yml`, it will return an error at startup. +{{es}} doesn’t archive transient cluster settings or settings in [`elasticsearch.yml`](/deploy-manage/stack-settings.md). If a node includes an unsupported setting in `elasticsearch.yml`, it will return an error at startup. ## Archived index settings [archived-index-settings] diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/access-agreement.md b/deploy-manage/users-roles/cluster-or-deployment-auth/access-agreement.md index 3fa128b599..a8c743221f 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/access-agreement.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/access-agreement.md @@ -21,7 +21,7 @@ You need to acknowledge the access agreement only once per session, and {{kib}} :::: -Here is an example of defining an access agreement in `kibana.yml`: +Here is an example of defining an access agreement in [`kibana.yml`](/deploy-manage/stack-settings.md): ```yaml xpack.security.authc.providers: diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/active-directory.md b/deploy-manage/users-roles/cluster-or-deployment-auth/active-directory.md index f004e08945..a5ef2a1555 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/active-directory.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/active-directory.md @@ -42,7 +42,7 @@ If your Active Directory domain supports authentication with user-provided crede ## Step 1: Add a new realm configuration [ad-realm-configuration] -1. Add a realm configuration of type `active_directory` to `elasticsearch.yml` under the `xpack.security.authc.realms.active_directory` namespace. At a minimum, you must specify the Active Directory `domain_name` and `order`. +1. Add a realm configuration of type `active_directory` to [`elasticsearch.yml`](/deploy-manage/stack-settings.md) under the `xpack.security.authc.realms.active_directory` namespace. At a minimum, you must specify the Active Directory `domain_name` and `order`. See [Active Directory realm settings](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-settings.html#ref-ad-settings) for all of the options you can set for an `active_directory` realm. @@ -114,17 +114,17 @@ If your Active Directory domain supports authentication with user-provided crede When you configure realms in `elasticsearch.yml`, only the realms you specify are used for authentication. If you also want to use the `native` or `file` realms, you must include them in the realm chain. :::: -2. (Optional) Configure how {{es}} should interact with multiple Active Directory servers. +1. (Optional) Configure how {{es}} should interact with multiple Active Directory servers. The `load_balance.type` setting can be used at the realm level. Two modes of operation are supported: failover and load balancing. See [Active Directory realm settings](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-settings.html#ref-ad-settings). -3. (Optional) To protect passwords, [encrypt communications](/deploy-manage/users-roles/cluster-or-deployment-auth/active-directory.md#tls-active-directory) between {{es}} and the Active Directory server. +2. (Optional) To protect passwords, [encrypt communications](/deploy-manage/users-roles/cluster-or-deployment-auth/active-directory.md#tls-active-directory) between {{es}} and the Active Directory server. * **For self-managed clusters and {{eck}} deployments**, clients and nodes that connect using SSL/TLS to the Active Directory server need to have the Active Directory server’s certificate or the server’s root CA certificate installed in their keystore or trust store. * **For {{ece}} and {{ech}} deployments**, if your Domain Controller is configured to use LDAP over TLS and it uses a self-signed certificate or a certificate that is signed by your organization’s CA, you need to enable the deployment to trust this certificate. -4. Restart {{es}}. +3. Restart {{es}}. ## Step 2: Configure a bind user (Optional) [ece-ad-configuration-with-bind-user] @@ -226,7 +226,7 @@ superuser: - cn=Senior Admin, cn=management, dc=example, dc=com ``` -Referencing the file in `elasticsearch.yml`: +Referencing the file in [`elasticsearch.yml`](/deploy-manage/stack-settings.md): ```yaml xpack: 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 1e63106948..11ff7a1539 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 @@ -18,7 +18,7 @@ To embed {{kib}} dashboards or grant access to {{kib}} without requiring credent Incoming requests to {{es}} are considered to be *anonymous* if no authentication token can be extracted from the incoming request. By default, anonymous requests are rejected and an authentication error is returned (status code `401`). -To enable anonymous access, you assign one or more roles to anonymous users in the `elasticsearch.yml` configuration file. For example, the following configuration assigns anonymous users `role1` and `role2`: +To enable anonymous access, you assign one or more roles to anonymous users in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) configuration file. For example, the following configuration assigns anonymous users `role1` and `role2`: ```yaml xpack.security.authc: diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/authorization-plugins.md b/deploy-manage/users-roles/cluster-or-deployment-auth/authorization-plugins.md index d4c41fd449..a4b063b823 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/authorization-plugins.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/authorization-plugins.md @@ -86,7 +86,7 @@ To use a security extension: * If you're using {{ece}}, then refer to [](/deploy-manage/deploy/cloud-enterprise/add-custom-bundles-plugins.md). * If you're using {{eck}}, then refer to [](/deploy-manage/deploy/cloud-on-k8s/custom-configuration-files-plugins.md). -2. Add any configuration parameters for implementations in the extension to the `elasticsearch.yml` file. The settings are not namespaced and you have access to any settings when constructing the extensions, although it is recommended to have a namespacing convention for extensions to keep your `elasticsearch.yml` configuration easy to understand. +2. Add any configuration parameters for implementations in the extension to the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file. The settings are not namespaced and you have access to any settings when constructing the extensions, although it is recommended to have a namespacing convention for extensions to keep your `elasticsearch.yml` configuration easy to understand. For example, if you have a custom roles provider that resolves roles from reading a blob in an S3 bucket on AWS, then you would specify settings in `elasticsearch.yml` such as: diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/built-in-users.md b/deploy-manage/users-roles/cluster-or-deployment-auth/built-in-users.md index b8ed6f8a91..48681fe021 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/built-in-users.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/built-in-users.md @@ -121,7 +121,7 @@ Alternatively, you can submit Change Password API requests for each built-in use ## Adding built-in user passwords to {{kib}} [add-built-in-user-kibana] -After the `kibana_system` user password is set, you need to update the {{kib}} server with the new password by setting `elasticsearch.password` in the `kibana.yml` configuration file: +After the `kibana_system` user password is set, you need to update the {{kib}} server with the new password by setting `elasticsearch.password` in the [`kibana.yml`](/deploy-manage/stack-settings.md) configuration file: ```yaml elasticsearch.password: kibanapassword diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/configure-operator-privileges.md b/deploy-manage/users-roles/cluster-or-deployment-auth/configure-operator-privileges.md index dc863003e4..4de639d1f3 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/configure-operator-privileges.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/configure-operator-privileges.md @@ -18,7 +18,7 @@ Before you can use operator privileges, you must [enable the feature](#enable-op ## Enable operator privileges [enable-operator-privileges] -In order to use the operator privileges feature, it must be enabled explicitly on each node in the cluster. Add the following setting in each `elasticsearch.yml` file: +In order to use the operator privileges feature, it must be enabled explicitly on each node in the cluster. Add the following setting in each [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file: ```yaml xpack.security.operator_privileges.enabled: true diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/custom.md b/deploy-manage/users-roles/cluster-or-deployment-auth/custom.md index 71bcfefa5b..ce27e5760a 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/custom.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/custom.md @@ -75,7 +75,7 @@ To use a custom realm: * If you're using {{eck}}, then refer to [](/deploy-manage/deploy/cloud-on-k8s/custom-configuration-files-plugins.md). -2. Add a realm configuration of the appropriate realm type to `elasticsearch.yml` under the `xpack.security.authc.realms` namespace. You must define your realm within the namespace that matches the type defined by the extension. The options you can set depend on the settings exposed by the custom realm. At a minimum, you must explicitly set the `order` attribute to control the order in which the realms are consulted during authentication. You must also 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. +2. Add a realm configuration of the appropriate realm type to [`elasticsearch.yml`](/deploy-manage/stack-settings.md) under the `xpack.security.authc.realms` namespace. You must define your realm within the namespace that matches the type defined by the extension. The options you can set depend on the settings exposed by the custom realm. At a minimum, you must explicitly set the `order` attribute to control the order in which the realms are consulted during authentication. You must also 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. ::::{important} When you configure realms in `elasticsearch.yml`, only the realms you specify are used for authentication. If you also want to use the `native` or `file` realms, you must include them in the realm chain. 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 792793ca0d..b35129baad 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 @@ -26,7 +26,7 @@ You can configure only one file realm on {{es}} nodes. 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. -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. +1. (Optional) Add a realm configuration to [`elasticsearch.yml`](/deploy-manage/stack-settings.md) 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: @@ -42,7 +42,7 @@ You don’t need to explicitly configure a `file` realm. The `file` and `native` 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. + 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`](/deploy-manage/stack-settings.md) file. :::{{warning}} Because `resource.reload.interval.high` is a common setting in {{es}}, changing its value may effect other schedules in the system. diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/jwt.md b/deploy-manage/users-roles/cluster-or-deployment-auth/jwt.md index 3e971621b9..29a76aedf0 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/jwt.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/jwt.md @@ -70,7 +70,7 @@ Not every access token is formatted as a JSON Web Token (JWT). For it to be comp ## Configure {{es}} to use a JWT realm [jwt-realm-configuration] -To use JWT authentication, create the realm in the `elasticsearch.yml` file to configure it within the {{es}} authentication chain. +To use JWT authentication, create the realm in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file to configure it within the {{es}} authentication chain. The JWT realm has a few mandatory settings, plus optional settings that are described in [JWT realm settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#ref-jwt-settings). @@ -335,7 +335,7 @@ If you use this API in the JWT realm, the following claims are available for rol If you [delegate authorization](../../../deploy-manage/users-roles/cluster-or-deployment-auth/realm-chains.md#authorization_realms) to other realms from the JWT realm, only the `principal` claim is available for role lookup. When delegating the assignment and lookup of roles to another realm from the JWT realm, claims for `dn`, `groups`, `mail`, `metadata`, and `name` are not used for the {{es}} user’s values. Only the JWT `principal` claim is passed to the delegated authorization realms. The realms that are delegated for authorization - not the JWT realm - become responsible for populating all of the {{es}} user’s values. -The following example shows how you define delegation authorization in the `elasticsearch.yml` file to multiple other realms from the JWT realm. A JWT realm named `jwt2` is delegating authorization to multiple realms: +The following example shows how you define delegation authorization in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file to multiple other realms from the JWT realm. A JWT realm named `jwt2` is delegating authorization to multiple realms: ```yaml xpack.security.authc.realms.jwt.jwt2.authorization_realms: file1,native1,ldap1,ad1 @@ -480,7 +480,7 @@ HMAC UTF-8: hmac-oidc-key-string-for-hs256-algorithm ### JWT realm settings [hmac-oidc-example-jwt-realm] -To define a JWT realm, add the following realm settings to `elasticsearch.yml`. +To define a JWT realm, add the following realm settings to [`elasticsearch.yml`](/deploy-manage/stack-settings.md). ```yaml xpack.security.authc.realms.jwt.jwt8.order: 8 <1> diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/kerberos.md b/deploy-manage/users-roles/cluster-or-deployment-auth/kerberos.md index 17a1366eaa..4e4af56755 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/kerberos.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/kerberos.md @@ -89,7 +89,7 @@ If you're using a self-managed cluster, then perform the following additional st * Enable the token service. - The {{es}} Kerberos implementation makes use of the {{es}} token service. If you configure TLS on the HTTP interface, this service is automatically enabled. It can be explicitly configured by adding the following setting in your `elasticsearch.yml` file: + The {{es}} Kerberos implementation makes use of the {{es}} token service. If you configure TLS on the HTTP interface, this service is automatically enabled. It can be explicitly configured by adding the following setting in your [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file: ```yaml xpack.security.authc.token.enabled: true @@ -151,7 +151,7 @@ For detailed information of available realm settings, see [Kerberos realm settin You can configure only one Kerberos realm on {{es}} nodes. ::: - To configure a Kerberos realm, there are a few mandatory realm settings and other optional settings that you need to configure in the `elasticsearch.yml` configuration file. Add a realm configuration under the `xpack.security.authc.realms.kerberos` namespace. + To configure a Kerberos realm, there are a few mandatory realm settings and other optional settings that you need to configure in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) configuration file. Add a realm configuration under the `xpack.security.authc.realms.kerberos` namespace. The most common configuration for a Kerberos realm is as follows: diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md index c846945f75..751d084fd7 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-authentication.md @@ -43,7 +43,7 @@ The Login Selector UI can also be disabled or enabled with `xpack.security.authc :::: -Here is how your `kibana.yml` and Login Selector UI can look like if you deal with multiple authentication providers: +Here is how your [`kibana.yml`](/deploy-manage/stack-settings.md) and Login Selector UI can look like if you deal with multiple authentication providers: ```yaml xpack.security.loginHelp: "**Help** info with a [link](...)" @@ -74,7 +74,7 @@ xpack.security.authc.providers: For more information, refer to [authentication security settings](kibana://reference/configuration-reference/security-settings.md#authentication-security-settings). ::::{tip} -If you have multiple authentication providers configured, you can use the `auth_provider_hint` URL query parameter to create a deep link to any provider and bypass the Login Selector UI. Using the `kibana.yml` above as an example, you can add `?auth_provider_hint=basic1` to the login page URL, which will take you directly to the basic login page. +If you have multiple authentication providers configured, you can use the `auth_provider_hint` URL query parameter to create a deep link to any provider and bypass the Login Selector UI. Using the [`kibana.yml`](/deploy-manage/stack-settings.md) above as an example, you can add `?auth_provider_hint=basic1` to the login page URL, which will take you directly to the basic login page. :::: @@ -97,7 +97,7 @@ Prior to configuring {{kib}}, ensure that token support is enabled in {{es}}. Se 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`: +To enable the token authentication provider in {{kib}}, set the following value in your [`kibana.yml`](/deploy-manage/stack-settings.md): ```yaml xpack.security.authc.providers: @@ -120,7 +120,7 @@ PKI authentication is a [subscription feature](https://www.elastic.co/subscripti Prior to configuring {{kib}}, ensure that the PKI realm is enabled in {{es}} and configured to permit delegation. See [Configuring a PKI realm](/deploy-manage/users-roles/cluster-or-deployment-auth/pki.md) for more information. -To enable the PKI authentication provider in {{kib}}, you must first [configure {{kib}} to encrypt communications between the browser and {{kib}} server](/deploy-manage/security/set-up-basic-security-plus-https.md#encrypt-kibana-http). You must also enable TLS client authentication and include the certificate authority (CA) used to sign client certificates into a list of CAs trusted by {{kib}} in your `kibana.yml`: +To enable the PKI authentication provider in {{kib}}, you must first [configure {{kib}} to encrypt communications between the browser and {{kib}} server](/deploy-manage/security/set-up-basic-security-plus-https.md#encrypt-kibana-http). You must also enable TLS client authentication and include the certificate authority (CA) used to sign client certificates into a list of CAs trusted by {{kib}} in your [`kibana.yml`](/deploy-manage/stack-settings.md): ::::{note} You can configure only one PKI provider per {{kib}} instance. @@ -279,7 +279,7 @@ During logout, both the {{kib}} session and {{es}} access/refresh token pair are 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: +Next, to enable Kerberos in {{kib}}, you will need to enable the Kerberos authentication provider in the [`kibana.yml`](/deploy-manage/stack-settings.md) configuration file, as follows: ::::{note} You can configure only one Kerberos provider per {{kib}} instance. @@ -325,7 +325,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](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: +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`](/deploy-manage/stack-settings.md) might look: ```yaml xpack.security.authc.providers: @@ -385,7 +385,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`](/deploy-manage/stack-settings.md) 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. diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/ldap.md b/deploy-manage/users-roles/cluster-or-deployment-auth/ldap.md index aa15dcf998..b9ce7eb6c2 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/ldap.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/ldap.md @@ -31,7 +31,7 @@ The path to an entry is a *Distinguished Name* (DN) that uniquely identifies a u The `ldap` realm supports two modes of operation, a user search mode and a mode with specific templates for user DNs. ::::{important} -When you configure realms in `elasticsearch.yml`, only the realms you specify are used for authentication. If you also want to use the `native` or `file` realms, you must include them in the realm chain. +When you configure realms in `elasticsearch.yml`/deploy-manage/stack-settings.md, only the realms you specify are used for authentication. If you also want to use the `native` or `file` realms, you must include them in the realm chain. :::: ## Step 1: Add a new realm configuration [ldap-realm-configuration] @@ -47,7 +47,7 @@ The `ldap` realm supports two modes of operation, a user search mode and a mode To configure an `ldap` realm with user search: -1. Add a realm configuration to `elasticsearch.yml` under the `xpack.security.authc.realms.ldap` namespace. +1. Add a realm configuration to [`elasticsearch.yml`](/deploy-manage/stack-settings.md) under the `xpack.security.authc.realms.ldap` namespace. At a minimum, you must specify the `url` and `order` of the LDAP server, and set `user_search.base_dn` to the container DN where the users are searched for. See [LDAP realm settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#ref-ldap-settings) for all of the options you can set for an `ldap` realm. @@ -102,7 +102,7 @@ To configure an `ldap` realm with user search: To configure an `ldap` realm with user DN templates: -1. Add a realm configuration to `elasticsearch.yml` in the `xpack.security.authc.realms.ldap` namespace. At a minimum, you must specify the `url` and `order` of the LDAP server, and specify at least one template with the `user_dn_templates` option. See [LDAP realm settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#ref-ldap-settings) for all of the options you can set for an `ldap` realm. +1. Add a realm configuration to [`elasticsearch.yml`](/deploy-manage/stack-settings.md) in the `xpack.security.authc.realms.ldap` namespace. At a minimum, you must specify the `url` and `order` of the LDAP server, and specify at least one template with the `user_dn_templates` option. See [LDAP realm settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#ref-ldap-settings) for all of the options you can set for an `ldap` realm. For example, the following snippet shows an LDAP realm configured with user DN templates: @@ -205,7 +205,7 @@ user: 2. The LDAP distinguished name (DN) of the `admins` group. 3. The LDAP distinguished name (DN) of the `users` group. -Referencing the file in `elasticsearch.yml`: +Referencing the file in [`elasticsearch.yml`](/deploy-manage/stack-settings.md): ```yaml xpack: diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-authentication-for-multiple-clusters.md b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-authentication-for-multiple-clusters.md index b84a15adf1..b351b69699 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/manage-authentication-for-multiple-clusters.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/manage-authentication-for-multiple-clusters.md @@ -127,7 +127,7 @@ spec: ### Configure an LDAP realm with user DN templates[k8s_to_configure_an_ldap_realm_with_user_dn_templates] -Add a realm configuration to `elasticsearch.yml` in the xpack.security.authc.realms.ldap namespace. At a minimum, you must specify the url and order of the LDAP server, and specify at least one template with the user_dn_templates option. Check [LDAP realm settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#ref-ldap-settings) for all of the options you can set for an ldap realm. +Add a realm configuration to [`elasticsearch.yml`](/deploy-manage/stack-settings.md) in the `xpack.security.authc.realms.ldap` namespace. At a minimum, you must specify the url and order of the LDAP server, and specify at least one template with the user_dn_templates option. Check [LDAP realm settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#ref-ldap-settings) for all of the options you can set for an ldap realm. For example, the following snippet shows an LDAP realm configured with user DN templates: @@ -193,7 +193,7 @@ Make sure you check the complete [guide to setting up OpenID Connect with {{es}} Configuring OpenID Connect using {{stack}} configuration policy -1. Add OIDC realm to the `elasticsearch.yml` file using the `config` field under `elasticsearch` in the {{stack}} configuration policy, also enable token service. +1. Add OIDC realm to the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file using the `config` field under `elasticsearch` in the {{stack}} configuration policy, also enable token service. ::::{note} Below snippet is an example of using Google as OpenID provider, the values will change depending on the provider being used. @@ -364,7 +364,7 @@ Make sure you check the complete [guide to setting up JWT with {{es}}](/deploy-m Configuring JWT with {{stack}} configuration policy -1. Add your JWT realm to the `elasticsearch.yml` file using the `config` field under `elasticsearch` in the {{stack}} configuration policy +1. Add your JWT realm to the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file using the `config` field under `elasticsearch` in the {{stack}} configuration policy ```yaml elasticsearch: diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/mapping-users-groups-to-roles.md b/deploy-manage/users-roles/cluster-or-deployment-auth/mapping-users-groups-to-roles.md index f3ac1e99d7..1b53758b1c 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/mapping-users-groups-to-roles.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/mapping-users-groups-to-roles.md @@ -126,11 +126,11 @@ If you're using a self-managed cluster, then the file must be present on each no By default, role mappings are stored in `ES_PATH_CONF/role_mapping.yml`. In self-managed clusters, `ES_PATH_CONF` is `ES_HOME/config` (zip/tar installations) or `/etc/elasticsearch` (package installations). -To specify a different location, you configure the `files.role_mapping` setting in the [Active Directory](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#ref-ad-settings), [LDAP](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#ref-ldap-settings), and [PKI](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#ref-pki-settings) realm settings in `elasticsearch.yml`. +To specify a different location, you configure the `files.role_mapping` setting in the [Active Directory](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#ref-ad-settings), [LDAP](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#ref-ldap-settings), and [PKI](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#ref-pki-settings) realm settings in [`elasticsearch.yml`](/deploy-manage/stack-settings.md). Within the role mapping file, the security roles are keys and groups and users are values. The mappings can have a many-to-many relationship. When you map roles to groups, the roles of a user in that group are the combination of the roles assigned to that group and the roles assigned to that user. -By default, {{es}} checks role mapping files for changes every 5 seconds. If you're using a self-managed {{es}} cluster, you can change this default behavior by changing the `resource.reload.interval.high` setting in the `elasticsearch.yml` file. Because this is a common setting in {{es}}, changing its value might effect other schedules in the system. +By default, {{es}} checks role mapping files for changes every 5 seconds. If you're using a self-managed {{es}} cluster, you can change this default behavior by changing the `resource.reload.interval.high` setting in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file. Because this is a common setting in {{es}}, changing its value might effect other schedules in the system. ## Realm specific details [_realm_specific_details] 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 30f2bde639..394d2d6be0 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/native.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/native.md @@ -38,7 +38,7 @@ xpack.security.authc.realms.native.native1: enabled: false ``` -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. +You can configure a `native` realm in the `xpack.security.authc.realms.native` namespace in [`elasticsearch.yml`](/deploy-manage/stack-settings.md). 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. 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. diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md b/deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md index 8f7c37b776..3ec024b073 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/openid-connect.md @@ -64,7 +64,7 @@ If you're using a self-managed cluster, then perform the following additional st * Enable the token service. - The {{es}} OIDC implementation makes use of the {{es}} token service. If you configure TLS on the HTTP interface, this service is automatically enabled. It can be explicitly configured by adding the following setting in your `elasticsearch.yml` file: + The {{es}} OIDC implementation makes use of the {{es}} token service. If you configure TLS on the HTTP interface, this service is automatically enabled. It can be explicitly configured by adding the following setting in your [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file: ```yaml xpack.security.authc.token.enabled: true @@ -78,7 +78,7 @@ OpenID Connect based authentication is enabled by configuring the appropriate re This realm has a few mandatory settings, and a number of optional settings. The available settings are described in detail in [OpenID Connect realm settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#ref-oidc-settings). This guide will explore the most common settings. -1. Create an OpenID Connect (the realm type is `oidc`) realm in your `elasticsearch.yml` file similar to what is shown below. +1. Create an OpenID Connect (the realm type is `oidc`) realm in your [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file similar to what is shown below. If you're using {{ece}} or {{ech}}, and you're using machine learning or a deployment with hot-warm architecture, you must include this configuration in the user settings section for each node type. @@ -415,7 +415,7 @@ OpenID Connect authentication in {{kib}} requires additional settings in additio If you're using a self-managed cluster, then, because OIDC requires {{es}} nodes to use TLS on the HTTP interface, you must configure {{kib}} to use a `https` URL to connect to {{es}}, and you may need to configure `elasticsearch.ssl.certificateAuthorities` to trust the certificates that {{es}} has been configured to use. -OpenID Connect authentication in {{kib}} is subject to the following timeout settings in `kibana.yml`: +OpenID Connect authentication in {{kib}} is subject to the following timeout settings in [`kibana.yml`](/deploy-manage/stack-settings.md): * [`xpack.security.session.idleTimeout`](/deploy-manage/security/kibana-session-management.md#session-idle-timeout) * [`xpack.security.session.lifespan`](/deploy-manage/security/kibana-session-management.md#session-lifespan) 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 dcde2f6a63..ade02b04b5 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/pki.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/pki.md @@ -18,7 +18,7 @@ You can also use PKI certificates to authenticate to {{kib}}, however this requi To use PKI in {{es}}, you configure a PKI realm, enable client authentication on the desired network layers (transport or http), and map the Distinguished Names (DNs) from the `Subject` field in the user certificates to roles. You create the mappings in a role mapping file or use the role mappings API. -1. Add a realm configuration for a `pki` realm to `elasticsearch.yml` under the `xpack.security.authc.realms.pki` namespace. You must explicitly set the `order` attribute. See [PKI realm settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#ref-pki-settings) for all of the options you can set for a `pki` realm. +1. Add a realm configuration for a `pki` realm to [`elasticsearch.yml`](/deploy-manage/stack-settings.md) under the `xpack.security.authc.realms.pki` namespace. You must explicitly set the `order` attribute. See [PKI realm settings](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#ref-pki-settings) for all of the options you can set for a `pki` realm. For example, the following snippet shows the most basic `pki` realm configuration: @@ -104,7 +104,7 @@ To use PKI in {{es}}, you configure a PKI realm, enable client authentication on The `certificate_authorities` option can be used as an alternative to the `truststore.path` setting, when the certificate files are PEM formatted. The setting accepts a list. The two options are exclusive, they cannot be both used simultaneously. - 2. If the trust store is password protected, the password should be configured by adding the appropriate `secure_password` setting [to the {{es}} keystore](/deploy-manage/security/secure-settings.md). For example, in a self-managed cluster, the following command adds the password for the example realm above: + 1. If the trust store is password protected, the password should be configured by adding the appropriate `secure_password` setting [to the {{es}} keystore](/deploy-manage/security/secure-settings.md). For example, in a self-managed cluster, the following command adds the password for the example realm above: ```shell bin/elasticsearch-keystore add \ 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 0faecf5e30..0f55d31026 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 @@ -23,7 +23,7 @@ Some systems, such as Active Directory, have a temporary lock-out period after s ## 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, specify the chain in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) 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 this automatic behavior, you can explicitly configure the `file` and `native` realms with the `order` and `enabled` settings. diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/saml.md b/deploy-manage/users-roles/cluster-or-deployment-auth/saml.md index d44af1e8b3..9815c65c35 100644 --- a/deploy-manage/users-roles/cluster-or-deployment-auth/saml.md +++ b/deploy-manage/users-roles/cluster-or-deployment-auth/saml.md @@ -101,7 +101,7 @@ If you're using a self-managed cluster, then perform the following additional st * Enable the token service. - The {{es}} SAML implementation makes use of the {{es}} token service. If you configure TLS on the HTTP interface, this service is automatically enabled. It can be explicitly configured by adding the following setting in your `elasticsearch.yml` file: + The {{es}} SAML implementation makes use of the {{es}} token service. If you configure TLS on the HTTP interface, this service is automatically enabled. It can be explicitly configured by adding the following setting in your [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file: ```yaml xpack.security.authc.token.enabled: true @@ -121,7 +121,7 @@ This realm has a few mandatory settings, and a number of optional settings. The This guide will walk you through the most common settings. -Create a realm by adding the following to your `elasticsearch.yml` configuration file. Each configuration value is explained below. +Create a realm by adding the following to your [`elasticsearch.yml`](/deploy-manage/stack-settings.md) configuration file. Each configuration value is explained below. If you're using {{ece}} or {{ech}}, and you're using machine learning or a deployment with hot-warm architecture, you must include this configuration in the user settings section for each node type. @@ -639,7 +639,7 @@ SAML authentication in {{kib}} requires additional settings in addition to the s If you're using a self-managed cluster, then, because OIDC requires {{es}} nodes to use TLS on the HTTP interface, you must configure {{kib}} to use a `https` URL to connect to {{es}}, and you may need to configure `elasticsearch.ssl.certificateAuthorities` to trust the certificates that {{es}} has been configured to use. -SAML authentication in {{kib}} is subject to the following timeout settings in `kibana.yml`: +SAML authentication in {{kib}} is subject to the following timeout settings in [`kibana.yml`](/deploy-manage/stack-settings.md): * [`xpack.security.session.idleTimeout`](/deploy-manage/security/kibana-session-management.md#session-idle-timeout) * [`xpack.security.session.lifespan`](/deploy-manage/security/kibana-session-management.md#session-lifespan) 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 ceae5141c8..711c4ea345 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 @@ -48,7 +48,7 @@ Security domains must be configured consistently across all nodes in cluster. In To configure a security domain: -1. Add a security domain configuration to `elasticsearch.yml` in the `xpack.security.authc.domains` namespace: +1. Add a security domain configuration to [`elasticsearch.yml`](/deploy-manage/stack-settings.md) in the `xpack.security.authc.domains` namespace: ```yaml xpack: diff --git a/explore-analyze/alerts-cases/alerts/alerting-setup.md b/explore-analyze/alerts-cases/alerts/alerting-setup.md index 151a2b3df1..075c08f2a9 100644 --- a/explore-analyze/alerts-cases/alerts/alerting-setup.md +++ b/explore-analyze/alerts-cases/alerts/alerting-setup.md @@ -15,7 +15,7 @@ mapped_pages: If you are using an **on-premises** {{stack}} deployment: -* In the `kibana.yml` configuration file, add the [`xpack.encryptedSavedObjects.encryptionKey`](kibana://reference/configuration-reference/alerting-settings.md#general-alert-action-settings) setting. +* In the [`kibana.yml`](/deploy-manage/stack-settings.md) configuration file, add the [`xpack.encryptedSavedObjects.encryptionKey`](kibana://reference/configuration-reference/alerting-settings.md#general-alert-action-settings) setting. * For emails to have a footer with a link back to {{kib}}, set the [`server.publicBaseUrl`](kibana://reference/configuration-reference/general-settings.md#server-publicbaseurl) configuration setting. If you are using an **on-premises** {{stack}} deployment with [**security**](../../../deploy-manage/security.md): diff --git a/explore-analyze/alerts-cases/cases/manage-cases.md b/explore-analyze/alerts-cases/cases/manage-cases.md index 202fab32f0..c62fe6bb16 100644 --- a/explore-analyze/alerts-cases/cases/manage-cases.md +++ b/explore-analyze/alerts-cases/cases/manage-cases.md @@ -52,7 +52,7 @@ For self-managed {{kib}}: 1. Create a preconfigured email connector. ::::{note} - At this time, email notifications support only preconfigured connectors, which are defined in the `kibana.yml` file. For examples, refer to [Email connectors](kibana://reference/connectors-kibana/pre-configured-connectors.md#preconfigured-email-configuration) and [Configure email accounts for well-known services](kibana://reference/connectors-kibana/email-action-type.md#configuring-email). + At this time, email notifications support only preconfigured connectors, which are defined in the [`kibana.yml`](/deploy-manage/stack-settings.md) file. For examples, refer to [Email connectors](kibana://reference/connectors-kibana/pre-configured-connectors.md#preconfigured-email-configuration) and [Configure email accounts for well-known services](kibana://reference/connectors-kibana/email-action-type.md#configuring-email). :::: 2. Set the `notifications.connectors.default.email` {{kib}} setting in kibana.yml to the name of your email connector. diff --git a/explore-analyze/alerts-cases/watcher/actions-email.md b/explore-analyze/alerts-cases/watcher/actions-email.md index ab7a52eb97..3896e40757 100644 --- a/explore-analyze/alerts-cases/watcher/actions-email.md +++ b/explore-analyze/alerts-cases/watcher/actions-email.md @@ -139,7 +139,7 @@ Address List {{watcher}} can send email using any SMTP email service. Email messages can contain basic HTML tags. You can control which groups of tags are allowed by [Configuring HTML Sanitization Options](#email-html-sanitization). -You configure the accounts {{watcher}} can use to send email in the `xpack.notification.email` namespace in `elasticsearch.yml`. The password for the specified SMTP user is stored securely in the [{{es}} keystore](../../../deploy-manage/security/secure-settings.md). +You configure the accounts {{watcher}} can use to send email in the `xpack.notification.email` namespace in [`elasticsearch.yml`](/deploy-manage/stack-settings.md). The password for the specified SMTP user is stored securely in the [{{es}} keystore](../../../deploy-manage/security/secure-settings.md). If your email account is configured to require two step verification, you need to generate and use a unique App Password to send email from {{watcher}}. Authentication will fail if you use your primary password. @@ -282,7 +282,7 @@ bin/elasticsearch-keystore add xpack.notification.email.account.exchange_account The `email` action supports sending messages with an HTML body. However, for security reasons, {{watcher}} [sanitizes](https://en.wikipedia.org/wiki/HTML_sanitization) the HTML. -You can control which HTML features are allowed or disallowed by configuring the `xpack.notification.email.html.sanitization.allow` and `xpack.notification.email.html.sanitization.disallow` settings in `elasticsearch.yml`. You can specify individual HTML elements and [HTML feature groups](elasticsearch://reference/elasticsearch/configuration-reference/watcher-settings.md#html-feature-groups). By default, {{watcher}} allows the following features: `body`, `head`, `_tables`, `_links`, `_blocks`, `_formatting` and `img:embedded`. +You can control which HTML features are allowed or disallowed by configuring the `xpack.notification.email.html.sanitization.allow` and `xpack.notification.email.html.sanitization.disallow` settings in [`elasticsearch.yml`](/deploy-manage/stack-settings.md). You can specify individual HTML elements and [HTML feature groups](elasticsearch://reference/elasticsearch/configuration-reference/watcher-settings.md#html-feature-groups). By default, {{watcher}} allows the following features: `body`, `head`, `_tables`, `_links`, `_blocks`, `_formatting` and `img:embedded`. For example, the following settings allow the HTML to contain tables and block elements, but disallow `

`, `

` and `
` tags. diff --git a/explore-analyze/alerts-cases/watcher/actions-jira.md b/explore-analyze/alerts-cases/watcher/actions-jira.md index b8432588fd..bad6b89571 100644 --- a/explore-analyze/alerts-cases/watcher/actions-jira.md +++ b/explore-analyze/alerts-cases/watcher/actions-jira.md @@ -77,7 +77,7 @@ The `project.key` (or `project.id`), the `issuetype.name` (or `issuetype.id`) an ## Configuring Jira accounts [configuring-jira] -You configure the accounts {{watcher}} can use to communicate with Jira in the `xpack.notification.jira` namespace in `elasticsearch.yml`. +You configure the accounts {{watcher}} can use to communicate with Jira in the `xpack.notification.jira` namespace in [`elasticsearch.yml`](/deploy-manage/stack-settings.md). {{watcher}} supports Basic Authentication for Jira Software. To configure a Jira account you need to specify (see [secure settings](../../../deploy-manage/security/secure-settings.md)): diff --git a/explore-analyze/alerts-cases/watcher/actions-pagerduty.md b/explore-analyze/alerts-cases/watcher/actions-pagerduty.md index 7cae701c35..c7177ea2f7 100644 --- a/explore-analyze/alerts-cases/watcher/actions-pagerduty.md +++ b/explore-analyze/alerts-cases/watcher/actions-pagerduty.md @@ -17,7 +17,7 @@ You configure PagerDuty actions in the `actions` array. Action-specific attribut The following snippet shows a simple PagerDuty action definition: -```js +```json "actions" : { "notify-pagerduty" : { "transform" : { ... }, @@ -35,7 +35,7 @@ The following snippet shows a simple PagerDuty action definition: To give the PagerDuty incident some more context, you can attach the payload as well as an array of contexts to the action. -```js +```json "actions" : { "notify-pagerduty" : { "throttle_period" : "5m", @@ -100,7 +100,7 @@ $$$pagerduty-event-trigger-context-attributes$$$ ## Configuring PagerDuty accounts [configuring-pagerduty] -You configure the accounts {{watcher}} uses to communicate with PagerDuty in the `xpack.notification.pagerduty` namespace in `elasticsearch.yml`. +You configure the accounts {{watcher}} uses to communicate with PagerDuty in the `xpack.notification.pagerduty` namespace in [`elasticsearch.yml`](/deploy-manage/stack-settings.md). To configure a PagerDuty account, you need the API integration key for the PagerDuty service you want to send notifications to. To get the key: @@ -121,7 +121,7 @@ bin/elasticsearch-keystore add xpack.notification.pagerduty.account.my_pagerduty Storing the service api key in the YAML file or via cluster update settings is still supported, but the keystore setting should be used. :::: -You can also specify defaults for the [PagerDuty event attributes](#pagerduty-event-trigger-incident-attributes): . +You can also specify defaults for the [PagerDuty event attributes](#pagerduty-event-trigger-incident-attributes): ```yaml xpack.notification.pagerduty: diff --git a/explore-analyze/alerts-cases/watcher/actions-slack.md b/explore-analyze/alerts-cases/watcher/actions-slack.md index 3d27f078ec..91044a39fb 100644 --- a/explore-analyze/alerts-cases/watcher/actions-slack.md +++ b/explore-analyze/alerts-cases/watcher/actions-slack.md @@ -138,7 +138,7 @@ In the following example, the watch input executes a search with a date histogra ## Configuring Slack Accounts [configuring-slack] -You configure the accounts {{watcher}} can use to communicate with Slack in the `xpack.notification.slack` namespace in `elasticsearch.yml`. +You configure the accounts {{watcher}} can use to communicate with Slack in the `xpack.notification.slack` namespace in [`elasticsearch.yml`](/deploy-manage/stack-settings.md). You need a Slack App with the [Incoming Webhooks feature](https://api.slack.com/messaging/webhooks) to configure a Slack account. Use the generated webhook URL to set up your Slack account in {{es}}. @@ -149,7 +149,7 @@ bin/elasticsearch-keystore add xpack.notification.slack.account.monitoring.secur ``` ::::{warning} -You can no longer configure Slack accounts using `elasticsearch.yml` settings. Use {{es}}'s secure [keystore](../../../deploy-manage/security/secure-settings.md) method instead. +You can no longer configure Slack accounts using [`elasticsearch.yml`](/deploy-manage/stack-settings.md) settings. Use {{es}}'s secure [keystore](../../../deploy-manage/security/secure-settings.md) method instead. :::: diff --git a/explore-analyze/alerts-cases/watcher/actions-webhook.md b/explore-analyze/alerts-cases/watcher/actions-webhook.md index 3c6674f245..9d10b25673 100644 --- a/explore-analyze/alerts-cases/watcher/actions-webhook.md +++ b/explore-analyze/alerts-cases/watcher/actions-webhook.md @@ -71,7 +71,7 @@ You can use basic authentication when sending a request to a secured webservice. By default, both the username and the password are stored in the `.watches` index in plain text. When the {{es}} {{security-features}} are enabled, {{watcher}} can encrypt the password before storing it. :::: -You can also use PKI-based authentication when submitting requests to a cluster that has {{es}} {{security-features}} enabled. When you use PKI-based authentication instead of HTTP basic auth, you don’t need to store any authentication information in the watch itself. To use PKI-based authentication, you [configure the SSL key settings](elasticsearch://reference/elasticsearch/configuration-reference/watcher-settings.md#ssl-notification-settings) for {{watcher}} in `elasticsearch.yml`. +You can also use PKI-based authentication when submitting requests to a cluster that has {{es}} {{security-features}} enabled. When you use PKI-based authentication instead of HTTP basic auth, you don’t need to store any authentication information in the watch itself. To use PKI-based authentication, you [configure the SSL key settings](elasticsearch://reference/elasticsearch/configuration-reference/watcher-settings.md#ssl-notification-settings) for {{watcher}} in [`elasticsearch.yml`](/deploy-manage/stack-settings.md). ## Query parameters [webhook-query-parameters] diff --git a/explore-analyze/alerts-cases/watcher/actions.md b/explore-analyze/alerts-cases/watcher/actions.md index cc797fe456..4d2c5a770a 100644 --- a/explore-analyze/alerts-cases/watcher/actions.md +++ b/explore-analyze/alerts-cases/watcher/actions.md @@ -140,7 +140,7 @@ PUT _watcher/watch/log_event_watch 1. There will be at least 15 minutes between subsequent action executions (applies to both `email_administrator` and `notify_pager` actions) -If you do not define a throttle period at the action or watch level, the global default throttle period is applied. Initially, this is set to 5 seconds. To change the global default, configure the `xpack.watcher.execution.default_throttle_period` setting in `elasticsearch.yml`: +If you do not define a throttle period at the action or watch level, the global default throttle period is applied. Initially, this is set to 5 seconds. To change the global default, configure the `xpack.watcher.execution.default_throttle_period` setting in [`elasticsearch.yml`](/deploy-manage/stack-settings.md): ```yaml xpack.watcher.execution.default_throttle_period: 15m diff --git a/explore-analyze/alerts-cases/watcher/enable-watcher.md b/explore-analyze/alerts-cases/watcher/enable-watcher.md index f47d927a3d..56efda3775 100644 --- a/explore-analyze/alerts-cases/watcher/enable-watcher.md +++ b/explore-analyze/alerts-cases/watcher/enable-watcher.md @@ -47,7 +47,7 @@ The following quotas apply when using the Elastic email service: ### Slack and PagerDuty integration [advanced-usage] -Under the hood, Alerting is configured through `elasticsearch.yml`. If you want to customize your Alerting settings, you can provide custom `elasticsearch.yml` snippet which is appended to your configuration. +Under the hood, Alerting is configured through [`elasticsearch.yml`](/deploy-manage/stack-settings.md). If you want to customize your Alerting settings, you can provide custom `elasticsearch.yml` snippet which is appended to your configuration. To provide the custom snippet, you can use the console [Elasticsearch settings editor](../../../deploy-manage/deploy/elastic-cloud/edit-stack-settings.md) for your deployment. @@ -61,7 +61,7 @@ There are three steps to integrate Elasticsearch with Slack: To add a webhook in Slack, select the settings icon, then choose **Add an app** and search for `webhook`. -The following example shows a configuration with multiple Slack accounts (`account1`, `account2`, and `account3`) specified in `elasticsearch.yml`: +The following example shows a configuration with multiple Slack accounts (`account1`, `account2`, and `account3`) specified in [`elasticsearch.yml`](/deploy-manage/stack-settings.md): ```sh xpack.notification.slack: diff --git a/explore-analyze/alerts-cases/watcher/watch-cluster-status.md b/explore-analyze/alerts-cases/watcher/watch-cluster-status.md index 70edbdab55..63468eaf73 100644 --- a/explore-analyze/alerts-cases/watcher/watch-cluster-status.md +++ b/explore-analyze/alerts-cases/watcher/watch-cluster-status.md @@ -182,7 +182,7 @@ PUT _watcher/watch/cluster_health_watch } ``` -For {{watcher}} to send email, you must configure an email account in your `elasticsearch.yml` configuration file and restart Elasticsearch. To add an email account, set the `xpack.notification.email.account` property. +For {{watcher}} to send email, you must configure an email account in your [`elasticsearch.yml`](/deploy-manage/stack-settings.md) configuration file and restart {{es}}. To add an email account, set the `xpack.notification.email.account` property. For example, the following snippet configures a single Gmail account named `work`: diff --git a/explore-analyze/discover/search-sessions.md b/explore-analyze/discover/search-sessions.md index 138f4a4192..fa866127f8 100644 --- a/explore-analyze/discover/search-sessions.md +++ b/explore-analyze/discover/search-sessions.md @@ -9,7 +9,7 @@ mapped_pages: # Run a search session in the background [search-sessions] ::::{admonition} Deprecated and disabled by default -Search Sessions are deprecated. They are disabled by default and will be removed in a future version. You can enable search sessions again by setting [`data.search.sessions.enabled`](kibana://reference/configuration-reference/search-sessions-settings.md) to `true` in the `kibana.yml` configuration file. +Search Sessions are deprecated. They are disabled by default and will be removed in a future version. You can enable search sessions again by setting [`data.search.sessions.enabled`](kibana://reference/configuration-reference/search-sessions-settings.md) to `true` in the [`kibana.yml`](/deploy-manage/stack-settings.md) configuration file. :::: diff --git a/explore-analyze/query-filter/tools/console.md b/explore-analyze/query-filter/tools/console.md index 94eaf51ea3..efe3f19a7c 100644 --- a/explore-analyze/query-filter/tools/console.md +++ b/explore-analyze/query-filter/tools/console.md @@ -235,6 +235,6 @@ Go to the **Config** tab of **Console** to customize its display, autocomplete, ## Disable Console [disable-console] -If you don’t want to use **Console**, you can disable it by setting `console.ui.enabled` to `false` in your `kibana.yml` configuration file. Changing this setting causes the server to regenerate assets on the next startup, which might cause a delay before pages start being served. +If you don’t want to use **Console**, you can disable it by setting `console.ui.enabled` to `false` in your [`kibana.yml`](/deploy-manage/stack-settings.md) configuration file. Changing this setting causes the server to regenerate assets on the next startup, which might cause a delay before pages start being served. You can also choose to only disable the persistent console that shows in the footer of several Kibana pages. To do that, go to **Stack Management** > **Advanced Settings**, and turn off the `devTools:enablePersistentConsole` setting. diff --git a/explore-analyze/report-and-share/reporting-troubleshooting-csv.md b/explore-analyze/report-and-share/reporting-troubleshooting-csv.md index 00b7a09885..e9e2a90f00 100644 --- a/explore-analyze/report-and-share/reporting-troubleshooting-csv.md +++ b/explore-analyze/report-and-share/reporting-troubleshooting-csv.md @@ -48,7 +48,7 @@ Some users may benefit from using the [scroll API](elasticsearch://reference/ela 1. Search is limited to 500 shards at the very most. 2. In cases where the data shards are unavailable or time out, the export may return partial data. -If you prefer the internal implementation of CSV export to use the scroll API, you can configure this in `kibana.yml`: +If you prefer the internal implementation of CSV export to use the scroll API, you can configure this in [`kibana.yml`](/deploy-manage/stack-settings.md): ```yaml xpack.reporting.csv.scroll.strategy: scroll diff --git a/explore-analyze/report-and-share/reporting-troubleshooting-pdf.md b/explore-analyze/report-and-share/reporting-troubleshooting-pdf.md index 0a21fd5d1b..3a837b2873 100644 --- a/explore-analyze/report-and-share/reporting-troubleshooting-pdf.md +++ b/explore-analyze/report-and-share/reporting-troubleshooting-pdf.md @@ -56,7 +56,7 @@ There is currently a known limitation with the data table visualization that onl ## Connection refused errors [reporting-troubleshooting-pdf-connection-refused] -If PDF or PNG reports are not working due to a "connection refused" or "unable to connect" type of error, ensure that the `kibana.yml` file uses the setting of `server.host: 0.0.0.0`. Also verify that no firewall rules or other routing rules prevent local services from accessing this address. Find out more at [Set the `server.host` for the headless browser](../report-and-share.md#set-reporting-server-host). +If PDF or PNG reports are not working due to a "connection refused" or "unable to connect" type of error, ensure that the [`kibana.yml`](/deploy-manage/stack-settings.md) file uses the setting of `server.host: 0.0.0.0`. Also verify that no firewall rules or other routing rules prevent local services from accessing this address. Find out more at [Set the `server.host` for the headless browser](../report-and-share.md#set-reporting-server-host). ## File permissions [reporting-troubleshooting-file-permissions] diff --git a/explore-analyze/report-and-share/reporting-troubleshooting.md b/explore-analyze/report-and-share/reporting-troubleshooting.md index 09593c81fd..b652f54101 100644 --- a/explore-analyze/report-and-share/reporting-troubleshooting.md +++ b/explore-analyze/report-and-share/reporting-troubleshooting.md @@ -56,7 +56,7 @@ Create a Markdown visualization and then create a PDF report. If this succeeds, ## Verbose logging [reporting-troubleshooting-verbose-logs] -{{kib}} server logs have a lot of useful information for troubleshooting and understanding how things work. The full logs from {{report-features}} are a good place to look when you encounter problems. In `kibana.yml`: +{{kib}} server logs have a lot of useful information for troubleshooting and understanding how things work. The full logs from {{report-features}} are a good place to look when you encounter problems. In [`kibana.yml`](/deploy-manage/stack-settings.md): ```yaml logging.root.level: all diff --git a/explore-analyze/visualize/custom-visualizations-with-vega.md b/explore-analyze/visualize/custom-visualizations-with-vega.md index abf87a85a0..a494c25322 100644 --- a/explore-analyze/visualize/custom-visualizations-with-vega.md +++ b/explore-analyze/visualize/custom-visualizations-with-vega.md @@ -1437,7 +1437,7 @@ The visualization automatically injects a `"projection"`, which you can use to c ##### Enable URL loading from any domain [vega-url-loading] -**Vega** can load data from any URL. To enable, set `vis_type_vega.enableExternalUrls: true` in `kibana.yml`, then restart {{kib}}. +**Vega** can load data from any URL. To enable, set `vis_type_vega.enableExternalUrls: true` in [`kibana.yml`](/deploy-manage/stack-settings.md), then restart {{kib}}. The files that the external URLs load must allow [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS). The remote URL must include `Access-Control-Allow-Origin`, which allows requests from the {{kib}} URL. diff --git a/explore-analyze/visualize/graph/graph-configuration.md b/explore-analyze/visualize/graph/graph-configuration.md index e81029d973..1b8bdb212d 100644 --- a/explore-analyze/visualize/graph/graph-configuration.md +++ b/explore-analyze/visualize/graph/graph-configuration.md @@ -20,7 +20,7 @@ The data in a saved workspace is like a report—​it is a saved snapshot that For this reason, you can configure the save policy for graph workspaces to ensure appropriate handling of your data. You can allow all users to save only the configuration information for a graph, require all users to explicitly include the workspace data, or completely disable the ability to save a workspace. -For example, to disable the save option entirely, set `xpack.graph.savePolicy` to `none` in `kibana.yml`: +For example, to disable the save option entirely, set `xpack.graph.savePolicy` to `none` in [`kibana.yml`](/deploy-manage/stack-settings.md): ```yaml xpack.graph.savePolicy: none @@ -56,7 +56,7 @@ You can also use security to grant read only or all access to different roles. W By default, users can configure *drilldown* URLs to display additional information about a selected vertex in a new browser window. For example, you could configure a drilldown URL to perform a web search for the selected vertex term. -To prevent users from adding drilldown URLs, set `xpack.graph.canEditDrillDownUrls` to `false` in `kibana.yml`: +To prevent users from adding drilldown URLs, set `xpack.graph.canEditDrillDownUrls` to `false` in [`kibana.yml`](/deploy-manage/stack-settings.md): ```yaml xpack.graph.canEditDrillDownUrls: false diff --git a/manage-data/lifecycle/data-tiers.md b/manage-data/lifecycle/data-tiers.md index 39a4be484d..8cbb1c9821 100644 --- a/manage-data/lifecycle/data-tiers.md +++ b/manage-data/lifecycle/data-tiers.md @@ -441,7 +441,7 @@ When data reaches the `cold` or `frozen` phases, it is automatically converted t ### Self-managed deployments [configure-data-tiers-on-premise] -For self-managed deployments, each node’s [data role](/deploy-manage/distributed-architecture/clusters-nodes-shards/node-roles.md#data-node-role) is configured in `elasticsearch.yml`. For example, the highest-performance nodes in a cluster might be assigned to both the hot and content tiers: +For self-managed deployments, each node’s [data role](/deploy-manage/distributed-architecture/clusters-nodes-shards/node-roles.md#data-node-role) is configured in [`elasticsearch.yml`](/deploy-manage/stack-settings.md). For example, the highest-performance nodes in a cluster might be assigned to both the hot and content tiers: ```yaml node.roles: ["data_hot", "data_content"] diff --git a/manage-data/lifecycle/index-lifecycle-management/migrate-index-allocation-filters-to-node-roles.md b/manage-data/lifecycle/index-lifecycle-management/migrate-index-allocation-filters-to-node-roles.md index 58ffd8473e..cbd5d80ecd 100644 --- a/manage-data/lifecycle/index-lifecycle-management/migrate-index-allocation-filters-to-node-roles.md +++ b/manage-data/lifecycle/index-lifecycle-management/migrate-index-allocation-filters-to-node-roles.md @@ -62,7 +62,7 @@ When you add a data tier to an {{ech}} deployment, one or more nodes are automat ], ``` -If you are directly managing your own cluster, configure the appropriate roles for each node in `elasticsearch.yml`. For example, the following setting configures a node to be a data-only node in the hot and content tiers. +If you are directly managing your own cluster, configure the appropriate roles for each node in [`elasticsearch.yml`](/deploy-manage/stack-settings.md). For example, the following setting configures a node to be a data-only node in the hot and content tiers. ```yaml node.roles [ data_hot, data_content ] diff --git a/manage-data/lifecycle/index-lifecycle-management/tutorial-customize-built-in-policies.md b/manage-data/lifecycle/index-lifecycle-management/tutorial-customize-built-in-policies.md index e3feb89c3a..0013bce619 100644 --- a/manage-data/lifecycle/index-lifecycle-management/tutorial-customize-built-in-policies.md +++ b/manage-data/lifecycle/index-lifecycle-management/tutorial-customize-built-in-policies.md @@ -51,7 +51,7 @@ To complete this tutorial, you’ll need: * Self-managed cluster: Assign `data_hot` and `data_warm` roles to nodes as described in [*Data tiers*](../data-tiers.md). - For example, include the `data_warm` node role in the `elasticsearch.yml` file of each node in the warm tier: + For example, include the `data_warm` node role in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file of each node in the warm tier: ```yaml node.roles: [ data_warm ] diff --git a/manage-data/migrate/migrate-from-a-self-managed-cluster-with-a-self-signed-certificate-using-remote-reindex.md b/manage-data/migrate/migrate-from-a-self-managed-cluster-with-a-self-signed-certificate-using-remote-reindex.md index 068e33ed80..a8e794ffae 100644 --- a/manage-data/migrate/migrate-from-a-self-managed-cluster-with-a-self-signed-certificate-using-remote-reindex.md +++ b/manage-data/migrate/migrate-from-a-self-managed-cluster-with-a-self-signed-certificate-using-remote-reindex.md @@ -54,7 +54,7 @@ The `Destination` cluster should be the same or newer version as the `Source` cl ## Step 4: Enable bundle and add `reindex` settings on the `Destination` cluster. [ec-remote-reindex-step4] 1. From your deployment page, go to the **Edit** page, click **Manage user settings and extensions**, select tab **Extensions** then enable `my_source_ca`. -2. Switch tab to **User settings**, append the following settings to the `elasticsearch.yml`. This step adds `source_server` to the `reindex.remote.whitelist`, points source CA bundle to be trusted by the `Destination` cluster using the setting `reindex.ssl.certificate_authorities`. +2. Switch tab to **User settings**, append the following settings to the [`elasticsearch.yml`](/deploy-manage/stack-settings.md). This step adds `source_server` to the `reindex.remote.whitelist`, points source CA bundle to be trusted by the `Destination` cluster using the setting `reindex.ssl.certificate_authorities`. ```text reindex.remote.whitelist: ["$SOURCE_SERVER:$PORT"] diff --git a/manage-data/use-case-use-elasticsearch-to-manage-time-series-data.md b/manage-data/use-case-use-elasticsearch-to-manage-time-series-data.md index 45240145e1..848b7353d9 100644 --- a/manage-data/use-case-use-elasticsearch-to-manage-time-series-data.md +++ b/manage-data/use-case-use-elasticsearch-to-manage-time-series-data.md @@ -34,7 +34,7 @@ The steps for setting up data tiers vary based on your deployment type: :::::: ::::::{tab-item} Self-managed -To assign a node to a data tier, add the respective [node role](elasticsearch://reference/elasticsearch/configuration-reference/node-settings.md#node-roles) to the node’s `elasticsearch.yml` file. Changing an existing node’s roles requires a [rolling restart](../deploy-manage/maintenance/start-stop-services/full-cluster-restart-rolling-restart-procedures.md#restart-cluster-rolling). +To assign a node to a data tier, add the respective [node role](elasticsearch://reference/elasticsearch/configuration-reference/node-settings.md#node-roles) to the node’s [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file. Changing an existing node’s roles requires a [rolling restart](../deploy-manage/maintenance/start-stop-services/full-cluster-restart-rolling-restart-procedures.md#restart-cluster-rolling). ```yaml # Content tier diff --git a/reference/fleet/air-gapped.md b/reference/fleet/air-gapped.md index ae9c55bc31..d19a70ef0c 100644 --- a/reference/fleet/air-gapped.md +++ b/reference/fleet/air-gapped.md @@ -95,7 +95,7 @@ For more information, refer to [Using a proxy server with {{agent}} and {{fleet} ## Host your own {{package-registry}} [air-gapped-diy-epr] ::::{note} -The {{package-registry}} packages include signatures used in [package verification](/reference/fleet/package-signatures.md). By default, {{fleet}} uses the Elastic public GPG key to verify package signatures. If you ever need to change this GPG key, use the `xpack.fleet.packageVerification.gpgKeyPath` setting in `kibana.yml`. For more information, refer to [{{fleet}} settings](kibana://reference/configuration-reference/fleet-settings.md). +The {{package-registry}} packages include signatures used in [package verification](/reference/fleet/package-signatures.md). By default, {{fleet}} uses the Elastic public GPG key to verify package signatures. If you ever need to change this GPG key, use the `xpack.fleet.packageVerification.gpgKeyPath` setting in [`kibana.yml`](/deploy-manage/stack-settings.md). For more information, refer to [{{fleet}} settings](kibana://reference/configuration-reference/fleet-settings.md). :::: diff --git a/reference/fleet/create-policy-no-ui.md b/reference/fleet/create-policy-no-ui.md index cfdb91c2da..7a2ad2f0f3 100644 --- a/reference/fleet/create-policy-no-ui.md +++ b/reference/fleet/create-policy-no-ui.md @@ -28,7 +28,7 @@ For more information, refer to [{{kib}} {{fleet}} APIs](/reference/fleet/fleet-a ## Option 2. Create agent policies with preconfiguration [use-preconfiguration-to-create-policy] -Add preconfigured policies to `kibana.yml` config. +Add preconfigured policies to [`kibana.yml`](/deploy-manage/stack-settings.md) config. For example, the following example adds a {{fleet-server}} policy for self-managed setup: diff --git a/reference/fleet/epr-proxy-setting.md b/reference/fleet/epr-proxy-setting.md index 3170c07382..e93da8461a 100644 --- a/reference/fleet/epr-proxy-setting.md +++ b/reference/fleet/epr-proxy-setting.md @@ -7,7 +7,7 @@ mapped_pages: {{fleet}} might be unable to access the {{package-registry}} because {{kib}} is behind a proxy server. -Also your organization might have network traffic restrictions that prevent {{kib}} from reaching the public {{package-registry}} (EPR) endpoints, like [epr.elastic.co](https://epr.elastic.co/), to download package metadata and content. You can route traffic to the public endpoint of EPR through a network gateway, then configure proxy settings in the [{{kib}} configuration file](kibana://reference/configuration-reference/fleet-settings.md), `kibana.yml`. For example: +Also your organization might have network traffic restrictions that prevent {{kib}} from reaching the public {{package-registry}} (EPR) endpoints, like [epr.elastic.co](https://epr.elastic.co/), to download package metadata and content. You can route traffic to the public endpoint of EPR through a network gateway, then configure proxy settings in the [{{kib}} configuration file](kibana://reference/configuration-reference/fleet-settings.md), [`kibana.yml`](/deploy-manage/stack-settings.md). For example: ```yaml xpack.fleet.registryProxyUrl: your-nat-gateway.corp.net diff --git a/reference/fleet/fleet-settings.md b/reference/fleet/fleet-settings.md index 9d780d51c1..172a7225e8 100644 --- a/reference/fleet/fleet-settings.md +++ b/reference/fleet/fleet-settings.md @@ -6,7 +6,7 @@ mapped_pages: # Fleet settings [fleet-settings] ::::{note} -The settings described here are configurable through the {{fleet}} UI. Refer to [{{fleet}} settings in {{kib}}](kibana://reference/configuration-reference/fleet-settings.md) for a list of settings that you can configure in the `kibana.yml` configuration file. +The settings described here are configurable through the {{fleet}} UI. Refer to [{{fleet}} settings in {{kib}}](kibana://reference/configuration-reference/fleet-settings.md) for a list of settings that you can configure in the [`kibana.yml`](/deploy-manage/stack-settings.md) configuration file. :::: diff --git a/reference/fleet/package-signatures.md b/reference/fleet/package-signatures.md index 26f8de816a..9c21d162ed 100644 --- a/reference/fleet/package-signatures.md +++ b/reference/fleet/package-signatures.md @@ -43,4 +43,4 @@ Here are some reasons why an integration might be flagged as unverified after in ## What if the Elastic key changes in the future? [what-if-key-changes] -In the unlikely event that the Elastic signing key changes in the future, any verified integration packages will continue to show as verified until new packages are installed or existing ones are upgraded. If this happens, you can set the `xpack.fleet.packageVerification.gpgKeyPath` setting in the `kibana.yml` configuration file to use the new key. +In the unlikely event that the Elastic signing key changes in the future, any verified integration packages will continue to show as verified until new packages are installed or existing ones are upgraded. If this happens, you can set the `xpack.fleet.packageVerification.gpgKeyPath` setting in the [`kibana.yml`](/deploy-manage/stack-settings.md) configuration file to use the new key. diff --git a/reference/security/fields-and-object-schemas/alert-schema.md b/reference/security/fields-and-object-schemas/alert-schema.md index 2ac960799f..60878795e6 100644 --- a/reference/security/fields-and-object-schemas/alert-schema.md +++ b/reference/security/fields-and-object-schemas/alert-schema.md @@ -136,7 +136,7 @@ The non-ECS fields listed below are beta and subject to change. | `kibana.alert.suppression.start` | The timestamp of the first document in the suppression group.
Type: date | | `kibana.alert.suppression.end` | The timestamp of the last document in the suppression group.
Type: date | | `kibana.alert.suppression.docs_count` | The number of suppressed alerts.
Type: long | -| `kibana.alert.url` | The shareable URL for the alert.
**Note:** This field appears only if you’ve set the [`server.publicBaseUrl`](kibana://reference/configuration-reference/general-settings.md#server-publicbaseurl) configuration setting in the `kibana.yml` file.
Type: long | +| `kibana.alert.url` | The shareable URL for the alert.
**Note:** This field appears only if you’ve set the [`server.publicBaseUrl`](kibana://reference/configuration-reference/general-settings.md#server-publicbaseurl) configuration setting in the [`kibana.yml`](/deploy-manage/stack-settings.md) file.
Type: long | | `kibana.alert.workflow_tags` | List of tags added to an alert.

This field can contain an array of values, for example: `["False Positive", "production"]`

Type: keyword
| | `kibana.alert.workflow_assignee_ids` | List of users assigned to an alert.

An array of unique identifiers (UIDs) for user profiles, for example: `["u_1-0CcWliOCQ9T2MrK5YDjhpxZ_AcxPKt3pwaICcnAUY_0, u_2-0CcWliOCQ9T2MrK5YDjhpxZ_AcxPKt3pwaICcnAUY_1"]`

UIDs are linked to user profiles that are automatically created when users first log into a deployment. These profiles contain names, emails, profile avatars, and other user settings.

Type: string[]
| | `kibana.alert.intended_timestamp` | Shows the alert’s estimated timestamp, had the alert been created when the source event initially occurred. The value in this field is determined by the way the rule was run:

- **Scheduled run**: Alerts created by scheduled runs have the same timestamp as the `@timestamp` field, which shows when the alert was created.
- **Manual run**: Alerts created by manual runs have a timestamp that falls within the time range specified for the manual run. For example, if you set a rule to manually run on event data from `10/01/2024 05:00 PM` to `10/07/2024 05:00 PM`, the `kibana.alert.intended_timestamp` value will be a date and time within that range.

Type: date
| diff --git a/solutions/observability/apm/applications-ui-settings.md b/solutions/observability/apm/applications-ui-settings.md index 3489c99aa7..ed1dac4129 100644 --- a/solutions/observability/apm/applications-ui-settings.md +++ b/solutions/observability/apm/applications-ui-settings.md @@ -60,7 +60,7 @@ To change APM settings, select **Settings** from any **Applications** page. The ## APM Indices [apm-indices-settings] -The Applications UI uses data views to query APM indices. In non-serverless versions, change the default APM indices that the Applications UI queries by opening the Applications UI and select **Settings** → **Indices**. Index settings in the Applications UI take precedence over those set in `kibana.yml`. +The Applications UI uses data views to query APM indices. In non-serverless versions, change the default APM indices that the Applications UI queries by opening the Applications UI and select **Settings** → **Indices**. Index settings in the Applications UI take precedence over those set in [`kibana.yml`](/deploy-manage/stack-settings.md). APM indices are {{kib}} Spaces-aware; Changes to APM index settings will only apply to the currently enabled space. See [Control access to APM data](/solutions/observability/apm/control-access-to-apm-data.md) for more information. diff --git a/solutions/observability/apm/cross-cluster-search.md b/solutions/observability/apm/cross-cluster-search.md index beff362592..aeb370e8a8 100644 --- a/solutions/observability/apm/cross-cluster-search.md +++ b/solutions/observability/apm/cross-cluster-search.md @@ -18,7 +18,7 @@ If you’re using the {{ech}}, see [Enable cross-cluster search](/deploy-manage/ To add remote clusters directly in {{kib}}, find `Remote Clusters` in the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). All you need is a name for the remote cluster and the seed node(s). Remember the names of your remote clusters, you’ll need them in step two. See [managing remote clusters](/deploy-manage/tools/cross-cluster-replication/set-up-cross-cluster-replication.md) for detailed information on the setup process. -Alternatively, you can [configure remote clusters](/deploy-manage/remote-clusters/remote-clusters-self-managed.md) in {{es}}'s `elasticsearch.yml` file. +Alternatively, you can [configure remote clusters](/deploy-manage/remote-clusters/remote-clusters-self-managed.md) in {{es}}'s [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file. **Step 2. Edit the default Applications UI {{data-sources}}.** @@ -31,7 +31,7 @@ You can also specify certain clusters to display data from, for example, `cluste There are two ways to edit the default {{data-source}}: * In the Applications UI — Find **Applications** in the main menu or use the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). Go to **Settings** → **Indices** and change all `xpack.apm.indices.*` values to include remote clusters. -* In `kibana.yml` — Update the [`xpack.apm.indices.*`](kibana://reference/configuration-reference/apm-settings.md) configuration values to include remote clusters. +* In [`kibana.yml`](/deploy-manage/stack-settings.md) — Update the [`xpack.apm.indices.*`](kibana://reference/configuration-reference/apm-settings.md) configuration values to include remote clusters. ::::{tip} diff --git a/solutions/observability/apm/get-started-fleet-managed-apm-server.md b/solutions/observability/apm/get-started-fleet-managed-apm-server.md index 9bfca274c5..1f59cb529a 100644 --- a/solutions/observability/apm/get-started-fleet-managed-apm-server.md +++ b/solutions/observability/apm/get-started-fleet-managed-apm-server.md @@ -14,7 +14,7 @@ This guide will explain how to set up and configure a Fleet-managed APM Server. You need {{es}} for storing and searching your data, and {{kib}} for visualizing and managing it. When setting these components up, you need: * {{es}} cluster and {{kib}} (version 9.0) with a basic license or higher. [Learn how to install the {{stack}} on your own hardware](/get-started/the-stack.md). -* Secure, encrypted connection between {{kib}} and {{es}}. For more information, see [Start the {{stack}} with security enabled](/deploy-manage/deploy/self-managed/installing-elasticsearch.md). +* Secure, encrypted connection between {{kib}} and {{es}}. For more information, refer to [](/deploy-manage/security/self-setup.md). * Internet connection for {{kib}} to download integration packages from the {{package-registry}}. Make sure the {{kib}} server can connect to `https://epr.elastic.co` on port `443`. If your environment has network traffic restrictions, there are ways to work around this requirement. See [Air-gapped environments](/reference/fleet/air-gapped.md) for more information. * {{kib}} user with `All` privileges on {{fleet}} and {{integrations}}. Since many Integrations assets are shared across spaces, users need the {{kib}} privileges in all spaces. * In the {{es}} configuration, the [built-in API key service](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md#api-key-service-settings) must be enabled. (`xpack.security.authc.api_key.enabled: true`) @@ -24,21 +24,21 @@ You need {{es}} for storing and searching your data, and {{kib}} for visualizing For testing purposes, you can use the following settings to get started quickly, but make sure you properly secure the {{stack}} before sending real data. -elasticsearch.yml example: +[`elasticsearch.yml`](/deploy-manage/stack-settings.md) example: ```yaml xpack.security.enabled: true xpack.security.authc.api_key.enabled: true ``` -kibana.yml example: +[`kibana.yml`](/deploy-manage/stack-settings.md) example: ```yaml elasticsearch.username: "kibana_system" <1> xpack.encryptedSavedObjects.encryptionKey: "something_at_least_32_characters" ``` -1. The password should be stored in the {{kib}} keystore as described in the [{{es}} security documentation](/deploy-manage/security/set-up-minimal-security.md). +1. The password should be stored in the {{kib}} keystore as described in the [{{es}} security documentation](/deploy-manage/security/secure-settings.md). ## Step 1: Set up Fleet [_step_1_set_up_fleet] @@ -142,8 +142,8 @@ An internet connection is required to install the APM integration via the Fleet ::::{dropdown} If you don’t have an internet connection If your environment has network traffic restrictions, there are other ways to install the APM integration. See [Air-gapped environments](/reference/fleet/air-gapped.md) for more information. -Option 1: Update `kibana.yml` -: Update `kibana.yml` to include the following, then restart {{kib}}. +Option 1: Update [`kibana.yml`](/deploy-manage/stack-settings.md) +: Update [`kibana.yml`](/deploy-manage/stack-settings.md) to include the following, then restart {{kib}}. ```yaml xpack.fleet.packages: diff --git a/solutions/observability/infra-and-hosts/step-2-enable-universal-profiling-in-kibana.md b/solutions/observability/infra-and-hosts/step-2-enable-universal-profiling-in-kibana.md index f9885bc43b..bfe08f4ae5 100644 --- a/solutions/observability/infra-and-hosts/step-2-enable-universal-profiling-in-kibana.md +++ b/solutions/observability/infra-and-hosts/step-2-enable-universal-profiling-in-kibana.md @@ -25,7 +25,7 @@ In ECE, you don’t need to perform any additional steps to enable the Universal ## Self-managed Elastic stack [_self_managed_elastic_stack] -1. Edit the Kibana YAML configuration file, usually named `kibana.yml` by adding previous configuration line. +1. Edit the Kibana YAML configuration file, usually named [`kibana.yml`](/deploy-manage/stack-settings.md) by adding previous configuration line. 2. Restart Kibana to reload the configuration. @@ -33,7 +33,7 @@ In ECE, you don’t need to perform any additional steps to enable the Universal If you’re using ECK, add the previous configuration line to the `kibana.k8s.elastic.co/v1` CRD, placing it under the `spec.config` key. Refer to the [ECK documentation](/deploy-manage/deploy/cloud-on-k8s/k8s-kibana-advanced-configuration.md#k8s-kibana-configuration) for more on configuring {{kib}}. -If you’re not using ECK, edit the `secret` or `configMap` holding the `kibana.yml` configuration file. Add the previously mentioned config line, and then perform a rolling restart of the Kibana deployment to reload the configuration. +If you’re not using ECK, edit the `secret` or `configMap` holding the [`kibana.yml`](/deploy-manage/stack-settings.md) configuration file. Add the previously mentioned config line, and then perform a rolling restart of the Kibana deployment to reload the configuration. Continue to [Step 3: Set up Universal Profiling in {{kib}}](step-3-set-up-universal-profiling-in-kibana.md). diff --git a/solutions/search/cross-cluster-search.md b/solutions/search/cross-cluster-search.md index 89cead6c84..445734b46b 100644 --- a/solutions/search/cross-cluster-search.md +++ b/solutions/search/cross-cluster-search.md @@ -982,9 +982,9 @@ If `skip_unavailable` is `true`, a {{ccs}}: * Ignores errors returned by the remote cluster, such as errors related to unavailable shards or indices. This can include errors related to search parameters such as [`allow_no_indices`](elasticsearch://reference/elasticsearch/rest-apis/api-conventions.md#api-multi-index) and [`ignore_unavailable`](elasticsearch://reference/elasticsearch/rest-apis/api-conventions.md#api-multi-index). * Ignores the [`allow_partial_search_results`](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-search#operation-search-allow_partial_search_results) parameter and the related `search.default_allow_partial_results` cluster setting when searching the remote cluster. This means searches on the remote cluster may return partial results. -You can modify the `skip_unavailable` setting by editing the `cluster.remote.` settings in the elasticsearch.yml config file. For example: +You can modify the `skip_unavailable` setting by editing the `cluster.remote.` settings in the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) config file. For example: -``` +```yml cluster: remote: cluster_one: @@ -995,7 +995,7 @@ cluster: skip_unavailable: true ``` -Or you can set the cluster.remote settings via the [cluster update settings](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings) API as shown [here](#ccs-remote-cluster-setup). +Or you can set the `cluster.remote` settings via the [cluster update settings](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-cluster-put-settings) API as shown [here](#ccs-remote-cluster-setup). When a remote cluster configured with `skip_unavailable: true` (such as `cluster_two` above) is disconnected or unavailable during a {{ccs}}, {{es}} won’t include matching documents from that cluster in the final results and the search will be considered successful (HTTP status 200 OK). diff --git a/solutions/search/search-applications/search-application-security.md b/solutions/search/search-applications/search-application-security.md index f557e56a88..2cb5360cff 100644 --- a/solutions/search/search-applications/search-application-security.md +++ b/solutions/search/search-applications/search-application-security.md @@ -187,7 +187,7 @@ There are two workarounds for this: ### Enable CORS on {{es}} [search-application-security-cors-elasticsearch] -This is the simplest option. Enable CORS on {{es}} by adding the following to your `elasticsearch.yml` file: +This is the simplest option. Enable CORS on {{es}} by adding the following to your [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file: ```yaml http.cors.allow-origin: "*" # Only use unrestricted value for local development @@ -198,14 +198,6 @@ http.cors.allow-methods: OPTIONS, POST http.cors.allow-headers: X-Requested-With, X-Auth-Token, Content-Type, Content-Length, Authorization, Access-Control-Allow-Headers, Accept ``` -On Elastic Cloud, you can do this by [editing your {{es}} user settings](../../../deploy-manage/deploy/elastic-cloud/edit-stack-settings.md#ec-add-user-settings). - -1. From your deployment menu, go to the **Edit** page. -2. In the **{{es}}** section, select **Manage user settings and extensions**. -3. Update the user settings with the configuration above. -4. Select **Save changes**. - - ### Proxy the request through a server that supports CORS [search-application-security-cors-proxy-request] If you are unable to enable CORS on {{es}}, you can proxy the request through a server that supports CORS. This is more complicated, but is a viable option. diff --git a/solutions/security/detect-and-alert.md b/solutions/security/detect-and-alert.md index 4a0066115d..f47ec82ad6 100644 --- a/solutions/security/detect-and-alert.md +++ b/solutions/security/detect-and-alert.md @@ -85,7 +85,7 @@ Depending on your privileges and whether detection system indices have already b If you get this message, a user with specific privileges must visit the **Alerts** or **Rules** page before you can view detection alerts and rules. Refer to [Enable and access detections](/solutions/security/detect-and-alert/detections-requirements.md#enable-detections-ui) for a list of all the requirements. ::::{note} - For **self-managed** {{stack}} deployments only, this message may be displayed when the [`xpack.encryptedSavedObjects.encryptionKey`](/solutions/security/detect-and-alert.md#detections-permissions) setting has not been added to the `kibana.yml` file. For more information, refer to [Configure self-managed {{stack}} deployments](/solutions/security/detect-and-alert/detections-requirements.md#detections-on-prem-requirements). + For **self-managed** {{stack}} deployments only, this message may be displayed when the [`xpack.encryptedSavedObjects.encryptionKey`](/solutions/security/detect-and-alert.md#detections-permissions) setting has not been added to the [`kibana.yml`](/deploy-manage/stack-settings.md) file. For more information, refer to [Configure self-managed {{stack}} deployments](/solutions/security/detect-and-alert/detections-requirements.md#detections-on-prem-requirements). :::: * **`Detection engine permissions required`** diff --git a/solutions/security/detect-and-alert/detections-requirements.md b/solutions/security/detect-and-alert/detections-requirements.md index 9468c65a25..fff28cd3fd 100644 --- a/solutions/security/detect-and-alert/detections-requirements.md +++ b/solutions/security/detect-and-alert/detections-requirements.md @@ -26,7 +26,7 @@ These steps are only required for **self-managed** deployments: * HTTPS must be configured for communication between [{{es}} and {{kib}}](/deploy-manage/security/set-up-basic-security-plus-https.md#encrypt-kibana-http). * In the `elasticsearch.yml` configuration file, set the `xpack.security.enabled` setting to `true`. For more information, refer to [Configuring {{es}}](/deploy-manage/deploy/self-managed/configure-elasticsearch.md) and [Security settings in {{es}}](elasticsearch://reference/elasticsearch/configuration-reference/security-settings.md). -* In the `kibana.yml` [configuration file](kibana://reference/configuration-reference/general-settings.md), add the `xpack.encryptedSavedObjects.encryptionKey` setting with any alphanumeric value of at least 32 characters. For example: +* In [`kibana.yml`](/deploy-manage/stack-settings.md), add the `xpack.encryptedSavedObjects.encryptionKey` setting with any alphanumeric value of at least 32 characters. For example: `xpack.encryptedSavedObjects.encryptionKey: 'fhjskloppd678ehkdfdlliverpoolfcr'` @@ -84,7 +84,7 @@ You can set limits to the number of bytes and the buffer size used to upload [va To set the value: -1. Open `kibana.yml` [configuration file](kibana://reference/configuration-reference/general-settings.md) or edit your {{kib}} cloud instance. +1. Open [`kibana.yml`](/deploy-manage/stack-settings.md) [configuration file](kibana://reference/configuration-reference/general-settings.md) or edit your {{kib}} cloud instance. 2. Add any of these settings and their required values: * `xpack.lists.maxImportPayloadBytes`: Sets the number of bytes allowed for uploading {{elastic-sec}} value lists (default `9000000`, maximum `100000000`). For every 10 megabytes, it is recommended to have an additional 1 gigabyte of RAM reserved for Kibana. diff --git a/solutions/security/detect-and-alert/view-detection-alert-details.md b/solutions/security/detect-and-alert/view-detection-alert-details.md index 39cf16dc62..37a452a8da 100644 --- a/solutions/security/detect-and-alert/view-detection-alert-details.md +++ b/solutions/security/detect-and-alert/view-detection-alert-details.md @@ -43,7 +43,7 @@ From the right panel, you can also: ::::{note} For {{stack}} users only: - If you’ve configured the [`server.publicBaseUrl`](kibana://reference/configuration-reference/general-settings.md#server-publicbaseurl) setting in the `kibana.yml` file, the shareable URL is also in the `kibana.alert.url` field. You can find the field by searching for `kibana.alert.url` on the **Table** tab. + If you’ve configured the [`server.publicBaseUrl`](kibana://reference/configuration-reference/general-settings.md#server-publicbaseurl) setting in the [`kibana.yml`](/deploy-manage/stack-settings.md) file, the shareable URL is also in the `kibana.alert.url` field. You can find the field by searching for `kibana.alert.url` on the **Table** tab. :::: diff --git a/solutions/security/endpoint-response-actions.md b/solutions/security/endpoint-response-actions.md index da7e63269a..d1f25d439a 100644 --- a/solutions/security/endpoint-response-actions.md +++ b/solutions/security/endpoint-response-actions.md @@ -217,7 +217,7 @@ You can follow this with the `execute` response action to upload and run scripts ::::{note} -The default file size maximum is 25 MB, configurable in `kibana.yml` with the `xpack.securitySolution.maxUploadResponseActionFileBytes` setting. You must enter the value in bytes (the maximum is `104857600` bytes, or 100 MB). +The default file size maximum is 25 MB, configurable in [`kibana.yml`](/deploy-manage/stack-settings.md) with the `xpack.securitySolution.maxUploadResponseActionFileBytes` setting. You must enter the value in bytes (the maximum is `104857600` bytes, or 100 MB). :::: diff --git a/solutions/security/investigate/open-manage-cases.md b/solutions/security/investigate/open-manage-cases.md index 3c3773d116..cd8ee8e523 100644 --- a/solutions/security/investigate/open-manage-cases.md +++ b/solutions/security/investigate/open-manage-cases.md @@ -64,7 +64,7 @@ For self-managed {{kib}}: 1. Create a preconfigured email connector. ::::{note} - At this time, email notifications support only [preconfigured email connectors](kibana://reference/connectors-kibana/pre-configured-connectors.md), which are defined in the `kibana.yml` file. + At this time, email notifications support only [preconfigured email connectors](kibana://reference/connectors-kibana/pre-configured-connectors.md), which are defined in the [`kibana.yml`](/deploy-manage/stack-settings.md) file. :::: 2. Set the `notifications.connectors.default.email` {{kib}} setting to the name of your email connector. diff --git a/troubleshoot/elasticsearch/remote-clusters.md b/troubleshoot/elasticsearch/remote-clusters.md index adfe6142c0..a5f7cb296e 100644 --- a/troubleshoot/elasticsearch/remote-clusters.md +++ b/troubleshoot/elasticsearch/remote-clusters.md @@ -54,7 +54,7 @@ The API should return `"connected" : true`. When using [API key authentication]( ### Enabling the remote cluster server [remote-clusters-troubleshooting-enable-server] -When using API key authentication, cross-cluster traffic happens on the remote cluster interface, instead of the transport interface. The remote cluster interface is not enabled by default. This means a node is not ready to accept incoming cross-cluster requests by default, while it is ready to send outgoing cross-cluster requests. Ensure you’ve enabled the remote cluster server on every node of the remote cluster. In `elasticsearch.yml`: +When using API key authentication, cross-cluster traffic happens on the remote cluster interface, instead of the transport interface. The remote cluster interface is not enabled by default. This means a node is not ready to accept incoming cross-cluster requests by default, while it is ready to send outgoing cross-cluster requests. Ensure you’ve enabled the remote cluster server on every node of the remote cluster. In [`elasticsearch.yml`](/deploy-manage/stack-settings.md): * Set [`remote_cluster_server.enabled`](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md#remote-cluster-network-settings) to `true`. * Configure the bind and publish address for remote cluster server traffic, for example using [`remote_cluster.host`](elasticsearch://reference/elasticsearch/configuration-reference/networking-settings.md#remote-cluster-network-settings). Without configuring the address, remote cluster traffic may be bound to the local interface, and remote clusters running on other machines can’t connect. @@ -154,7 +154,7 @@ Once you know the cause, you should be able to fix it by adjusting the remote cl Often, the issue is on the local cluster. For example, fix it by configuring necessary trusted CAs (`xpack.security.remote_cluster_client.ssl.certificate_authorities`). -If you change the `elasticsearch.yml` file, the associated cluster needs to be restarted for the changes to take effect. +If you change the [`elasticsearch.yml`](/deploy-manage/stack-settings.md) file, the associated cluster needs to be restarted for the changes to take effect. diff --git a/troubleshoot/elasticsearch/security/trb-security-internalserver.md b/troubleshoot/elasticsearch/security/trb-security-internalserver.md index c0fd3b66b0..516fddd9d9 100644 --- a/troubleshoot/elasticsearch/security/trb-security-internalserver.md +++ b/troubleshoot/elasticsearch/security/trb-security-internalserver.md @@ -19,5 +19,5 @@ mapped_pages: **Resolution:** -If the Security plugin is enabled in {{es}} but disabled in {{kib}}, you must still set `elasticsearch.username` and `elasticsearch.password` in `kibana.yml`. Otherwise, {{kib}} cannot connect to {{es}}. +If the Security plugin is enabled in {{es}} but disabled in {{kib}}, you must still set `elasticsearch.username` and `elasticsearch.password` in [`kibana.yml`](/deploy-manage/stack-settings.md). Otherwise, {{kib}} cannot connect to {{es}}. diff --git a/troubleshoot/elasticsearch/security/trb-security-saml.md b/troubleshoot/elasticsearch/security/trb-security-saml.md index d5ff2e4e85..63f0cb4b25 100644 --- a/troubleshoot/elasticsearch/security/trb-security-saml.md +++ b/troubleshoot/elasticsearch/security/trb-security-saml.md @@ -42,7 +42,7 @@ Some of the common SAML problems are shown below with tips on how to resolve the ``` **Resolution:** - We received a SAML response that is addressed to another SAML Service Provider. This usually means that the configured SAML Service Provider Entity ID in `elasticsearch.yml` (`sp.entity_id`) does not match what has been configured as the SAML Service Provider Entity ID in the SAML Identity Provider documentation. + We received a SAML response that is addressed to another SAML Service Provider. This usually means that the configured SAML Service Provider Entity ID in [`elasticsearch.yml`](/deploy-manage/stack-settings.md) (`sp.entity_id`) does not match what has been configured as the SAML Service Provider Entity ID in the SAML Identity Provider documentation. To resolve this issue, ensure that both the saml realm in {{es}} and the IdP are configured with the same string for the SAML Entity ID of the Service Provider. @@ -73,7 +73,7 @@ Some of the common SAML problems are shown below with tips on how to resolve the We could not find the metadata for the SAML Entity ID `your:entity.id` in the configured metadata file (`metadata.xml`). 1. Ensure that the `metadata.xml` file you are using is indeed the one provided by your SAML Identity Provider. - 2. Ensure that the `metadata.xml` file contains one element as follows: ` element as follows: `