docs: import CloudNativePG main

Author: cnpg-bot

website/docs/installation_upgrade.md

@@ -267,6 +267,22 @@ removed before installing the new one. This won't affect user data but
 only the operator itself.
 
 
+### Upgrading to 1.29.1 or 1.28.3
+
+Version 1.29.1 and 1.28.3 ship the fix for `CVE-2026-44477` /
+`GHSA-423p-g724-fr39`. The metrics exporter now authenticates as a
+dedicated `cnpg_metrics_exporter` role with `pg_monitor` privileges
+only, instead of the `postgres` superuser.
+
+Custom monitoring queries that read user-owned tables, or use
+`target_databases: '*'` against databases where `PUBLIC` `CONNECT`
+has been revoked, need explicit `GRANT` statements to
+`cnpg_metrics_exporter`. See ["Custom query privileges and
+safety"](monitoring.md#custom-query-privileges-and-safety) and ["Manually creating
+the metrics exporter
+role"](monitoring.md#manually-creating-the-metrics-exporter-role) in
+the monitoring documentation.
+
 ### Upgrading to 1.29.0 or 1.28.x
 
 :::info[Important]

website/docs/monitoring.md

@@ -36,10 +36,17 @@ more `ConfigMap` or `Secret` resources (see the
 
 All monitoring queries that are performed on PostgreSQL are:
 
-- atomic (one transaction per query)
-- executed with the `pg_monitor` role
+- atomic (one read-only transaction per query)
+- executed as the `cnpg_metrics_exporter` role (a member of `pg_monitor`)
 - executed with `application_name` set to `cnpg_metrics_exporter`
-- executed as user `postgres`
+
+The connection uses peer authentication on the pod-local Unix socket;
+because `session_user` is never a superuser, the monitoring session
+cannot escalate via `RESET ROLE` or `RESET SESSION AUTHORIZATION`. Do
+not grant additional privileges or role memberships to
+`cnpg_metrics_exporter` beyond `pg_monitor` and the table-level grants
+required by your custom queries: any extra membership flows into the
+scrape session via inheritance and weakens this property.
 
 Please refer to the "Predefined Roles" section in PostgreSQL
 [documentation](https://www.postgresql.org/docs/current/predefined-roles.html)
@@ -494,6 +501,42 @@ Take care that the referred resources have to be created **in the same namespace
     and a key `queryName` containing the overwritten query name.
 :::
 
+#### Custom query privileges and safety
+
+:::warning
+    Custom queries run as the `cnpg_metrics_exporter` role, which inherits
+    `pg_monitor`. Queries within `pg_monitor`'s scope (catalog reads,
+    `pg_stat_*` views, configuration parameters) work without modification.
+    Queries that read user-owned tables or superuser-only catalogs (e.g.
+    `pg_authid`, `pg_subscription`) need explicit grants. Reading a table
+    also requires USAGE on its schema:
+
+    ```sql
+    GRANT USAGE ON SCHEMA myschema TO cnpg_metrics_exporter;
+    GRANT SELECT ON TABLE myschema.mytable TO cnpg_metrics_exporter;
+    ```
+
+    Every database in `target_databases` must allow
+    `cnpg_metrics_exporter` to `CONNECT`. On clusters that have
+    revoked `CONNECT` from `PUBLIC` for a database, grant it
+    explicitly to that role:
+
+    ```sql
+    GRANT CONNECT ON DATABASE domainapp TO cnpg_metrics_exporter;
+    ```
+
+    Prefer an explicit list of trusted databases (e.g.
+    `target_databases: ["domainapp"]`) over the `"*"` wildcard. The
+    wildcard scrapes every database the role can connect to and
+    silently skips the rest, so an explicit list makes a missing grant
+    easier to notice. Use `"*"` only when the query is meant to
+    collect per-database metrics across the whole cluster.
+
+    Schema-qualify catalog references (`pg_catalog.now()`,
+    `pg_catalog.current_database()`) to prevent `search_path` shadowing
+    by user-owned objects.
+:::
+
 #### Example of a user defined metric
 
 Here you can see an example of a `ConfigMap` containing a single custom query,
@@ -570,17 +613,22 @@ Database auto-discovery can be enabled for a specific query by specifying a
 *shell-like pattern* (i.e., containing `*`, `?` or `[]`) in the list of
 `target_databases`. If provided, the operator will expand the list of target
 databases by adding all the databases returned by the execution of `SELECT
-datname FROM pg_database WHERE datallowconn AND NOT datistemplate` and matching
-the pattern according to [path.Match()](https://pkg.go.dev/path#Match) rules.
+datname FROM pg_catalog.pg_database WHERE datallowconn AND NOT datistemplate
+AND pg_catalog.has_database_privilege(datname, 'CONNECT')` and matching the
+pattern according to [path.Match()](https://pkg.go.dev/path#Match) rules.
+Databases on which `cnpg_metrics_exporter` lacks the `CONNECT` privilege are
+silently skipped; if you want a database with revoked `PUBLIC` access to be
+scraped, grant `CONNECT` explicitly (see "Custom query privileges and safety"
+above).
 
 :::note
     The `*` character has a [special meaning](https://yaml.org/spec/1.2/spec.html#id2786448) in yaml,
     so you need to quote (`"*"`) the `target_databases` value when it includes such a pattern.
 :::
 
 It is recommended that you always include the name of the database
-in the returned labels, for example using the `current_database()` function
-as in the following example:
+in the returned labels, for example using the `pg_catalog.current_database()`
+function as in the following example:
 
 ```yaml
 some_query: |
@@ -757,6 +805,33 @@ CloudNativePG is inspired by the PostgreSQL Prometheus Exporter, but
 presents some differences. In particular, the `cache_seconds` field is not implemented
 in CloudNativePG's exporter.
 
+### Manually creating the metrics exporter role
+
+The operator creates the `cnpg_metrics_exporter` PostgreSQL role on the
+primary during reconciliation; it then propagates to standbys and
+replica clusters via streaming replication.
+
+If the role is missing (replica cluster upgraded before its primary,
+restore from a backup that predates the role, accidental removal),
+recreate it as a superuser on the writable primary of the replication
+chain (the source primary, not a designated primary of a replica
+cluster):
+
+```sql
+CREATE ROLE cnpg_metrics_exporter WITH LOGIN NOSUPERUSER NOCREATEDB
+    NOCREATEROLE NOREPLICATION NOBYPASSRLS INHERIT;
+GRANT pg_monitor TO cnpg_metrics_exporter;
+```
+
+If your custom monitoring queries need access to objects outside
+`pg_monitor`'s scope, grant the necessary privileges explicitly. SELECT
+on a table also requires USAGE on its schema:
+
+```sql
+GRANT USAGE ON SCHEMA myschema TO cnpg_metrics_exporter;
+GRANT SELECT ON TABLE myschema.mytable TO cnpg_metrics_exporter;
+```
+
 ## Monitoring the CloudNativePG operator
 
 The operator internally exposes [Prometheus](https://prometheus.io/) metrics

website/docs/release_notes/v1.28.md

@@ -17,6 +17,29 @@ on the release branch in GitHub.
 
 ### Security and Supply Chain
 
+- **`CVE-2026-44477` / `GHSA-423p-g724-fr39`: metrics exporter privilege
+  escalation**: the metrics exporter no longer authenticates as the
+  `postgres` superuser. It now uses a dedicated `cnpg_metrics_exporter`
+  role with `pg_monitor` privileges only, closing a chain that let a
+  low-privilege database user gain PostgreSQL superuser.
+  ([`GHSA-423p-g724-fr39`](https://github.com/cloudnative-pg/cloudnative-pg/security/advisories/GHSA-423p-g724-fr39)) <!-- 1.29 1.28 1.25 -->
+
+    Upgrade impact: custom monitoring queries that read user-owned tables,
+    or use `target_databases: '*'` against databases where
+    `PUBLIC CONNECT` has been revoked, need explicit `GRANT` statements to
+    `cnpg_metrics_exporter`. See ["Custom query privileges and
+    safety"](../monitoring.md#custom-query-privileges-and-safety) and ["Manually
+    creating the metrics exporter
+    role"](../monitoring.md#manually-creating-the-metrics-exporter-role)
+    in the monitoring documentation.
+
+    For replica clusters, upgrade the source primary cluster before any
+    replica clusters that consume from it. The `cnpg_metrics_exporter`
+    role is created on the source primary and replicates downstream; a
+    replica cluster upgraded first will scrape against a missing role
+    until the source primary upgrades. The manual-recovery section
+    linked above also covers replica clusters.
+
 - **Schema-qualified catalog references in default monitoring queries**:
   hardened the shipped monitoring configuration and documentation samples by
   qualifying every `pg_catalog` object explicitly. Unqualified references

website/docs/release_notes/v1.29.md

@@ -17,6 +17,29 @@ on the release branch in GitHub.
 
 ### Security and Supply Chain
 
+- **`CVE-2026-44477` / `GHSA-423p-g724-fr39`: metrics exporter privilege
+  escalation**: the metrics exporter no longer authenticates as the
+  `postgres` superuser. It now uses a dedicated `cnpg_metrics_exporter`
+  role with `pg_monitor` privileges only, closing a chain that let a
+  low-privilege database user gain PostgreSQL superuser.
+  ([`GHSA-423p-g724-fr39`](https://github.com/cloudnative-pg/cloudnative-pg/security/advisories/GHSA-423p-g724-fr39)) <!-- 1.29 1.28 1.25 -->
+
+    Upgrade impact: custom monitoring queries that read user-owned tables,
+    or use `target_databases: '*'` against databases where
+    `PUBLIC CONNECT` has been revoked, need explicit `GRANT` statements to
+    `cnpg_metrics_exporter`. See ["Custom query privileges and
+    safety"](../monitoring.md#custom-query-privileges-and-safety) and ["Manually
+    creating the metrics exporter
+    role"](../monitoring.md#manually-creating-the-metrics-exporter-role)
+    in the monitoring documentation.
+
+    For replica clusters, upgrade the source primary cluster before any
+    replica clusters that consume from it. The `cnpg_metrics_exporter`
+    role is created on the source primary and replicates downstream; a
+    replica cluster upgraded first will scrape against a missing role
+    until the source primary upgrades. The manual-recovery section
+    linked above also covers replica clusters.
+
 - **Schema-qualified catalog references in default monitoring queries**:
   hardened the shipped monitoring configuration and documentation samples by
   qualifying every `pg_catalog` object explicitly. Unqualified references