Enhance Fleet & Agent docs with comprehensive deployment guides

reference/fleet/_snippets/best-practices-certificates.md

@@ -0,0 +1,8 @@
+### Certificate management
+
+Follow these best practices for managing certificates:
+
+* Never use self-signed certificates in production. Generate certificates using a trusted CA or your organization's CA.
+* When generating certificates, include all hostnames and IP addresses that will be used in the certificate's Subject Alternative Name (SAN) list.
+* Store private keys securely and use appropriate file permissions. Consider using encrypted keys with passphrases.
+* Plan for certificate rotation. For more information, refer to [Certificate rotation](/reference/fleet/certificates-rotation.md).

reference/fleet/_snippets/best-practices-config-management.md

@@ -0,0 +1,8 @@
+### Configuration management
+
+Follow these best practices for managing configuration:
+
+* After initial installation or enrollment, manage most settings through {{fleet}} policies rather than CLI flags.
+* Document your configuration to keep track of which settings are configured using CLI, environment variables, and policies.
+* Test policy changes in a non-production environment before applying to production.
+* For containerized deployments, use environment variables to provide host-specific settings while keeping policies generic.

reference/fleet/_snippets/config-hierarchy.md

@@ -0,0 +1,7 @@
+The configuration precedence is as follows (highest to lowest):
+
+1. CLI flags (during installation/enrollment)
+2. Environment variables (during installation/enrollment)
+3. Policy configuration (after enrollment, downloaded from {{fleet}})
+
+Settings provided using CLI or environment variables during installation are used for the initial bootstrap or enrollment. After enrollment, the component downloads its policy from {{fleet}}, and policy settings take precedence for most configuration options (except those that must be provided using CLI or environment variables).

reference/fleet/_snippets/policy-cli-precedence-intro.md

@@ -0,0 +1 @@
+Understanding what can be configured using policy and what must be provided using CLI or environment variables is crucial for managing deployments.

reference/fleet/_snippets/security-considerations-common.md

@@ -0,0 +1,6 @@
+Follow these security best practices:
+
+* Use mutual TLS to output connections in high-security environments.
+* Prefer API keys or service tokens over basic authentication for output connections.
+* Consider network segmentation to limit which hosts can connect to {{fleet-server}}.
+* Keep component versions up to date to benefit from security patches.

reference/fleet/add-fleet-server-cloud.md

