Merge branch 'main' into internal-452-known-issue

Author: benironside

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

@@ -75,6 +75,13 @@ ECK is compatible with the following Kubernetes distributions and related techno
 
 ::::{tab-set}
 
+:::{tab-item} ECK 3.2
+* Kubernetes 1.30-1.34
+* OpenShift 4.15-4.19
+* Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), and Amazon Elastic Kubernetes Service (EKS)
+* Helm: {{eck_helm_minimum_version}}+
+:::
+
 :::{tab-item} ECK 3.1
 * Kubernetes 1.29-1.33
 * OpenShift 4.15-4.19

deploy-manage/deploy/cloud-on-k8s/configure-eck.md

@@ -97,6 +97,7 @@ data:
     enable-leader-election: true
     elasticsearch-observation-interval: 10s
     ubi-only: false
+    password-length: 24
 ```
 
 Alternatively, you can edit the `elastic-operator` StatefulSet and add flags to the `args` section of the operator container — which will trigger an automatic restart of the operator pod by the StatefulSet controller.

deploy-manage/deploy/cloud-on-k8s/pod-disruption-budget.md

@@ -12,9 +12,47 @@ products:
 
 A [Pod Disruption Budget](https://kubernetes.io/docs/tasks/run-application/configure-pdb/) (PDB) allows you to limit the disruption to your application when its pods need to be rescheduled for some reason such as upgrades or routine maintenance work on the Kubernetes nodes.
 
-ECK manages a default PDB per {{es}} resource. It allows one {{es}} Pod to be taken down, as long as the cluster has a `green` health. Single-node clusters are not considered highly available and can always be disrupted.
+{{eck}} manages either a single default PDB, or multiple PDBs per {{es}} resource depending on the license level of the ECK installation.
 
-In the {{es}} specification, you can change the default behavior as follows:
+:::{note}
+In {{eck}} 3.1 and earlier, all clusters follow the [default PodDisruptionBudget rules](#default-pdb-rules), regardless of license type.
+:::
+
+## Advanced rules (Enterprise license required)
+```{applies_to}
+deployment:
+  eck: ga 3.2
+```
+
+In Elasticsearch clusters managed by ECK and licensed with an Enterprise license, a separate PDB is created for each type of `nodeSet` defined in the manifest. This setup allows Kubernetes upgrade or maintenance operations to be executed more quickly. Each PDB permits one Elasticsearch Pod per `nodeSet` to be disrupted at a time, provided the Elasticsearch cluster maintains the health status described in the following table:
+
+| Role | Cluster health required | Notes |
+|------|------------------------|--------|
+| master | Yellow |  |
+| data | Green | All Data roles are grouped together into a single PDB, except for data_frozen. |
+| data_frozen | Yellow | Since frozen data tier nodes only host partially mounted indices backed by searchable snapshots additional disruptions are allowed. |
+| ingest | Yellow |  |
+| ml | Yellow |  |
+| coordinating | Yellow |  |
+| transform | Yellow |  |
+| remote_cluster_client | Yellow |  |
+
+Single-node clusters are not considered highly available and can always be disrupted regardless of license type.
+
+## Default rules (Basic license) [default-pdb-rules]
+:::{note}
+In {{eck}} 3.1 and earlier, all clusters follow this behavior regardless of license type.
+:::
+
+In {{eck}} clusters that do not have an Enterprise license, one {{es}} Pod can be taken down at a time, as long as the cluster has a health status of `green`. Single-node clusters are not considered highly available and can always be disrupted.
+
+## Overriding the default behavior
+
+In the {{es}} specification, you can change the default behavior in two ways. By fully overriding the PodDisruptionBudget within the {{es}} spec or by disabling the default PodDisruptionBudget and specifying one or more PodDisruptionBudget(s).
+
+### Specify your own PodDisruptionBudget [k8s-specify-own-pdb]
+
+You can fully override the default PodDisruptionBudget by specifying your own PodDisruptionBudget in the {{es}} spec.
 
 ```yaml
 apiVersion: elasticsearch.k8s.elastic.co/v1
@@ -34,14 +72,15 @@ spec:
           elasticsearch.k8s.elastic.co/cluster-name: quickstart
 ```
 
-::::{note} 
+This will cause the ECK operator to only create the PodDisruptionBudget defined in the spec. It will not create any additional PodDisruptionBudgets.
+
+::::{note}
 [`maxUnavailable`](https://kubernetes.io/docs/tasks/run-application/configure-pdb/#arbitrary-controllers-and-selectors) cannot be used with an arbitrary label selector, therefore `minAvailable` is used in this example.
 ::::
 
+### Create a PodDisruptionBudget per nodeSet [k8s-pdb-per-nodeset]
 
-## Pod disruption budget per nodeset [k8s-pdb-per-nodeset]
-
-You can specify a PDB per nodeset or node role.
+You can specify a PDB per `nodeSet` or node role.
 
 ```yaml subs=true
 apiVersion: elasticsearch.k8s.elastic.co/v1
