Merge branch 'main' into issue-3228-estore

Author: natasha-moore-elastic

deploy-manage/cloud-organization/billing/cloud-hosted-deployment-billing-dimensions.md

@@ -78,7 +78,7 @@ As is common with Cloud providers, we meter and bill snapshot storage using two
 
    This is calculated by metering the storage space (GBs) occupied by all snapshots of all deployments tied to an account. The same unit price applies to all regions. To calculate the due charges, we meter the amount of storage on an hourly basis and produce an average size (in GB) for a given month. The average amount is then used to bill the account for the GB/month used within a billing cycle (a calendar month).
 
-   For example, if the storage used in April 2019 was 100GB for 10 days, and then 130GB for the remaining 20 days of the month, the average storage would be 120 GB/month, calculated as (100*10 + 130*20)/30.
+   For example, if the storage used in April 2019 was 100GB for 10 days, and then 130GB for the remaining 20 days of the month, the average storage would be 120 GB/month, calculated as `(100*10 + 130*20)/30`.
 
    We provide a free allowance of 100 GB/month to all accounts across all the account deployments. Any metered storage usage below that amount will not be billed. Whenever the 100 GB/month threshold is crossed, we bill for the storage used in excess of the 100GB/month free allowance.
 

deploy-manage/cloud-organization/billing/elastic-observability-billing-dimensions.md