@@ -18,6 +18,10 @@ To use {{fleet}} for central management, a [{{fleet-server}}](/reference/fleet/f
 
 {{fleet-server}} can be provisioned and hosted on {{ecloud}}. When the Cloud deployment is created, a highly available set of {{fleet-server}}s is provisioned automatically.
 
+::::{note}
+For comprehensive information about {{fleet-server}} configuration flags, environment variables, mutual TLS (mTLS) setup, and policy vs CLI precedence, refer to [How to deploy {{fleet-server}}](/reference/fleet/deploy-fleet-server.md). This guide provides detailed configuration organized by connection type.
+::::
+
 This approach might be right for you if you want to reduce on-prem compute resources and you’d like Elastic to take care of provisioning and life cycle management of your deployment.
 
 With this approach, multiple {{fleet-server}}s are automatically provisioned to satisfy the chosen instance size (instance sizes are modified to satisfy the scale requirement). You can also choose the resources allocated to each {{fleet-server}} and whether you want each {{fleet-server}} to be deployed in multiple availability zones. If you choose multiple availability zones to address your fault-tolerance requirements, those instances are also utilized to balance the load.

reference/fleet/add-fleet-server-kubernetes.md

@@ -28,6 +28,10 @@ This guide assumes familiarity with Kubernetes concepts and resources, such as `
 
 To use {{fleet}} for central management, a [{{fleet-server}}](/reference/fleet/fleet-server.md) must be running and accessible to your hosts.
 
+::::{note}
+For comprehensive information about {{fleet-server}} configuration flags, environment variables, mutual TLS (mTLS) setup, and policy vs CLI precedence, refer to [How to deploy {{fleet-server}}](/reference/fleet/deploy-fleet-server.md). This guide provides detailed configuration organized by connection type.
+::::
+
 You can deploy {{fleet-server}} on Kubernetes and manage it yourself. In this deployment model, you are responsible for high-availability, fault-tolerance, and lifecycle management of the {{fleet-server}}.
 
 To deploy a {{fleet-server}} on Kubernetes and register it into {{fleet}} you will need the following details:
@@ -75,7 +79,7 @@ Before deploying {{fleet-server}}, you need to:
 
 ### {{fleet-server}} and SSL/TLS certificates considerations [add-fleet-server-kubernetes-cert-prereq]
 
-This section shows the minimum requirements in terms of Transport Layer Security (TLS) certificates for the {{fleet-server}}, assuming no mutual TLS (mTLS) is needed. Refer to [One-way and mutual TLS certifications flow](/reference/fleet/tls-overview.md) and [{{agent}} deployment models with mutual TLS](/reference/fleet/mutual-tls.md) for more information about the configuration needs of both approaches.
+This section shows the minimum requirements in terms of Transport Layer Security (TLS) certificates for the {{fleet-server}}, assuming no mutual TLS (mTLS) is needed. Refer to [One-way and mutual TLS certifications flow](/reference/fleet/tls-overview.md) and [{{agent}} deployment models with mutual TLS](/reference/fleet/mutual-tls.md) for more information about the configuration needs of both approaches. For detailed configuration information organized by connection type, refer to [How to deploy Fleet Server](/reference/fleet/deploy-fleet-server.md).
 
 There are two main traffic flows for {{fleet-server}}, each with different TLS requirements:
 

reference/fleet/add-fleet-server-mixed.md

@@ -17,6 +17,10 @@ To use {{fleet}} for central management, a [{{fleet-server}}](/reference/fleet/f
 
 Another approach is to deploy a cluster of {{fleet-server}}s on-premises and connect them back to {{ecloud}} with access to {{es}} and {{kib}}. In this [deployment model](/reference/fleet/deployment-models.md), you are responsible for high-availability, fault-tolerance, and lifecycle management of {{fleet-server}}.
 
+::::{note}
+For comprehensive information about {{fleet-server}} configuration flags, environment variables, mutual TLS (mTLS) setup, and policy vs CLI precedence, refer to [How to deploy {{fleet-server}}](/reference/fleet/deploy-fleet-server.md). This guide provides detailed configuration organized by connection type.
+::::
+
 This approach might be right for you if you would like to limit the control plane traffic out of your data center. For example, you might take this approach if you are a managed service provider or a larger enterprise that segregates its networks.
 
 This approach might *not* be right for you if you don’t want to manage the life cycle of an extra compute resource in your environment for {{fleet-server}} to reside on.

reference/fleet/add-fleet-server-on-prem.md

@@ -18,6 +18,10 @@ To use {{fleet}} for central management, a [{{fleet-server}}](/reference/fleet/f
 
 You can deploy {{fleet-server}} on-premises and manage it yourself. In this [deployment model](/reference/fleet/deployment-models.md), you are responsible for high-availability, fault-tolerance, and lifecycle management of {{fleet-server}}.
 
+::::{note}
+For comprehensive information about {{fleet-server}} configuration flags, environment variables, mutual TLS (mTLS) setup, and policy vs CLI precedence, refer to [How to deploy {{fleet-server}}](/reference/fleet/deploy-fleet-server.md). This guide provides detailed configuration organized by connection type.
+::::
+
 This approach might be right for you if you would like to limit the control plane traffic out of your data center or have requirements for fully air-gapped operations. For example, you might take this approach if you need to satisfy data governance requirements or you want agents to only have access to a private segmented network.
 
 This approach might *not* be right for you if you don’t want to manage the life cycle of your Elastic environment and instead would like that to be handled by Elastic.
@@ -112,14 +116,13 @@ To add a {{fleet-server}}:
     * Use **Advanced** if you want to either:
 
         * **Use your own {{fleet-server}} policy.** {{fleet-server}} policies manage and configure the {{agent}} running on {{fleet-server}} hosts to launch a {{fleet-server}} process. You can create a new {{fleet-server}} policy or select an existing one. Alternatively you can [create a {{fleet-server}} policy without using the UI](/reference/fleet/create-policy-no-ui.md), and then select the policy here.
-        * **Use your own TLS certificates.** TLS certificates encrypt traffic between {{agent}}s and {{fleet-server}}. To learn how to generate certs, refer to [Configure SSL/TLS for self-managed {{fleet-server}}s](/reference/fleet/secure-connections.md).
+        * **Use your own TLS certificates.** TLS certificates encrypt traffic between {{agent}}s and {{fleet-server}}. To learn how to generate certs, refer to [Configure SSL/TLS for self-managed {{fleet-server}}s](/reference/fleet/secure-connections.md). For detailed information about configuring TLS and mTLS connections, refer to [How to deploy Fleet Server](/reference/fleet/deploy-fleet-server.md).
 
             ::::{note}
             If you are providing your own certificates:
 
             * Before running the `install` command, make sure you replace the values in angle brackets.
             * The URL specified by `--url` must match the DNS name used to generate the certificate specified by `--fleet-server-cert`.
-
             ::::
 
 
@@ -132,8 +135,8 @@ To add a {{fleet-server}}:
 
     ::::{note}
     * The fields to configure {{fleet-server}} hosts are not available if the hosts are already configured outside of {{fleet}}. For more information, refer to [{{fleet}} settings in {{kib}}](kibana://reference/configuration-reference/fleet-settings.md).
-    * When using the **Advanced** option, it’s recommended to generate a unique service token for each {{fleet-server}}. For other ways to generate service tokens, refer to [`elasticsearch-service-tokens`](elasticsearch://reference/elasticsearch/command-line-tools/service-tokens-command.md).
-    * If you’ve configured a non-default port for {{fleet-server}} in the {{fleet-server}} integration, you need to include the `--fleet-server-host` and `--fleet-server-port` options in the `elastic-agent install` command. Refer to the [install command documentation](/reference/fleet/agent-command-reference.md#elastic-agent-install-command) for details.
+    * When using the **Advanced** option, it's recommended to generate a unique service token for each {{fleet-server}}. For other ways to generate service tokens, refer to [`elasticsearch-service-tokens`](elasticsearch://reference/elasticsearch/command-line-tools/service-tokens-command.md).
+    * If you've configured a non-default port for {{fleet-server}} in the {{fleet-server}} integration, you need to include the `--fleet-server-host` and `--fleet-server-port` options in the `elastic-agent install` command. Refer to the [install command documentation](/reference/fleet/agent-command-reference.md#elastic-agent-install-command) for details.
 
     ::::