[DOCS] Document when security auto configuration is skipped (#86575) (#86839)

* [DOCS] Document when security auto configuration is skipped

* Add xpack autoconfiguration parameter and links

* Fix typo and add related link 🔗

* Incorporate review feedback

* Remove keystore section and instead integrate into previous section

(cherry picked from commit acc22de)

Author: Adam Locke

docs/reference/settings/security-settings.asciidoc

@@ -33,6 +33,18 @@ information about disabling {security-features} in specific {kib} instances, see
 {kibana-ref}/security-settings-kb.html[{kib} security settings].
 --
 
+`xpack.security.autoconfiguration.enabled`::
+(<<static-cluster-setting,Static>>)
+Defaults to `true`, which enables
+<<configuring-stack-security,security auto configuration>>.
++
+--
+If set to `false`, security auto configuration is disabled, which is not 
+recommended. When disabled, security is not configured automatically when 
+starting {es} for the first time, which means that you must
+<<manually-configure-security,manually configure security>>. 
+--
+
 `xpack.security.hide_settings`::
 (<<static-cluster-setting,Static>>)
 A comma-separated list of settings that are omitted from the results of the

x-pack/docs/en/security/configuring-stack-security.asciidoc

@@ -15,6 +15,11 @@ 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`.
 
+NOTE: There are <<stack-skip-auto-configuration,some cases>> 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.
+
 [discrete]
 === Prerequisites
 
@@ -72,10 +77,19 @@ bin/kibana
 . Enroll {kib} using either interactive or detached mode.
 
   * *Interactive mode* (browser)
-  
+
   .. In your terminal, click the generated link to open {kib} in your browser.
   .. In your browser, paste the enrollment token that you copied and click the
   button to connect your {kib} instance with {es}.
++
+--
+[NOTE]
+====
+{kib} won't enter interactive mode if it detects existing credentials for {es} 
+(`elasticsearch.username` and `elasticsearch.password`) or an existing URL for 
+`elasticsearch.hosts`.
+====
+--
 
   * *Detached mode* (non-browser)
 +
@@ -112,3 +126,73 @@ include::{es-ref-dir}/setup/install/security-files-reference.asciidoc[leveloffse
 Additionally, when you use the enrollment token to connect {kib} to a secured {es} cluster, the HTTP layer CA certificate is retrieved from {es} and stored in the
 {kib} `/data` directory. This file establishes trust between {kib} and the {es}
 Certificate Authority (CA) for the HTTP layer.
+
+[discrete]
+[[stack-skip-auto-configuration]]
+=== Cases when security auto configuration is skipped
+When you start {es} for the first time, the node startup process tries to
+automatically configure security for you. The process runs some checks to
+determine: 
+
+* If this is the first time that the node is starting
+* Whether security is already configured
+* If the startup process can modify the node configuration
+
+If any of those checks fail, there's a good indication that you
+<<manually-configure-security,manually configured security>>, or don't want
+security to be configured automatically. In these cases, the node starts
+normally using the existing configuration. 
+
+[discrete]
+[[stack-existing-environment-detected]]
+==== Existing environment detected
+If certain directories already exist, there's a strong indication that the node
+was started previously. Similarly, if certain files _don't_ exist, or we can't 
+read or write to specific files or directories, then we're likely not running as 
+the user who installed {es} or an administrator imposed restrictions. If any of 
+the following environment checks are true, security isn't configured 
+automatically.
+
+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::
+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::
+This state likely indicates that an administrator made this directory read-only,
+or that the user who is starting {es} is not the user that installed {es}.
+
+[discrete]
+[[stack-existing-settings-detected]]
+==== Existing settings detected
+The following settings are incompatible with security auto configuration. If any
+of these settings exist, the node startup process skips configuring security
+automatically and the node starts normally.
+
+* {ref}/modules-node.html#node-roles[`node.roles`] is set to a value where the
+node can't be elected as `master`, or if the node can't hold data
+* {ref}/security-settings.html#general-security-settings[`xpack.security.autoconfiguration.enabled`] is set to `false`
+* {ref}/security-settings.html#general-security-settings[`xpack.security.enabled`] has a value set
+* Any of the
+{ref}/security-settings.html#transport-tls-ssl-settings[`xpack.security.transport.ssl.*`] or 
+{ref}/security-settings.html#http-tls-ssl-settings[`xpack.security.http.ssl.*`]
+settings have a value set in the `elasticsearch.yml` configuration file or in
+the `elasticsearch.keystore`
+* Any of the `discovery.type`, `discovery.seed_hosts`, or
+`cluster.initial_master_nodes`
+{ref}/modules-discovery-settings.html[discovery and cluster formation settings] 
+have a value set
++
+--
+[NOTE]
+====
+Exceptions are when `discovery.type` is set to `single-node`, or when
+`cluster.initial_master_nodes` exists but contains only the name of the current
+node.
+====
+--