@@ -81,6 +120,3 @@ spec:
 4. Pod disruption budget applies on all master nodes.
 5. Specify pod disruption budget to have 1 hot node available.
 6. Pod disruption budget applies on nodes of the same nodeset.
-
-
-

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

@@ -100,11 +100,9 @@ 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, 3.1 <1>
-```
+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^, 3.2^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).
+^1^ The restart when upgrading to version 3.1 and 3.2 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.

deploy-manage/users-roles/cluster-or-deployment-auth/jwt.md

@@ -121,10 +121,22 @@ Client authentication is enabled by default for the JWT realms. Disabling client
   :   Indicates that {{es}} should use the `RS256` or `HS256` signature algorithms to verify the signature of the JWT from the JWT issuer.
 
   `pkc_jwkset_path`
-  :   The file name or URL to a JSON Web Key Set (JWKS) with the public key material that the JWT Realm uses for verifying token signatures. A value is considered a file name if it does not begin with `https`. The file name is resolved relative to the {{es}} configuration directory. If a URL is provided, then it must begin with `https://` (`http://` is not supported). {{es}} automatically caches the JWK set and will attempt to refresh the JWK set upon signature verification failure, as this might indicate that the JWT Provider has rotated the signing keys.
+  :   The file name or URL to a JSON Web Key Set (JWKS) with the public key material that the JWT Realm uses for verifying token signatures. A value is considered a file name if it does not begin with `https`. The file name is resolved relative to the {{es}} configuration directory. If a URL is provided, then it must begin with `https://` (`http://` is not supported). {{es}} automatically caches the JWK set and will attempt to refresh the JWK set upon signature verification failure, as this might indicate that the JWT Provider has rotated the signing keys. Background JWKS reloading can also be configured with the setting `pkc_jwkset_reload.enabled`. This ensures that rotated keys are automatically discovered and used to verify JWT signatures.
+
+  `pkc_jwkset_reload.enabled` {applies_to}`stack: ga 9.3`
+  :   Indicates whether JWKS background reloading is enabled. Defaults to `false`.
+
+  `pkc_jwkset_reload.file_interval` {applies_to}`stack: ga 9.3`
+  :   Specifies the reload interval for file-based JWKS. Defaults to `5m`.
+
+  `pkc_jwkset_reload.url_interval_min` {applies_to}`stack: ga 9.3`
+  :   Specifies the minimum reload interval for URL-based JWKS. The `Expires` and `Cache-Control` HTTP response headers inform the reload interval. This configuration setting is the lower bound of what is considered, and it is also the default interval in the absence of useful response headers. Defaults to `1h`.
+
+  `pkc_jwkset_reload.url_interval_max` {applies_to}`stack: ga 9.3`
+  :   Specifies the maximum reload interval for URL-based JWKS. This configuration setting is the upper bound of what is considered from header responses (`5d`).
 
   `claims.principal`
-  :   The name of the JWT claim that contains the user’s principal (username).
+  :   The name of the JWT claim that contains the user’s principal. Defaults to `username`.
 
   ::::
 
@@ -434,6 +446,8 @@ PKC JSON Web Token Key Sets (JWKS) can contain public RSA and EC keys. HMAC JWKS
 
 JWT realms load a PKC JWKS and an HMAC JWKS or HMAC UTF-8 JWK at startup. JWT realms can also reload PKC JWKS contents at runtime; a reload is triggered by signature validation failures.
 
+JWT realms can also be configured to reload a PKC JWKS periodically in the background.
+
 ::::{note}
 HMAC JWKS or HMAC UTF-8 JWK reloading is not supported at this time.
 ::::

deploy-manage/users-roles/cluster-or-deployment-auth/managed-credentials-eck.md

@@ -50,7 +50,11 @@ spec:
     count: 1
 ```
 
-## Rotate auto-generated credentials [k8s-rotate-credentials]
+## ECK auto-generated credentials
+
+{{eck}} auto-generates credentials for [the `elastic` user](#k8s-default-elastic-user) and other file-based users. These credentials are stored in Kubernetes Secrets and are labeled with `eck.k8s.elastic.co/credentials=true`.
+
+### Rotate auto-generated credentials [k8s-rotate-credentials]
 
 You can force the auto-generated credentials to be regenerated with new values by deleting the appropriate Secret. For example, to change the password for the `elastic` user from the [quickstart example](/deploy-manage/deploy/cloud-on-k8s/elasticsearch-deployment-quickstart.md), use the following command:
 
@@ -62,7 +66,6 @@ kubectl delete secret quickstart-es-elastic-user
 If you are using the `elastic` user credentials in your own applications, they will fail to connect to {{es}} and {{kib}} after you run this command. It is not recommended to use `elastic` user credentials for production use cases. Always [create your own users with restricted roles](../../../deploy-manage/users-roles/cluster-or-deployment-auth/native.md) to access {{es}}.
 ::::
 
-
 To regenerate all auto-generated credentials in a namespace, run the following command:
 
 ```sh
