Merge branch 'main' into issue-1235-highlighted-fields-serv

Author: nastasha-solomon

.github/CODEOWNERS

@@ -47,6 +47,7 @@
 /solutions/observability/get-started/       @elastic/ski-docs
 /solutions/search/                          @elastic/developer-docs
 /solutions/security/                        @elastic/experience-docs
+/solutions/security/get-started/            @elastic/ingest-docs @elastic/experience-docs
 /solutions/security/cloud/                  @elastic/ingest-docs
 
 /troubleshoot/                              @elastic/docs

cloud-account/update-your-email-address.md

@@ -13,6 +13,8 @@ products:
 
 Each {{ecloud}} account has a primary email associated with it. By default, the primary email address is used to sign up for {{ecloud}} and to log in. If needed, you can change this primary email address.
 
+Your email address is used to uniquely identify you. It can’t be used for more than one {{ecloud}} account, whether that account is a trial account, a standard {{ecloud}} account, or a subscription account through a marketplace. An {{ecloud}} account can belong to only one organization at a time.
+ 
 ## Change your email address (native sign-in)
 
 If you log in using a standard email and password, follow these steps to update your email address:
@@ -34,3 +36,15 @@ If you log in using Google or Microsoft Sign-In, follow these steps to update yo
 ## Changing your email address with an Azure Marketplace account
 
 If your organization is associated with [Azure Marketplace](../deploy-manage/deploy/elastic-cloud/azure-native-isv-service.md), you can’t change your primary email address using the above methods. Instead, [invite another user](../deploy-manage/users-roles/cloud-organization/manage-users.md) with the desired email address to join your organization.
