Add acnchors to Kibana docs-settings (#78115) (#78307)

* Add acnchors to Kibana docs-settings

* Address PR comments

Co-authored-by: PavithraCP <[email protected]>

docs/settings/monitoring-settings.asciidoc

@@ -33,7 +33,7 @@ For more information, see
 |===
 | `monitoring.enabled`
   | Set to `true` (default) to enable the {monitor-features} in {kib}. Unlike the
-  `monitoring.ui.enabled` setting, when this setting is `false`, the
+  <<monitoring-ui-enabled, `monitoring.ui.enabled`>> setting, when this setting is `false`, the
   monitoring back-end does not run and {kib} stats are not sent to the monitoring
   cluster.
 
@@ -44,7 +44,7 @@ a|`monitoring.cluster_alerts.`
 
 | `monitoring.ui.elasticsearch.hosts`
   | Specifies the location of the {es} cluster where your monitoring data is stored.
-  By default, this is the same as `elasticsearch.hosts`. This setting enables
+  By default, this is the same as <<elasticsearch-hosts, `elasticsearch.hosts`>>. This setting enables
   you to use a single {kib} instance to search and visualize data in your
   production cluster as well as monitor data sent to a dedicated monitoring
   cluster.
@@ -58,7 +58,7 @@ a|`monitoring.cluster_alerts.`
   cluster uses the authenticated user's credentials, which must be the same on
   both the {es} monitoring cluster and the {es} production cluster. +
   +
-  If not set, {kib} uses the value of the `elasticsearch.username` setting.
+  If not set, {kib} uses the value of the <<elasticsearch-user-passwd, `elasticsearch.username`>> setting.
 
 | `monitoring.ui.elasticsearch.password`
   | Specifies the password used by {kib} monitoring to establish a persistent connection
@@ -69,11 +69,11 @@ a|`monitoring.cluster_alerts.`
   cluster uses the authenticated user's credentials, which must be the same on
   both the {es} monitoring cluster and the {es} production cluster. +
   +
-  If not set, {kib} uses the value of the `elasticsearch.password` setting.
+  If not set, {kib} uses the value of the <<elasticsearch-user-passwd, `elasticsearch.password`>> setting.
 
 | `monitoring.ui.elasticsearch.pingTimeout`
   | Specifies the time in milliseconds to wait for {es} to respond to internal
-  health checks. By default, it matches the `elasticsearch.pingTimeout` setting,
+  health checks. By default, it matches the <<elasticsearch-pingTimeout, `elasticsearch.pingTimeout`>> setting,
   which has a default value of `30000`.
 
 |===
@@ -112,7 +112,7 @@ about configuring {kib}, see
   | Specifies the number of log entries to display in *{stack-monitor-app}*.
   Defaults to `10`. The maximum value is `50`.
 
-| `monitoring.ui.enabled`
+|[[monitoring-ui-enabled]] `monitoring.ui.enabled`
   | Set to `false` to hide *{stack-monitor-app}*. The monitoring back-end
     continues to run as an agent for sending {kib} stats to the monitoring
     cluster. Defaults to `true`.

docs/settings/reporting-settings.asciidoc

@@ -20,7 +20,7 @@ You can configure `xpack.reporting` settings in your `kibana.yml` to:
 | [[xpack-enable-reporting]]`xpack.reporting.enabled` {ess-icon}
   | Set to `false` to disable the {report-features}.
 
-| `xpack.reporting.encryptionKey` {ess-icon}
+|[[xpack-reporting-encryptionKey]] `xpack.reporting.encryptionKey` {ess-icon}
   | Set to an alphanumeric, at least 32 characters long text string. By default, {kib} will generate a random key when it
   starts, which will cause pending reports to fail after restart. Configure this
   setting to preserve the same key across multiple restarts and multiple instances of {kib}.
@@ -53,20 +53,20 @@ proxy host requires that the {kib} server has network access to the proxy.
 [cols="2*<"]
 |===
 | `xpack.reporting.kibanaServer.port`
-  | The port for accessing {kib}, if different from the `server.port` value.
+  | The port for accessing {kib}, if different from the <<server-port, `server.port`>> value.
 
 | `xpack.reporting.kibanaServer.protocol`
   | The protocol for accessing {kib}, typically `http` or `https`.
 
-| `xpack.reporting.kibanaServer.hostname`
-  | The hostname for accessing {kib}, if different from the `server.host` value.
+|[[xpack-kibanaServer-hostname]] `xpack.reporting.kibanaServer.hostname`
+  | The hostname for accessing {kib}, if different from the <<server-host, `server.host`>> value.
 
 |===
 
 [NOTE]
 ============
 Reporting authenticates requests on the Kibana page only when the hostname matches the
-`xpack.reporting.kibanaServer.hostname` setting. Therefore Reporting would fail if the
+<<xpack-kibanaServer-hostname, `xpack.reporting.kibanaServer.hostname`>> setting. Therefore Reporting would fail if the
 set value redirects to another server. For that reason, `"0"` is an invalid setting
 because, in the Reporting browser, it becomes an automatic redirect to `"0.0.0.0"`.
 ============
@@ -97,8 +97,8 @@ reports, you might need to change the following settings.
 [NOTE]
 ============
 Running multiple instances of {kib} in a cluster for load balancing of
-reporting requires identical values for `xpack.reporting.encryptionKey` and, if
-security is enabled, `xpack.security.encryptionKey`.
+reporting requires identical values for <<xpack-reporting-encryptionKey, `xpack.reporting.encryptionKey`>> and, if
+security is enabled, <<xpack-security-encryptionKey, `xpack.security.encryptionKey`>>.
 ============
 
 [cols="2*<"]
@@ -177,7 +177,7 @@ available, but there will likely be errors in the visualizations in the report.
 [[reporting-chromium-settings]]
 ==== Chromium settings
 
-When `xpack.reporting.capture.browser.type` is set to `chromium` (default) you can also specify the following settings.
+When <<xpack-reporting-browser, `xpack.reporting.capture.browser.type`>> is set to `chromium` (default) you can also specify the following settings.
 
 [cols="2*<"]
 |===
@@ -246,7 +246,7 @@ a| `xpack.reporting.capture.browser`
   | Reporting uses a weekly index in {es} to store the reporting job and
   the report content. The index is automatically created if it does not already
   exist. Configure this to a unique value, beginning with `.reporting-`, for every
-  {kib} instance that has a unique `kibana.index` setting. Defaults to `.reporting`.
+  {kib} instance that has a unique <<kibana-index, `kibana.index`>> setting. Defaults to `.reporting`.
 
 | `xpack.reporting.roles.allow`
   | Specifies the roles in addition to superusers that can use reporting.

docs/settings/security-settings.asciidoc

@@ -49,11 +49,11 @@ xpack.security.authc:
       saml.saml1: <3>
           order: 1
           ...
-  
+
       saml.saml2: <4>
           order: 2
           ...
-  
+
       pki.realm3:
           order: 3
           ...
@@ -190,26 +190,26 @@ You can configure the following settings in the `kibana.yml` file.
 | `xpack.security.cookieName`
   | Sets the name of the cookie used for the session. The default value is `"sid"`.
 
-| `xpack.security.encryptionKey`
+|[[xpack-security-encryptionKey]] `xpack.security.encryptionKey`
   | An arbitrary string of 32 characters or more that is used to encrypt session information. Do **not** expose this key to users of {kib}. By
   default, a value is automatically generated in memory. If you use that default
   behavior, all sessions are invalidated when {kib} restarts.
   In addition, high-availability deployments of {kib} will behave unexpectedly
   if this setting isn't the same for all instances of {kib}.
 
-| `xpack.security.secureCookies`
+|[[xpack-security-secureCookies]] `xpack.security.secureCookies`
   | Sets the `secure` flag of the session cookie. The default value is `false`. It
-  is automatically set to `true` if `server.ssl.enabled` is set to `true`. Set
+  is automatically set to `true` if <<server-ssl-enabled, `server.ssl.enabled`>> is set to `true`. Set
   this to `true` if SSL is configured outside of {kib} (for example, you are
   routing requests through a load balancer or proxy).
 
 | `xpack.security.sameSiteCookies` {ess-icon}
   | Sets the `SameSite` attribute of the session cookie. This allows you to declare whether your cookie should be restricted to a first-party or same-site context.
   Valid values are `Strict`, `Lax`, `None`.
-  This is *not set* by default, which modern browsers will treat as `Lax`. If you use Kibana embedded in an iframe in modern browsers, you might need to set it to `None`. Setting this value to `None` requires cookies to be sent over a secure connection by setting `xpack.security.secureCookies: true`. Some old versions of IE11 do not support `SameSite: None`.
+  This is *not set* by default, which modern browsers will treat as `Lax`. If you use Kibana embedded in an iframe in modern browsers, you might need to set it to `None`. Setting this value to `None` requires cookies to be sent over a secure connection by setting <<xpack-security-secureCookies, `xpack.security.secureCookies`>>: true`. Some old versions of IE11 do not support `SameSite: None`.
 
-| `xpack.security.session.idleTimeout` {ess-icon}
-  | Ensures that user sessions will expire after a period of inactivity. This and `xpack.security.session.lifespan` are both
+|[[xpack-session-idleTimeout]] `xpack.security.session.idleTimeout` {ess-icon}
+  | Ensures that user sessions will expire after a period of inactivity. This and <<xpack-session-lifespan,`xpack.security.session.lifespan`>> are both
 highly recommended. By default, this setting is not set.
 
 2+a|
@@ -218,9 +218,9 @@ highly recommended. By default, this setting is not set.
 The format is a string of `<count>[ms\|s\|m\|h\|d\|w\|M\|Y]` (e.g. '20m', '24h', '7d', '1w').
 ============
 
-| `xpack.security.session.lifespan` {ess-icon}
+|[[xpack-session-lifespan]] `xpack.security.session.lifespan` {ess-icon}
   | Ensures that user sessions will expire after the defined time period. This behavior also known as an "absolute timeout". If
-this is _not_ set, user sessions could stay active indefinitely. This and `xpack.security.session.idleTimeout` are both highly
+this is _not_ set, user sessions could stay active indefinitely. This and <<xpack-session-idleTimeout, `xpack.security.session.idleTimeout`>> are both highly
 recommended. By default, this setting is not set.
 
 2+a|

docs/settings/telemetry-settings.asciidoc

@@ -19,7 +19,7 @@ See our https://www.elastic.co/legal/privacy-statement[Privacy Statement] to lea
 
 [cols="2*<"]
 |===
-| `telemetry.enabled`
+|[[telemetry-enabled]] `telemetry.enabled`
   | Set to `true` to send cluster statistics to Elastic. Reporting your
   cluster statistics helps us improve your user experience. Your data is never
   shared with anyone. Set to `false` to disable statistics reporting from any
@@ -31,16 +31,16 @@ See our https://www.elastic.co/legal/privacy-statement[Privacy Statement] to lea
   it is behind a firewall and falls back to `'browser'` to send it from users' browsers
   when they are navigating through {kib}. Defaults to `'server'`.
 
-| `telemetry.optIn`
+|[[telemetry-optIn]] `telemetry.optIn`
   | Set to `true` to automatically opt into reporting cluster statistics. You can also opt out through
   *Advanced Settings* in {kib}. Defaults to `true`.
 
 | `telemetry.allowChangingOptInStatus`
-  | Set to `true` to allow overwriting the `telemetry.optIn` setting via the {kib} UI. Defaults to `true`. +
+  | Set to `true` to allow overwriting the <<telemetry-optIn, `telemetry.optIn`>> setting via the {kib} UI. Defaults to `true`. +
 
 |===
 
 [NOTE]
 ============
-When `false`, `telemetry.optIn` must be `true`. To disable telemetry and not allow users to change that parameter, use `telemetry.enabled`.
+When `false`, <<telemetry-optIn, `telemetry.optIn`>> must be `true`. To disable telemetry and not allow users to change that parameter, use <<telemetry-enabled, `telemetry.enabled`>>.
 ============

docs/setup/secure-settings.asciidoc

@@ -19,7 +19,7 @@ bin/kibana-keystore create
 ----------------------------------------------------------------
 
 The file `kibana.keystore` will be created in the directory defined by the
-`path.data` configuration setting.
+<<path-data, `path.data`>> configuration setting.
 
 [float]
 [[list-settings]]