Merge branch 'main' into update-synthetics-docker

Author: mdbirnstiehl

deploy-manage/security/fips-ingest.md

@@ -85,14 +85,23 @@ When you use {{agent}} and {{fleet-server}}, these limitations apply:
 * Running {{agent}} in [OpenTelemetry mode](https://github.com/elastic/elastic-agent/blob/main/internal/pkg/otel/README.md) is not yet supported. This includes all receivers, such as Filebeat Receiver, Metricbeat Receiver, [Prometheus Receiver](https://www.elastic.co/docs/reference/integrations/prometheus).
 * Some Elastic Integrations are not FIPS compatible, as they depend on functionality that is not yet supported for FIPS configuration. In general, when using {{agent}} and {{fleet-server}}, the same restrictions listed previously for {{metricbeat}} and {{filebeat}} modules, inputs, and processors apply.
 
-  These Elastic Integrations have components that are **not** FIPS compatible, and **cannot** be used in FIPS environments, even if combined with other ingest tools that offer FIPS mode. 
-
-  - [Azure Logs Integration (v2 preview)](integration-docs://reference/azure/events.md)
-  - [Azure Event Hub Input](integration-docs://reference/azure/eventhub.md)
-  - [SQL Input](integration-docs://reference/sql.md) 
-  - [PostgreSQL Integration](integration-docs://reference/postgresql.md)
-  - [MongoDB Integration](integration-docs://reference/mongodb.md)
-  - [MySQL Integration](integration-docs://reference/mysql.md)
-  - [Microsoft SQL Server Integration](integration-docs://reference/microsoft_sqlserver.md)
-  - [Oracle Integration](integration-docs://reference/oracle.md)
-
+### Elastic Integrations that are not FIPS compatible [ingest-limitations-integrations]
+
+These Elastic Integrations have components that are **not** FIPS compatible, and **cannot** be used in FIPS environments, even if combined with other ingest tools that offer FIPS mode. 
+
+- [Azure Logs Integration (v2 preview)](integration-docs://reference/azure/events.md)
+- [Azure Event Hub Input](integration-docs://reference/azure/eventhub.md)
+- [Azure AI Foundry Integration](integration-docs://reference/azure_ai_foundry.md)
+- [Azure App Service Integration](integration-docs://reference/azure_app_service.md)
+- [Azure Application Insights Integration](integration-docs://reference/azure_application_insights.md)
+- [Azure Billing Metrics Integration](integration-docs://reference/azure_billing.md)
+- [Azure Functions Integration](integration-docs://reference/azure_functions.md)
+- [Custom Azure Logs Integration](integration-docs://reference/azure_logs.md)
+- [Azure Resource Metrics Integration](integration-docs://reference/azure_metrics.md)
+- [Azure OpenAI Integration](integration-docs://reference/azure_openai.md)
+- [SQL Input](integration-docs://reference/sql.md) 
+- [PostgreSQL Integration](integration-docs://reference/postgresql.md)
+- [MongoDB Integration](integration-docs://reference/mongodb.md)
+- [MySQL Integration](integration-docs://reference/mysql.md)
+- [Microsoft SQL Server Integration](integration-docs://reference/microsoft_sqlserver.md)
+- [Oracle Integration](integration-docs://reference/oracle.md)

deploy-manage/upgrade/orchestrator/upgrade-cloud-on-k8s.md

@@ -101,8 +101,11 @@ This will update the ECK installation to the latest binary and update the CRDs a
 Upgrading the operator results in a one-time update to existing managed resources in the cluster. This potentially triggers a rolling restart of pods by Kubernetes to apply those changes. The following list contains the ECK operator versions that would cause a rolling restart after they have been installed.
 
 ```
-1.6, 1.9, 2.0, 2.1, 2.2, 2.4, 2.5, 2.6, 2.7, 2.8, 2.14
+1.6, 1.9, 2.0, 2.1, 2.2, 2.4, 2.5, 2.6, 2.7, 2.8, 2.14, 3.1 <1>
 ```
+
+1. The restart when upgrading to version 3.1 happens only for applications using [stack monitoring](/deploy-manage/monitor/stack-monitoring/eck-stack-monitoring.md).
+
 ::::{note}
 Stepping over one of these versions, for example, upgrading ECK from 2.6 to 2.9, still triggers a rolling restart.
 ::::

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

@@ -336,7 +336,7 @@ Adapt and change the suggested manifests and deployment strategy to your needs,
           automountServiceAccountToken: false
           containers:
           - name: elastic-agent
-            image: docker.elastic.co/beats/elastic-agent:{{version.stack}}
+            image: docker.elastic.co/elastic-agent:{{version.stack}}
             env:
               - name: FLEET_SERVER_ENABLE
                 value: "true"
@@ -422,7 +422,7 @@ Adapt and change the suggested manifests and deployment strategy to your needs,
           automountServiceAccountToken: false
           containers:
           - name: elastic-agent
-            image: docker.elastic.co/beats/elastic-agent:{{version.stack}}
+            image: docker.elastic.co/elastic-agent:{{version.stack}}
             env:
               - name: FLEET_SERVER_ENABLE
                 value: "true"

solutions/security/get-started/spaces-defend-faq.md

@@ -19,13 +19,7 @@ This page introduces {{elastic-sec}} space awareness and answers frequently aske
 :::: 
 
 ::::{note}
-{{elastic-sec}}'s space awareness works in conjunction with {{fleet}}'s space awareness. Space awareness is enabled by default in both applications, but for {{stack}} deployments that existed prior to version 9.1, {{fleet}} requires you to manually “opt-in” so that existing data can become space aware:
-
-1. Navigate to **Fleet** using the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md).
-2. Go to the **Settings** tab.
-3. Scroll to **Advanced settings**.
-4. Under **Migrate to space-aware agent policies**, click **Start migration**.
-5. Confirm the migration.
+{{elastic-sec}}'s space awareness works in conjunction with {{fleet}}'s space awareness. Space awareness is enabled by default in both applications, but for {{stack}} deployments that existed prior to version 9.1, {{fleet}} requires you to manually “opt-in” so that existing data can become space aware. For instructions, refer to [Enable space awareness in {{fleet}}](/deploy-manage/manage-spaces-fleet.md#spaces-fleet-enable).
 
 This is a one-time migration that copies your existing {{fleet}} data into a new, space-aware model. Previous data will be preserved in snapshots in case rollback is needed.
 ::::