@@ -73,6 +76,20 @@ kubectl delete secret -l eck.k8s.elastic.co/credentials=true
 This command regenerates auto-generated credentials of **all** {{stack}} applications in the namespace.
 ::::
 
+### Control the length of auto-generated passwords
+
+```{applies_to}
+  eck: ga 3.2
+```
+
+:::{note}
+The ability to control the length of passwords generated by {{eck}} requires an Enterprise license.
+:::
+
+You can control the length of auto-generated passwords in {{eck}} installations by setting either `config.policies.passwords.length` in your Helm chart values or `password-length` in the `elastic-operator` `ConfigMap` when installing with YAML manifests. Refer to the [operator configuration documentation](../../deploy/cloud-on-k8s/configure-eck.md) for details on managing these settings.
+
+Changing these values does not update existing passwords. To rotate current credentials, refer to the [Rotate auto-generated credentials](#k8s-rotate-credentials)
+
 ## Creating custom users
 
 {{eck}} provides functionality to facilitate custom user creation through various authentication realms. You can create users using the native realm, file realm, or external authentication methods.
@@ -99,4 +116,4 @@ For more information, refer to [External authentication](/deploy-manage/users-ro
 
 ECK facilitates file-based role management through Kubernetes secrets containing the roles specification. Alternatively, you can use the Role management API or the Role management UI in {{kib}}.
 
-Refer to [Managing custom roles](/deploy-manage/users-roles/cluster-or-deployment-auth/defining-roles.md#managing-custom-roles) for details and ECK based examples.
+Refer to [Managing custom roles](/deploy-manage/users-roles/cluster-or-deployment-auth/defining-roles.md#managing-custom-roles) for details and ECK based examples.

explore-analyze/report-and-share/automating-report-generation.md

@@ -244,9 +244,12 @@ Save time by setting up a recurring task that automatically generates reports an
 
 A message appears, indicating that the schedule is available on the **Reporting** page. From the **Reporting** page, click on the **Schedules** tab to view details for the newly-created schedule. 
 
-::::{important} 
-Note that you cannot edit or delete a schedule after you create it. To stop the schedule from running, you must disable it. Disabling a schedule permanently stops it from running. To restart it, you must create a new schedule. 
-::::
+### Stop scheduled reports [stop-scheduled-reports]
+
+To stop a scheduled report, you can take the following actions from the **Schedules** tab on the **Reporting** page: 
+
+- **Disable schedule**: {applies_to}`stack: ga 9.1` Disabling a schedule allows you to keep a record of it on the **Reporting** page, but permanently turns the schedule off. To restart the schedule, you must create a new one.
+- **Delete schedule**: {applies_to}`stack: ga 9.3` Deleting a schedule permanently stops it and removes the schedule's record from the **Reporting** page. You can't recover a deleted schedule.
 
 ### Scheduled reports limitations [scheduled-reports-limitations]
 

solutions/observability/incident-management/create-metric-threshold-rule.md

@@ -47,6 +47,13 @@ When you select **Alert me if there’s no data**, the rule is triggered if the
 
 The **Filters** control the scope of the rule. If used, the rule will only evaluate metric data that matches the query in this field. In this example, the rule will only alert on metrics reported from a Cloud region called `us-east`.
 
+::::{note}
+If you've made a rule with the [create rule API](https://www.elastic.co/docs/api/doc/kibana/operation/operation-post-alerting-rule-id) and added Query DSL filters using the `filterQuery` parameter, the filters won't appear in the UI for editing a rule. As a workaround, manually re-add the filters through the UI and save the rule. As you're modifying the rule's filters from the UI, be mindful of the following:
+
+- The **Filter** field only accepts KQL syntax, meaning you may need to manually convert your Query DSL filters to KQL. 
+- After you save the rule, filters you've added to the **Filter** field are converted appropriately and specified in the rule's `filterQuery` parameter.  
+::::
+
 The **Group alerts by** creates an instance of the alert for every unique value of the `field` added. For example, you can create a rule per host or every mount point of each host. You can also add multiple fields. In this example, the rule will individually track the status of each `host.name` in your infrastructure. You will only receive an alert about `host-1`, if `host.name: host-1` passes the threshold, but `host-2` and `host-3` do not.
 
 When you select **Alert me if a group stops reporting data**, the rule is triggered if a group that previously reported metrics does not report them again over the expected time period.

solutions/security/get-started/_snippets/agentless-integrations-faq.md

@@ -69,3 +69,7 @@ When you create a new agentless CSPM integration, a new agent policy appears wit
 2. Go to the CSPM Integration’s **Integration policies** tab.
 3. Find the integration policy for the integration you want to delete. Click **Actions**, then **Delete integration**.
 4. Confirm by clicking **Delete integration** again.
+
+## Can agentless integrations use a specific range of static IP addresses for configuring allow and deny rules for traffic?
+
+No, agentless integrations can not use a specific range of static IP addresses for configuring ingress and egress allow and deny rules.