docs: import CloudNativePG main

Author: cnpg-bot

website/docs/cluster_conf.md

@@ -89,6 +89,17 @@ the `.spec.ephemeralVolumesSizeLimit.shm` field in the cluster spec.
 Use this field only in case of
 [PostgreSQL running with `posix` shared memory dynamic allocation](postgresql_conf.md#dynamic-shared-memory-settings).
 
+## ServiceAccount token mount
+
+The `automountServiceAccountToken` field of the cluster specification
+controls the automatic mount of the `ServiceAccount` token in the instance
+Pods and in the Jobs that create them. Setting it to `false` helps comply
+with admission policies enforced in hardened environments; the operator then
+mounts an equivalent projected volume so that the instance manager can keep
+working. See
+["Disabling the automatic mount of the ServiceAccount token"](security.md#disabling-the-automatic-mount-of-the-serviceaccount-token)
+for the details.
+
 ## Environment variables
 
 :::important

website/docs/security.md

@@ -490,6 +490,47 @@ PostgreSQL `Cluster` resource name.
     [recommended way to access the API server from within a Pod](https://kubernetes.io/docs/tasks/run-application/access-api-from-pod/).
 :::
 
+#### Disabling the automatic mount of the ServiceAccount token
+
+Some hardened environments enforce admission policies that require
+`automountServiceAccountToken: false` on every Pod and on the
+`ServiceAccount` itself. You can comply with such policies by setting the
+`automountServiceAccountToken` field in the cluster specification:
+
+```yaml
+apiVersion: postgresql.cnpg.io/v1
+kind: Cluster
+metadata:
+  name: cluster-example
+spec:
+  automountServiceAccountToken: false
+  instances: 3
+  storage:
+    size: 1Gi
+```
+
+The value is copied verbatim to the specification of the instance Pods, to
+the pod template of the Jobs that create the instances, and to the
+`ServiceAccount` generated by the operator.
+
+Since the instance manager requires access to the Kubernetes API server, when
+the automatic mount is disabled the operator adds to those Pods and Jobs an
+explicit projected volume named `kube-api-access`, equivalent to the volume
+that Kubernetes would have automounted, and mounts it on every container at
+`/var/run/secrets/kubernetes.io/serviceaccount`. As a result, the workload
+keeps the same API server access it would have with the default settings,
+while satisfying policies that check the `automountServiceAccountToken`
+fields.
+
+Changing the field triggers a rolling update of the cluster.
+
+:::note
+When a shared `ServiceAccount` is referenced through `serviceAccountName`
+(see below), the operator does not modify it: setting
+`automountServiceAccountToken: false` on the `ServiceAccount` itself is your
+responsibility in that case.
+:::
+
 #### Using a shared ServiceAccount
 
 By default, CloudNativePG creates a dedicated `ServiceAccount` for each cluster,