Merge branch 'main' into 3720-value-report

Author: benironside

deploy-manage/deploy/cloud-enterprise/post-installation-steps.md

@@ -18,6 +18,12 @@ To start creating {{es}} deployments directly, refer to [](./working-with-deploy
 
 * Add your own [load balancer](./ece-load-balancers.md). Load balancers are user supplied and we do not currently provide configuration steps for you.
 
+* [Add more capacity](/deploy-manage/maintenance/ece/scale-out-installation.md) to your ECE installation, [resize your deployment](./resize-deployment.md), [upgrade to a newer {{es}} version](/deploy-manage/upgrade/deployment-or-cluster/upgrade-on-ece.md), and [add some plugins](./add-plugins.md).
+
+* [Configure ECE system deployments](./system-deployments-configuration.md) to ensure a highly available and resilient setup.
+
+* [Configure ECE for deployment templates](./configure-deployment-templates.md) to indicate what kind of hardware you have available for {{stack}} deployments.
+
 * In production systems, add your own [Cloud UI and Proxy certificates](../../security/secure-your-elastic-cloud-enterprise-installation/manage-security-certificates.md) to enable secure connections over HTTPS. The proxy certificate must be a wildcard certificate signed for the needed DNS records of your domain.
 
   ::::{note}
@@ -32,19 +38,21 @@ To start creating {{es}} deployments directly, refer to [](./working-with-deploy
   For example, if your proxy certificate is signed for `*.elastic-cloud-enterprise.example.com` and you have a wildcard DNS register pointing `*.elastic-cloud-enterprise.example.com` to your load balancer, you should configure `elastic-cloud-enterprise.example.com` as the **deployment domain name** in Platform → Settings. Refer to [](./change-endpoint-urls.md) for more details.
   ::::
 
-* If you received a license from Elastic, [manage the licenses](../../license/manage-your-license-in-ece.md) for your {{ece}} installation.
+* [Add a snapshot repository](../../tools/snapshot-and-restore/cloud-enterprise.md) to enable regular backups of your {{es}} clusters.
 
 * [Add more platform users](../../users-roles/cloud-enterprise-orchestrator/manage-users-roles.md) with role-based access control.
 
-* [Add a snapshot repository](../../tools/snapshot-and-restore/cloud-enterprise.md) to enable regular backups of your {{es}} clusters.
-
 * Consider enabling encryption-at-rest (EAR) on your hosts.
 
   :::{{note}}
   Encryption-at-rest is not implemented out of the box in {{ece}}. [Learn more](/deploy-manage/security/secure-your-elastic-cloud-enterprise-installation.md#ece_encryption).
   :::
 
-* Learn about common maintenance activities—such as adding capacity, applying OS patches, and addressing host failures--at [](../../maintenance/ece.md).
+* Set up [traffic filters](/deploy-manage/security/network-security.md) to restrict traffic to your deployment to only trusted IP addresses or VPCs.
+
+* Learn how to work around host maintenance or a host failure by [moving nodes off of an allocator](/deploy-manage/maintenance/ece/move-nodes-instances-from-allocators.md). For an overview of common ECE maintenance activities, refer to [ECE maintenance](../../maintenance/ece.md).
+
+* If you received a license from Elastic, [manage the licenses](../../license/manage-your-license-in-ece.md) for your {{ece}} installation.
 
 ::::{warning}
 During installation, the system generates secrets that are placed into the `/mnt/data/elastic/bootstrap-state/bootstrap-secrets.json` secrets file, unless you passed in a different path with the --host-storage-path parameter. Keep the information in the `bootstrap-secrets.json` file secure by removing it from its default location and placing it into a secure storage location.

deploy-manage/distributed-architecture/discovery-cluster-formation.md

@@ -8,7 +8,7 @@ products:
 ---
 
 ::::{important}
-The information provided in this section is applicable to all deployment types. However, the configuration settings detailed here are only valid for self-managed {{es}} deployments. For {{ecloud}} and {{serverless-full}} deployments this seciton should only be used for general information.
+The information provided in this section is applicable to all deployment types. However, the configuration settings detailed here are only valid for fully self-managed {{es}} deployments. For ECE, ECK, and ECH deployments, this section should only be used for general information and troubleshooting.
 ::::
 
 # Discovery and cluster formation [modules-discovery]

deploy-manage/monitor/_snippets/autoops-cc-regions.md

@@ -1,7 +1,12 @@
 | Region | Name |
 | --- | --- | 
+| us-east-1 | US East (N. Virginia) |
 | us-east-2 | US East (Ohio) |
+| us-west-2 | US West (Oregon) |
 | eu-west-1 | EU (Ireland) |
+| eu-west-2 | Europe (London) |
+| eu-central-1 | Europe (Frankfurt) |
 | ap-northeast-1 | Asia Pacific (Tokyo) |
+| ap-southeast-1 | Asia Pacific (Singapore) |
 
 More regions are coming soon.

deploy-manage/monitor/autoops/cc-autoops-as-cloud-connected.md

@@ -12,7 +12,7 @@ products:
 
 # AutoOps for self-managed clusters
 
-For ECE ({{ece}}), ECK ({{eck}}), and self-managed {{es}} clusters, AutoOps can be set up in all supported [regions](ec-autoops-regions.md#autoops-for-self-managed-clusters-regions) through [Cloud Connect](/deploy-manage/cloud-connect.md). More regions are coming soon.
+For ECE ({{ece}}), ECK ({{eck}}), and self-managed {{es}} clusters, AutoOps can be set up through [Cloud Connect](/deploy-manage/cloud-connect.md).
 
 Cloud Connect enables users of ECE, ECK, and self-managed clusters to use {{ecloud}} services. This means you can take advantage of the simplified cluster monitoring, real-time issue detection, and performance recommendations of AutoOps without having to run and manage the underlying infrastructure.
 

deploy-manage/monitor/autoops/cc-connect-self-managed-to-autoops.md

@@ -211,7 +211,7 @@ If you manually assign privileges, you won't be able to allow {{agent}} to acces
 
 :::::
 * **System architecture**: Select the system architecture of the machine running the agent.
-* **Metrics storage location**: Select where to store your metrics data from the list of available AWS regions.
+* **Metrics storage location**: Select where to store your metrics data from the list of available AWS regions:
 
   :::{include} ../_snippets/autoops-cc-regions.md
   :::

deploy-manage/monitor/autoops/ec-autoops-faq.md

@@ -43,7 +43,7 @@ Whether you are using AutoOps in your [{{ech}} deployment](/deploy-manage/monito
 * [Do I have to define an Elastic IP address to enable the agent to send data to {{ecloud}}?](#elastic-ip-address)
 
 **Collected metrics and data in AutoOps for self-managed clusters**
-* [Where are metrics stored in AutoOps for self-managed clusters?](#autoops-metrics-storage)
+* [Where are metrics stored in AutoOps for self-managed clusters?](#sm-autoops-metrics-storage)
 * [What information does {{agent}} gather from my cluster?](#extracted-info)
 * [How does AutoOps gather data from my cluster and ensure its security?](#data-gathering)
 * [Can I view the data gathered by {{agent}}?](#data-viewing-config)
@@ -91,7 +91,7 @@ $$$additional-payment$$$ **Does AutoOps for self-managed clusters incur addition
 $$$autoops-metrics-cost$$$ **Does shipping metrics data to {{ecloud}} incur additional costs?**
 :   Elastic does not charge extra for this service, but your cloud service provider (CSP) might. When sending metrics data from your cluster in a CSP region to {{ecloud}}, shipping costs are determined by your agreement with that CSP. 
 
-    You can [choose the CSP region where your data is stored](/deploy-manage/monitor/autoops/ec-autoops-regions.md#autoops-for-self-managed-clusters-regions).
+    You can [choose the CSP region where your data is stored](#sm-autoops-metrics-storage).
 
 $$$deployment-types$$$ **Which deployment types can be connected to AutoOps through Cloud Connect?**
 :   You can connect to AutoOps on a standalone {{stack}}, ECE ({{ece}}), or ECK ({{eck}}) deployment, both on-premise and in private cloud environments.
@@ -117,7 +117,7 @@ $$$elastic-ip-address$$$ **Do I have to define an Elastic IP address to enable t
 
 ### Collected metrics and data in AutoOps for self-managed clusters
 
-$$$autoops-metrics-storage$$$ **Where are metrics stored in AutoOps for self-managed clusters?**
+$$$sm-autoops-metrics-storage$$$ **Where are metrics stored in AutoOps for self-managed clusters?**
 :   You can choose where to store your metrics from the following AWS regions:
 
     :::{include} ../_snippets/autoops-cc-regions.md

deploy-manage/monitor/autoops/ec-autoops-regions.md

@@ -5,14 +5,9 @@ navigation_title: Regions
 applies_to:
   serverless:
   deployment:
-    self:
-    ece:
-    eck:
     ess: all
 products:
   - id: cloud-hosted
-  - id: cloud-kubernetes
-  - id: cloud-enterprise
 ---
 
 # AutoOps regions [ec-autoops-regions]
@@ -73,14 +68,3 @@ AutoOps for {{serverless-short}} is set up and enabled automatically in the foll
 The only exception is the **Search AI Lake** view, which is available in all CSP regions across AWS, Azure, and GCP.
 
 Learn how to [access](/deploy-manage/monitor/autoops/access-autoops-for-serverless.md) AutoOps in your {{serverless-short}} project.
-
-## AutoOps for self-managed clusters regions
-
-You can also use AutoOps with your ECE ({{ece}}), ECK ({{eck}}), or self-managed clusters through [Cloud Connect](/deploy-manage/cloud-connect.md). 
-
-This service is currently available in the following regions for AWS:
-
-:::{include} ../_snippets/autoops-cc-regions.md
-:::
-
-Learn how to [set up](/deploy-manage/monitor/autoops/cc-connect-self-managed-to-autoops.md) AutoOps in your ECE, ECK, or self-managed cluster.

deploy-manage/remote-clusters/ece-enable-ccs.md

@@ -32,8 +32,18 @@ To use CCS or CCR, your environment must meet the following criteria:
   :::{include} _snippets/remote-cluster-certificate-compatibility.md
   :::
 
-* Proxies must answer TCP requests on the port 9400. Check the [prerequisites for the ports that must permit outbound or inbound traffic](../deploy/cloud-enterprise/ece-networking-prereq.md).
-* Load balancers must pass-through TCP requests on port 9400. Check the [configuration details](../deploy/cloud-enterprise/ece-load-balancers.md).
+* ECE proxies must answer TCP requests on the port used by the selected [security model](./security-models.md):
+  * `9400` when using TLS certificate–based authentication (deprecated).
+  * `9443` when using API key–based authentication.
+  
+  For details, refer to the [remote cluster security models](./security-models.md) documentation and [ECE networking prerequisites](/deploy-manage/deploy/cloud-enterprise/ece-networking-prereq.md).
+
+* Load balancers must pass through TCP requests on the port that corresponds to the security model:
+  * `9400` for TLS certificate–based authentication (deprecated).
+  * `9443` for API key–based authentication.
+
+  For configuration details, refer to the [ECE load balancer requirements](../deploy/cloud-enterprise/ece-load-balancers.md).
+
 * If your deployment was created before ECE version `2.9.0`, the Remote clusters page in {{kib}} must be enabled manually from the **Security** page of your deployment, by selecting **Enable CCR** under **Trust management**.
 
 ::::{note}
@@ -62,4 +72,4 @@ The steps, information, and authentication method required to configure CCS and
 
 ## Remote clusters and network security [ece-ccs-ccr-network-security]
 
-If you have [network security policies](/deploy-manage/security/network-security-policies.md) applied to the remote cluster, you might need to take extra steps on the remote side to allow traffic from the local cluster. Some remote cluster configurations have limited compatibility with network security. To learn more, refer to [Remote clusters and network security](/deploy-manage/remote-clusters.md#network-security).
+If you have [network security policies](/deploy-manage/security/network-security-policies.md) applied to the remote cluster, you might need to take extra steps on the remote side to allow traffic from the local cluster. Some remote cluster configurations have limited compatibility with network security. To learn more, refer to [Remote clusters and network security](/deploy-manage/remote-clusters.md#network-security).

deploy-manage/remote-clusters/remote-clusters-api-key.md

@@ -25,7 +25,9 @@ To add a remote cluster using API key authentication:
 1. [Review the prerequisites](#remote-clusters-prerequisites-api-key)
 2. [Establish trust with a remote cluster](#remote-clusters-security-api-key)
 3. [Connect to a remote cluster](#remote-clusters-connect-api-key)
-4. [Configure roles and users](#remote-clusters-privileges-api-key)
+4. (Optional) [Configure strong identity verification](#remote-cluster-strong-verification)
+5. [Configure roles and users](#remote-clusters-privileges-api-key)
+
 
 If you run into any issues, refer to [Troubleshooting](/troubleshoot/elasticsearch/remote-clusters.md).
 
@@ -338,6 +340,85 @@ cluster:
 3. The address for the proxy endpoint used to connect to `cluster_three`.
 
 
+## Strong identity verification [remote-cluster-strong-verification]
+```{applies_to}
+deployment:
+  stack: preview 9.3
+```
+
+Cross-cluster API keys can be configured with strong identity verification to provide an additional layer of security. To enable this feature, a
+cross-cluster API key is created on the remote cluster with a certificate identity pattern that specifies which certificates are allowed
+to use it. The local cluster must then sign each request with its private key and include a certificate whose subject Distinguished Name
+(DN) matches the pattern. The remote cluster validates both that the certificate is trusted by its configured certificate authorities
+and that the certificate's subject matches the API key's identity pattern.
+
+Each remote cluster alias on the local cluster can have different remote signing configurations.
+
+### How strong identity verification works [_how_strong_verification_works]
+
+When a local cluster makes a request to a remote cluster using a cross-cluster API key:
+
+1. The local cluster signs the request headers with its configured private key and sends the signature and certificate chain as header
+   in the request to the remote cluster.
+2. The remote cluster verifies that the API key is valid.
+3. If the API key has a certificate identity pattern configured, the remote cluster extracts the Distinguished Name (DN) from the
+   certificate chain's leaf certificate and matches it against the certificate identity pattern.
+4. The remote cluster validates that the provided certificate chain is trusted.
+5. The remote cluster validates the signature and checks that the certificate is not expired.
+
+If any of these validation steps fail, the request is rejected.
+
+### Configure strong identity verification [_configure_strong_verification]
+
+To use strong identity verification, the local and remote clusters must be configured to sign request headers and to verify request
+headers. This can be done through the cluster settings API or `elasticsearch.yaml`.
+
+#### On the local cluster [_certificate_identity_local_cluster]
+
+When [adding the remote cluster](#using-the-es-api) to the local cluster, you must configure it to sign cross-cluster requests with a certificate–private key pair. You can generate a signing certificate using [elasticsearch-certutil](#remote-clusters-security-api-key-remote-action) or use an existing certificate. The private key can be encrypted and the password must be stored securely as a secure setting in Elasticsearch keystore. Refer to the [remote cluster settings reference](elasticsearch://reference/elasticsearch/configuration-reference/remote-clusters.md#remote-cluster-signing-settings) for details.
+
+```yaml
+cluster.remote.my_remote_cluster.signing.certificate: "path/to/signing/certificate.crt"
+cluster.remote.my_remote_cluster.signing.key: "path/to/signing/key.key"
+```
+
+::::{note}
+Replace `my_remote_cluster` with your remote cluster alias, and the paths with the paths to your certificate and key files.
+::::
+
+#### On the remote cluster [_certificate_identity_remote_cluster]
+
+The remote cluster must be configured with a certificate authority that trusts the certificate that was used to sign the request headers.
+
+```yaml
+cluster.remote.signing.certificate_authorities: "path/to/signing/certificate_authorities.crt"
+```
+
+When creating a cross-cluster API key on the remote cluster, specify a `certificate_identity` pattern that matches the Distinguished
+Name (DN) of the local cluster's certificate. Use the [Create Cross-Cluster API key](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-security-create-cross-cluster-api-key) API:
+
+```console
+POST /_security/cross_cluster/api_key
+{
+  "name": "my-cross-cluster-api-key",
+  "access": {
+    "search": [
+      {
+        "names": ["logs-*"]
+      }
+    ]
+  },
+  "certificate_identity": "CN=local-cluster.example.com,O=Example Corp,C=US"
+}
+```
+
+The `certificate_identity` field supports regular expressions. For example:
+
+* `"CN=.*.example.com,O=Example Corp,C=US"` matches any certificate with a CN ending in "example.com"
+* `"CN=local-cluster.*,O=Example Corp,C=US"` matches any certificate with a CN starting with "local-cluster"
+* `"CN=.*"` matches any certificate (not recommended for production)
+
+For a full list of available strong identity verification settings for remote clusters, refer to the [remote cluster settings reference](elasticsearch://reference/elasticsearch/configuration-reference/remote-clusters.md#remote-cluster-signing-settings).
 
 
 ## Configure roles and users [remote-clusters-privileges-api-key]

explore-analyze/dashboards/arrange-panels.md

@@ -29,7 +29,7 @@ To add a collapsible section:
    :::{tip}
    The section must be expanded in order to place panels into it.
    :::
-5. Just like any other panel, you can drag and drop the collapsible section to a different position in the dashboard.
+5. Like any other panel, you can drag and drop the collapsible section to a different position in the dashboard.
 6. Save the dashboard. 
 
 Users viewing the dashboard will find the section in the same state as when you saved the dashboard. If you saved it with the section collapsed, then it will also be collapsed by default for users.