@@ -26,8 +26,8 @@ Refer to [Serverless billing dimensions](serverless-project-billing-dimensions.m
 
 ## Synthetics [synthetics-billing]
 
-[Synthetic monitoring](/solutions/observability/synthetics/index.md) is an optional add-on to Observability Serverless projects that allows you to periodically check the status of your services and applications as a part of your "Complete" tier subscription. In addition to the core ingest and retention dimensions, there is a charge to execute synthetic monitors on our testing infrastructure. Browser (journey) based tests are charged per-test-run, and ping (lightweight) tests have an all-you-can-use model per location used.
+[Synthetic monitoring](/solutions/observability/synthetics/index.md) is an optional add-on to Observability Serverless projects that allows you to periodically check the status of your services and applications as a part of the "Observability Complete" feature tier. In addition to the core ingest and retention dimensions, there is a charge to execute synthetic monitors on our testing infrastructure. Browser (journey) based tests are charged per-test-run, and ping (lightweight) tests have an all-you-can-use model per location used.
 
 ## Elastic Managed LLM
 
-The default [Elastic Managed LLM](kibana://reference/connectors-kibana/elastic-managed-llm.md) enables you to leverage AI-powered search as a service without deploying a model in your serverless project. It's configured by default to use with the Security AI Assistant, Attack Discovery, and other applicable AI features as a part of your "Complete" tier subscription. Using the default LLM will use tokens and incur related token-based add-on billing for your serverless project.
+The default [Elastic Managed LLM](kibana://reference/connectors-kibana/elastic-managed-llm.md) enables you to leverage AI-powered search as a service without deploying a model in your serverless project. It's configured by default to use with the Security AI Assistant, Attack Discovery, and other applicable AI features as a part of the "Observability Complete" feature tier. Using the default LLM will use tokens and incur related token-based add-on billing for your serverless project.

deploy-manage/cloud-organization/billing/manage-subscription.md

@@ -67,11 +67,14 @@ You can [change your subscription level](/deploy-manage/cloud-organization/billi
 :   Edit your deployment index management policies to disable the frozen tier that is using [searchable snapshots](/deploy-manage/tools/snapshot-and-restore/searchable-snapshots.md), or set up your cold tier to not mount indices from a searchable snapshot.
 
 `JDBC/ODBC clients`
-:   Make sure that there are no applications that use the SQL [JDBC](/explore-analyze/query-filter/languages/sql-jdbc.md) or [ODBC](/explore-analyze/query-filter/languages/sql-odbc.md) clients.
+:   Make sure that there are no applications that use the SQL [JDBC](elasticsearch://reference/query-languages/sql/sql-jdbc.md) or [ODBC](elasticsearch://reference/query-languages/sql/sql-odbc.md) clients.
 
 `Field-level or document-level security`
 :   Remove any user role configurations based on field or document access [through the API](/deploy-manage/users-roles/cluster-or-deployment-auth/controlling-access-at-document-field-level.md) or the {{kib}} [Roles](/deploy-manage/users-roles/cluster-or-deployment-auth/defining-roles.md) page.
 
+`ES|QL cross-cluster search`
+:   Discontinue all [ES|QL CCS queries](elasticsearch://reference/query-languages/esql/esql-cross-clusters.md) or upgrade license tier to Enterprise.
+
 ::::{note}
 After you have made your changes to the deployment, it can take up to one hour to clear the notification banner.
 ::::

deploy-manage/cloud-organization/billing/security-billing-dimensions.md

@@ -73,4 +73,4 @@ For more details about {{elastic-sec}} serverless project rates and billable ass
 
 ## Elastic Managed LLM
 
-The default [Elastic Managed LLM](kibana://reference/connectors-kibana/elastic-managed-llm.md) enables you to leverage AI-powered search as a service without deploying a model in your serverless project. It's configured by default to use with the Security AI Assistant, Attack Discovery, and other applicable AI features as a part of your "Complete" tier subscription. Using the default LLM will use tokens and incur related token-based add-on billing for your serverless project.
+The default [Elastic Managed LLM](kibana://reference/connectors-kibana/elastic-managed-llm.md) enables you to leverage AI-powered search as a service without deploying a model in your serverless project. It's configured by default to use with the Security AI Assistant, Attack Discovery, and other applicable AI features as a part of the "Security Analytics Complete" feature tier. Using the default LLM will use tokens and incur related token-based add-on billing for your serverless project.

deploy-manage/deploy/cloud-on-k8s/elastic-stack-configuration-policies.md

@@ -11,14 +11,17 @@ products:
 # {{stack}} configuration policies [k8s-stack-config-policy]
 
 ::::{warning}
-We have identified an issue with {{es}} 8.15.1 and 8.15.2 that prevents security role mappings configured via Stack configuration policies to work correctly. Avoid these versions and upgrade to 8.16.0 to remedy this issue if you are affected.
+We have identified an issue with {{es}} 8.15.1 and 8.15.2 that prevents security role mappings configured via Stack configuration policies to work correctly. Avoid these versions and upgrade to 8.16+ to remedy this issue if you are affected.
 ::::
 
 
 ::::{note}
 This requires a valid Enterprise license or Enterprise trial license. Check [the license documentation](../../license/manage-your-license-in-eck.md) for more details about managing licenses.
 ::::
 
+::::{note}
+Component templates created in configuration policies cannot currently be referenced from index templates created through the {{es}} API or {{kib}} UI.
+::::
 
 Starting from ECK `2.6.1` and {{es}} `8.6.1`, {{stack}} configuration policies allow you to configure the following settings for {{es}}:
 

deploy-manage/deploy/cloud-on-k8s/propagate-labels-annotations.md

@@ -6,13 +6,13 @@ products:
   - id: cloud-kubernetes
 ---
 
-# Propagate Labels and Annotations [k8s-propagate-labels-annotations]
+# Propagate labels and annotations [k8s-propagate-labels-annotations]
 
 Starting with version `3.1.0`, {{eck}} supports propagating labels and annotations from the parent resource to the child resources it creates. This can be used on all custom resources managed by ECK, such as {{eck_resources_list}}.
 
 The example below demonstrates how to use this feature on a {{es}} cluster, however, as mentioned above, this can be also applied to any custom resource managed by {{eck}}.
 
-```yaml
+```yaml subs=true
 apiVersion: elasticsearch.k8s.elastic.co/v1
 kind: Elasticsearch
 metadata:
@@ -29,7 +29,7 @@ metadata:
     my-label2: "my-label2-value"
   name: elasticsearch-sample
 spec:
-  version: 9.1.0
+  version: {{version.stack}}
   nodeSets:
     - name: default
       config:
@@ -60,7 +60,7 @@ service/elasticsearch-sample-es-transport       ClusterIP   None             <no
 
 It is possible to use `*` as a wildcard to propagate all labels and annotations from the parent resource to the child resources. For example:
 
-```yaml
+```yaml subs=true
 apiVersion: elasticsearch.k8s.elastic.co/v1
 kind: Elasticsearch
 metadata:
@@ -70,7 +70,7 @@ metadata:
     eck.k8s.alpha.elastic.co/propagate-labels: "*"
   name: elasticsearch-sample
 spec:
-  version: 9.1.0
+  version: {{version.stack}}
   nodeSets:
     - name: default
       config:

deploy-manage/deploy/elastic-cloud/differences-from-other-elasticsearch-offerings.md

@@ -105,7 +105,7 @@ This table compares Elasticsearch capabilities between {{ech}} deployments and S
 
 ### Observability
 
-This table compares Observability capabilities between {{ech}} deployments and Observability Complete Serverless projects. For more information on Observability Logs Essentials Serverless projects, refer to [Observability subscription tiers](../../../solutions/observability/observability-serverless-feature-tiers.md).
+This table compares Observability capabilities between {{ech}} deployments and Observability Complete Serverless projects. For more information on Observability Logs Essentials Serverless projects, refer to [Observability feature tiers](../../../solutions/observability/observability-serverless-feature-tiers.md).
 
 | **Feature** | {{ech}} | Serverless Observability Complete projects | Serverless notes |
 |---------|----------------------|-----------------------------------|------------------|

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

@@ -80,8 +80,8 @@ If you already have an {{ecloud}} account:
 :sync: new
 
 If you don’t have an existing {{ecloud}} account: 
-1. Sign up for an account. 
-2. Follow the prompts on your screen to create an organization.
+1. Go to the [Cloud Connected Services sign up](https://cloud.elastic.co/registration?onboarding_service_type=ccm) page. 
+2. Follow the prompts on your screen to sign up for {{ecloud}} and create an organization.
 3. Go through the installation wizard as detailed in the following sections.
 ::::
 

deploy-manage/remote-clusters.md

@@ -34,7 +34,52 @@ Depending on the environment the local and remote clusters are deployed on and t
 
 Find the instructions with details on the supported security models and available connection modes for your specific scenario:
 
-- [Remote clusters with {{ech}}](remote-clusters/ec-enable-ccs.md)
-- [Remote clusters with {{ece}}](remote-clusters/ece-enable-ccs.md)
-- [Remote clusters with {{eck}}](remote-clusters/eck-remote-clusters.md)
-- [Remote clusters with self-managed installations](remote-clusters/remote-clusters-self-managed.md)
+- [Remote clusters on {{ech}}](remote-clusters/ec-enable-ccs.md)
+- [Remote clusters on {{ece}}](remote-clusters/ece-enable-ccs.md)
+- [Remote clusters on {{eck}}](remote-clusters/eck-remote-clusters.md)
+- [Remote clusters on self-managed installations](remote-clusters/remote-clusters-self-managed.md)
+
+## Remote clusters and network security [network-security]
+```{applies_to}
+deployment:
+  ece: ga
+  ess: ga
+```
+
+In {{ech}} (ECH) and {{ece}} (ECE), the remote clusters functionality interacts with [network security](/deploy-manage/security/network-security.md) traffic filtering rules in different ways, depending on the [security model](/deploy-manage/remote-clusters/remote-clusters-self-managed.md#remote-clusters-security-models) you use.
+
+* **TLS certificate–based authentication (deprecated):**
+  For remote clusters configured using the TLS certificate–based security model, network security policies or rule sets have no effect on remote clusters functionality. Connections established with this method (mTLS) are already considered secure and are always accepted, regardless of any filtering policies or rule sets applied on the local or remote deployment to restrict other traffic.
+
+* **API key–based authentication (recommended):**
+  When remote clusters use the API key–based authentication model, network security policies or rule sets on the **destination (remote) deployment** do affect remote cluster functionality if enabled. In this case, you can use traffic filters to explicitly control which deployments are allowed to connect to the remote cluster service endpoint.
+
+  ::::{note}
+  Because of [how network security works](/deploy-manage/security/network-security.md#how-network-security-works):
+    * If network security is disabled, all traffic is allowed by default, and remote clusters work without requiring any specific filtering policy.
+    * If network security is enabled on the remote cluster, apply a [remote cluster filter](/deploy-manage/security/remote-cluster-filtering.md#create-remote-cluster-filter) to allow incoming connections from the local clusters. Without this filter, the connections are blocked.
+  ::::
+
+This section explains how remote clusters interact with network security when using API key–based authentication, and describes the supported use cases.
+
+### Filter types and supported use cases for remote cluster traffic [use-cases-network-security]
+
+With API key–based authentication, remote clusters require the local cluster (A) to trust the transport SSL certificate presented by the remote cluster server (B). When network security is enabled on the destination cluster (B), it’s also necessary to explicitly allow the incoming traffic from cluster A. This can be achieved using different types of traffic filters:
+
+* [Remote cluster filters](/deploy-manage/security/remote-cluster-filtering.md), available exclusively in ECH and ECE. They allow filtering by organization ID or {{es}} cluster ID and are the recommended option, as they combine mTLS with API key authentication for stronger security.
+
+* [IP filters](/deploy-manage/security/ip-filtering.md), which allow traffic based on IP addresses or CIDR ranges.
+
+The applicable filter type for the remote cluster depends on the local and remote deployment types:
+
+| Remote cluster → <br>Local cluster ↓  | Elastic Cloud Hosted | Elastic Cloud Enterprise | Self-managed / Elastic Cloud on Kubernetes |
+|-------------------------|----------------------|--------------------------|--------------------------------------------|
+| **Elastic Cloud Hosted** | [Remote cluster filter](/deploy-manage/security/remote-cluster-filtering.md) | [IP filter](/deploy-manage/security/ip-filtering.md) | [IP filter](/deploy-manage/security/ip-filtering.md) or [Kubernetes network policy](/deploy-manage/security/k8s-network-policies.md) |
+| **Elastic Cloud Enterprise** | [IP filter](/deploy-manage/security/ip-filtering.md) | [Remote cluster filter](/deploy-manage/security/remote-cluster-filtering.md) / [IP filter](/deploy-manage/security/ip-filtering.md) (\*) | [IP filter](/deploy-manage/security/ip-filtering.md) or [Kubernetes network policy](/deploy-manage/security/k8s-network-policies.md) |
+| **Self-managed / Elastic Cloud on Kubernetes** | [IP filter](/deploy-manage/security/ip-filtering.md) | [IP filter](/deploy-manage/security/ip-filtering.md) | [IP filter](/deploy-manage/security/ip-filtering.md) or [Kubernetes network policy](/deploy-manage/security/k8s-network-policies.md) |
+
+(*) For ECE, remote cluster filters apply when both clusters are in the **same environment**. Use IP filters when the clusters belong to **different environments**.
+
+::::{note}
+When using self-managed security mechanisms (such as firewalls), keep in mind that remote clusters with API key–based authentication use port `9443` by default. Specify this port if a destination port is required.
+::::

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

@@ -19,6 +19,10 @@ You can configure an {{ech}} deployment to either connect to remote clusters or
 * A deployment in an {{eck}} installation
 * A self-managed installation.
 
+::::{note}
+Refer to [Remote clusters and network security](/deploy-manage/remote-clusters.md#network-security) for details on how remote clusters interact with network security policies and the implications for your deployments.
+::::
+
 
 ## Prerequisites [ec-ccs-ccr-prerequisites]
 
@@ -51,20 +55,6 @@ The steps, information, and authentication method required to configure CCS and
     * [From a self-managed cluster](remote-clusters-self-managed.md)
     * [From an ECK environment](ec-enable-ccs-for-eck.md)
 
-
 ## Remote clusters and network security [ec-ccs-ccr-network-security]
 
-::::{note}
-[Network security](../security/network-security.md) isn’t supported for cross-cluster operations initiated from an {{ece}} environment to a remote {{ech}} deployment.
-::::
-
-You can use [network security policies](../security/network-security.md) to restrict access to deployments used as a local or remote cluster, without impacting cross-cluster search or cross-cluster replication.
-
-Network security for remote clusters supports the following methods:
-
-* [Filtering by IP addresses and Classless Inter-Domain Routing (CIDR) masks](../security/ip-filtering.md)
-* Filtering by Organization or {{es}} cluster ID with a **Remote cluster** private connection policy. You can configure this type of policy from the **Access and security** > **Network security** page of your organization or using the [{{ecloud}} RESTful API](https://www.elastic.co/docs/api/doc/cloud) and apply it from each deployment’s **Security** page.
-
-::::{note}
-When setting up network security policies for a remote connection to an {{ece}} environment, you also need to upload the region’s TLS certificate of the local cluster to the {{ece}} environment’s proxy. You can find that region’s TLS certificate in the **Security** page of any deployment of the environment initiating the remote connection. This is regardless of whether you are using API key or TLS Certificates (deprecated) to authenticate remote connections.
-::::
+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).