+
+## Sign up using an existing email address [sign-up-existing]
+
+In some situations, you might want to create a new {{ecloud}} account using an email address that is already associated with an existing account. To sign up to {{ecloud}} using an email address associated with another {{ecloud}} account, you must remove the email address from your previous account and replace it with a new address.
+
+1. Use your current email address (for example, `[email protected]`) to log in to the [{{ecloud}} Console](https://cloud.elastic.co?page=docs&placement=docs-body).
+2. Follow the steps from one of the procedures on this page to update that email address to another email address, such as `[email protected]`.
+
+You can now use the email address from step 1 to do the following:
+
+* [Sign up for a new account](/deploy-manage/deploy/elastic-cloud/create-an-organization.md).
+* [Join an existing organization](/cloud-account/join-or-leave-an-organization.md).

deploy-manage/deploy/cloud-enterprise/access-kibana.md

@@ -27,7 +27,9 @@ To access {{kib}}:
 3. Under **Applications**, select the {{kib}} **Open** link and wait for {{kib}} to open.
 
     ::::{note} 
-    Both ports 443 and 9243 can be used to access {{kib}}. SSO only works with 9243 on older deployments, where you will see an option in the Cloud UI to migrate the default to port 443. In addition, any version upgrade will automatically migrate the default port to 443.
+    The URL provided to access {{kib}} is based on the [endpoint URL](/deploy-manage/deploy/cloud-enterprise/change-endpoint-urls.md) configured in the ECE **Settings** UI. This URL should resolve to your [external load balancer](/deploy-manage/deploy/cloud-enterprise/ece-load-balancers.md), which forwards the traffic to ECE proxies on port `9243`.
+
+    If your load balancer is configured to accept traffic on both ports `9243` and `443`, you can use either port when connecting to {{kib}}. However, [built-in SSO](/deploy-manage/users-roles/cloud-enterprise-orchestrator/configure-sso-for-deployments.md) will only work with the URL configured in ECE **Settings** UI.
     ::::
 
 4. Log into {{kib}}. Single sign-on (SSO) is enabled between your {{ece}} account and the {{kib}} instance. If you’re logged in already, then {{kib}} opens without requiring you to log in again. However, if your token has expired, choose from one of these methods to log in:

deploy-manage/deploy/elastic-cloud/create-an-organization.md

@@ -37,7 +37,8 @@ To sign up:
 2. Choose one of the available sign up methods. You can register with your email address and a password, use a Google or Microsoft account, or [subscribe from a Marketplace](../../../deploy-manage/deploy/elastic-cloud/subscribe-from-marketplace.md).
 
 :::{note}
-You can only belong to one {{ecloud}} organization at a time. If you want to create or join another organization, you must leave the previous one or use a different email address.
+* You can only belong to one {{ecloud}} organization at a time. If you want to create or join another organization, you must [leave the previous one](/cloud-account/join-or-leave-an-organization.md#ec-leave-organization) or use a different email address.
+* An email address can’t be used for more than one {{ecloud}} account. To make the email address available for a new account, you can [remove it from your existing account](/cloud-account/update-your-email-address.md#sign-up-existing).
 :::
 
 When your first sign up, you create an organization and start with a trial license.

deploy-manage/monitor/stack-monitoring/eck-stack-monitoring.md

@@ -38,7 +38,7 @@ However, for maximum efficiency and minimizing resource consumption, or advanced
 
 To enable stack monitoring, reference the monitoring {{es}} cluster in the `spec.monitoring` section of their specification. 
 
-The monitoring cluster must be managed by ECK in the same Kubernetes cluster as the monitored one. To learn how to connect an external monitoring cluster, refer to [Connect ot an external monitoring {{es}} cluster](#k8s_connect_to_an_external_monitoring_elasticsearch_cluster).
+The monitoring cluster must be managed by ECK in the same Kubernetes cluster as the monitored one. To learn how to connect an external monitoring cluster, refer to [Connect to an external monitoring {{es}} cluster](#k8s_connect_to_an_external_monitoring_elasticsearch_cluster).
 
 The following example shows how {{stack}} components can be configured to send their monitoring data to a separate {{es}} cluster in the same Kubernetes cluster. 
 

deploy-manage/tools/snapshot-and-restore.md

@@ -143,22 +143,26 @@ You can’t restore a snapshot to an earlier version of {{es}}. For example, you
 
 Any index you restore from a snapshot must also be compatible with the current cluster’s version. If you try to restore an index created in an incompatible version, the restore attempt will fail.
 
-| Index creation version | 6.8 | 7.0–7.1 | 7.2–7.17 | 8.0–8.2 | 8.3–8.17 |
-|------------------------|-----|---------|---------|---------|---------|
-| 5.0–5.6               | ✅   | ❌       | ❌       | ❌       | ✅ [^1^](#footnote-1)   |
-| 6.0–6.7               | ✅   | ✅       | ✅       | ❌       | ✅ [^1^](#footnote-1)   |
-| 6.8                   | ✅   | ❌       | ✅       | ❌       | ✅ [^1^](#footnote-1)   |
-| 7.0–7.1               | ❌   | ✅       | ✅       | ✅       | ✅       |
-| 7.2–7.17              | ❌   | ❌       | ✅       | ✅       | ✅       |
-| 8.0–8.17              | ❌   | ❌       | ❌       | ✅       | ✅       |
+| Index creation version | 6.8 | 7.0–7.1 | 7.2–7.17 | 8.0–8.2 | 8.3–8.18 | 9.0 |
+|------------------------|-----|---------|---------|---------|---------|-----|
+| 5.0–5.6               | ✅   | ❌       | ❌       | ❌       | ✅ ^1^   | ✅ ^1^ |
+| 6.0–6.7               | ✅   | ✅       | ✅       | ❌       | ✅ ^1^   | ✅ ^1^ |
+| 6.8                   | ✅   | ❌       | ✅       | ❌       | ✅ ^1^   | ✅ ^1^ |
+| 7.0–7.1               | ❌   | ✅       | ✅       | ✅       | ✅       | ✅ ^1, 2^ |
+| 7.2–7.17              | ❌   | ❌       | ✅       | ✅       | ✅       | ✅ ^1, 2^ |
+| 8.0–8.18              | ❌   | ❌       | ❌       | ✅       | ✅       | ✅ |
 
 ^1^ $$$footnote-1$$$ Supported with [archive indices](/deploy-manage/upgrade/deployment-or-cluster/reading-indices-from-older-elasticsearch-versions.md).
 
-You can’t restore an index to an earlier version of {{es}}. For example, you can’t restore an index created in 7.6.0 to a cluster running 7.5.0.
+^2^ $$$footnote-2$$$ Supported with [searchable snapshots](/deploy-manage/tools/snapshot-and-restore/searchable-snapshots.md).
 
-A compatible snapshot can contain indices created in an older incompatible version. For example, a snapshot of a 7.17 cluster can contain an index created in 6.8. Restoring the 6.8 index to an 8.17 cluster fails unless you can use the [archive functionality](/deploy-manage/upgrade/deployment-or-cluster/reading-indices-from-older-elasticsearch-versions.md). Keep this in mind if you take a snapshot before upgrading a cluster.
+You can’t restore an index to an earlier version of {{es}}. For example, you can’t restore an index created in 8.18.0 to a cluster running 8.15.0.
 
-As a workaround, you can first restore the index to another cluster running the latest version of {{es}} that’s compatible with both the index and your current cluster. You can then use [reindex-from-remote](https://www.elastic.co/guide/en/elasticsearch/reference/8.18/docs-reindex.html#reindex-from-remote) to rebuild the index on your current cluster. Reindex from remote is only possible if the index’s [`_source`](elasticsearch://reference/elasticsearch/mapping-reference/mapping-source-field.md) is enabled.
+#### Restoring incompatible indices
+
+A compatible snapshot can contain indices created in an older incompatible version. To restore these incompatible indices, you must take additional steps. For example, a snapshot of a 7.17 cluster might contain an index created in 6.8. Restoring the 6.8 index to an 8.18 cluster fails unless you use the [archive functionality](/deploy-manage/upgrade/deployment-or-cluster/reading-indices-from-older-elasticsearch-versions.md). To restore a 7.17 index to a 9.0 cluster, you can use the [archive functionality](/deploy-manage/upgrade/deployment-or-cluster/reading-indices-from-older-elasticsearch-versions.md) or [searchable snapshots](/deploy-manage/tools/snapshot-and-restore/searchable-snapshots.md). Keep this in mind if you take a snapshot before upgrading a cluster.
+
+To ensure index compatibility, you can first restore the index to another cluster running the latest version of {{es}} that’s compatible with both the index and your current cluster. You can then use [reindex-from-remote](https://www.elastic.co/guide/en/elasticsearch/reference/8.18/docs-reindex.html#reindex-from-remote) to rebuild the index on your current cluster. Reindex from remote is only possible if the index’s [`_source`](elasticsearch://reference/elasticsearch/mapping-reference/mapping-source-field.md) is enabled.
 
 Reindexing from remote can take significantly longer than restoring a snapshot. Before you start, test the reindex from remote process with a subset of the data to estimate your time requirements.
 

deploy-manage/tools/snapshot-and-restore/elastic-cloud-hosted.md

@@ -124,7 +124,7 @@ Note that most of the cleanup operations executed by this endpoint are automatic
 
 You may wish to make an independent backup of your repository, for instance so that you have an archive copy of its contents that you can use to recreate the repository in its current state at a later date.
 
-You must ensure that {{es}} does not write to the repository while you are taking the backup of its contents. If {{es}} writes any data to the repository during the backup then the contents of the backup may not be consistent and it may not be possible to recover any data from it in future. Prevent writes to the repository by unregistering the repository from the cluster which has write access to it.
+You must ensure that {{es}} does not write to the repository while you are taking the backup of its contents. If {{es}} writes any data to the repository during the backup then the contents of the backup may not be consistent and it may not be possible to recover any data from it in future. Prevent writes to the repository by unregistering the repository from the cluster which has write access to it, or by registering it with `readonly: true`.
 
 Alternatively, if your repository supports it, you may take an atomic snapshot of the underlying filesystem and then take a backup of this filesystem snapshot. It is very important that the filesystem snapshot is taken atomically.
 

deploy-manage/tools/snapshot-and-restore/self-managed.md

@@ -128,7 +128,7 @@ Note that most of the cleanup operations executed by this endpoint are automatic
 
 You may wish to make an independent backup of your repository, for instance so that you have an archive copy of its contents that you can use to recreate the repository in its current state at a later date.
 
-You must ensure that {{es}} does not write to the repository while you are taking the backup of its contents. If {{es}} writes any data to the repository during the backup then the contents of the backup may not be consistent and it may not be possible to recover any data from it in future. Prevent writes to the repository by unregistering the repository from the cluster which has write access to it.
+You must ensure that {{es}} does not write to the repository while you are taking the backup of its contents. If {{es}} writes any data to the repository during the backup then the contents of the backup may not be consistent and it may not be possible to recover any data from it in future. Prevent writes to the repository by unregistering the repository from the cluster which has write access to it, or by registering it with `readonly: true`.
 
 Alternatively, if your repository supports it, you may take an atomic snapshot of the underlying filesystem and then take a backup of this filesystem snapshot. It is very important that the filesystem snapshot is taken atomically.
 

deploy-manage/users-roles.md

@@ -86,7 +86,7 @@ You can't manage users and roles for {{eck}} clusters at the orchestrator level.
 serverless: all
 ```
 
-As an extension of the [predefined instance access roles](/deploy-manage/users-roles/cloud-organization/user-roles.md#ec_instance_access_roles) offered for {{serverless-short}} projects, you can create custom roles at the project level to provide more granular control, and provide users with only the access they need within specific projects.
+As an extension of the [predefined cloud resource access roles](/deploy-manage/users-roles/cloud-organization/user-roles.md#ec_instance_access_roles) offered for {{serverless-short}} projects, you can create custom roles at the project level to provide more granular control, and provide users with only the access they need within specific projects.
 
 [Learn more about custom roles for {{serverless-full}} projects](/deploy-manage/users-roles/serverless-custom-roles.md).
 

deploy-manage/users-roles/_snippets/org-vs-deploy-sso.md

@@ -6,7 +6,7 @@ The option that you choose depends on your requirements:
 | --- | --- | --- |
 | **Management experience** | Manage authentication and role mapping centrally for all deployments in the organization | Configure SSO for each deployment individually |
 | **Authentication protocols** | SAML only | Multiple protocols, including LDAP, OIDC, and SAML |
-| **Role mapping** | [Organization-level roles and instance access roles](../../../deploy-manage/users-roles/cloud-organization/user-roles.md), Serverless project [custom roles](/deploy-manage/users-roles/serverless-custom-roles.md) | [Built-in](../../../deploy-manage/users-roles/cluster-or-deployment-auth/built-in-roles.md) and [custom](../../../deploy-manage/users-roles/cluster-or-deployment-auth/defining-roles.md) stack-level roles |
+| **Role mapping** | [Organization-level roles and cloud resource access roles](../../../deploy-manage/users-roles/cloud-organization/user-roles.md), Serverless project [custom roles](/deploy-manage/users-roles/serverless-custom-roles.md) | [Built-in](../../../deploy-manage/users-roles/cluster-or-deployment-auth/built-in-roles.md) and [custom](../../../deploy-manage/users-roles/cluster-or-deployment-auth/defining-roles.md) stack-level roles |
 | **User experience** | Users interact with Cloud | Users interact with the deployment directly |
 
 If you want to avoid exposing users to the {{ecloud}} Console, or have users who only interact with some deployments, then you might prefer users to interact with your deployment directly.