[Draft] ECK 3.2 doc updates

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

@@ -101,10 +101,10 @@ 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/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.