CloudNativePG 1.29 puts extension images in the catalog

Adding a PostgreSQL extension to a Kubernetes deployment has consequences beyond the SQL statement that enables it. Someone has to distribute compatible extension files and make them available to the database process. CloudNativePG 1.29 gives that packaging decision a place in the same catalog that selects the PostgreSQL image.

The community's April 2 announcement describes integration between Image Catalogs and an ecosystem of extension container images. The 1.29.0 release notes date the release March 31. These are the release and announcement dates respectively. The April announcement is an opportunity to examine how the operator's deployment model has changed.

I have run PostgreSQL in production for decades and still choose it by default for relational work. Its extension interface is one reason for that preference. Packaging extensions should preserve the usefulness of that interface without requiring every database deployment to maintain its own image-building process.

Extension packaging becomes catalog data

The release notes identify extension support in image catalogs as change #9781. An image catalog can now contain extension-specific images alongside its PostgreSQL image entries. The announcement connects that support to the postgres-extensions-containers project and describes a coordinated distribution system for extension images.

The point is to make the extension's deployable files part of the operator's declared inputs. The announcement explicitly presents this as a way to avoid manually building and maintaining complex custom PostgreSQL images solely to add functionality. That is a change in who assembles the deployment, even when the underlying extension remains the same.

The Image Catalog documentation explains the existing separation between a cluster definition and the lifecycle of its database image. A cluster references a catalog entry for a PostgreSQL major version. Changing the entry can roll out the new image to associated clusters. Extending that relationship to extension images makes the catalog a broader deployment policy.

Catalog scope remains meaningful. ImageCatalog is namespaced, while ClusterImageCatalog applies across the Kubernetes cluster. Those scopes let administrators decide whether a particular image selection belongs to one namespace or is a shared standard. An extension catalog participates in that same choice about the reach of a change.

The catalog documentation also states that the operator trusts the declared PostgreSQL major version. It does not detect the image's actual version to verify a custom catalog entry. Centralizing image selection therefore does not eliminate compatibility responsibility. It gives that responsibility a declared location and allows several consumers to share the result.

Files alone do not describe every extension

The release adds bin_path to postgresql.extensions and to image catalog resources in change #10250. An extension can declare directories containing external binaries, and the operator appends those directories to the PostgreSQL process's PATH. That detail shows why extension packaging requires more than selecting a container reference.

Change #10375 adds an env field in the same places. It lets administrators declare environment variables for the database process. The ${image_root} placeholder resolves to the extension's absolute mount path. Configuration can therefore refer to the deployed extension location without embedding a separately guessed path.

These fields describe runtime requirements that previously could have been incorporated into a custom image or surrounding deployment configuration. Moving them into extension declarations lets the operator carry those requirements with the extension selection. It also makes them relevant to review of the database process's environment.

This is a useful extension of the catalog model, but the authority of the catalog deserves attention. A declaration that changes PATH or environment variables changes how the process locates programs and configuration. Sharing a catalog means sharing those decisions, not simply sharing a list of downloadable artifacts.

My preference is for those dependencies to be visible in configuration. PostgreSQL's extension system is valuable because it can provide substantial functionality inside the database. The packaging mechanism should make that functionality's runtime requirements inspectable alongside the selected database version.

Pod selectors generate PostgreSQL access rules

The same release introduces podSelectorRefs in change #10148. Using these references, the operator resolves the ephemeral IP addresses of selected client pods and updates pg_hba.conf rules. The announcement limits the described client selection to workloads in the same namespace.

That mechanism connects Kubernetes labels to PostgreSQL's host-based authentication configuration. It avoids treating a pod's current IP address as a value an administrator must copy into a long-lived rule. When the selected workload's pod addresses change, the operator has the information needed to update the database rules.

The announcement calls this dynamic network access control, but the implementation detail is worth retaining. These are generated PostgreSQL authentication rules. The feature description does not say that label selection replaces database authentication or creates an independent Kubernetes network policy. It explains how the operator maintains the address-dependent part of database access configuration.

This has a similar administrative shape to the extension change. The operator takes a higher-level declaration and maintains lower-level PostgreSQL configuration from it. In one case the declaration identifies extension images and their runtime requirements. In the other it identifies client pods whose addresses belong in authentication rules.

Shared identities change the unit of administration

CloudNativePG also adds the optional serviceAccountName field to both Cluster and Pooler specifications. The release notes credit Salih Bozkaya for change #9287. Resources can reference a pre-existing ServiceAccount, allowing multiple clusters or poolers to reuse identity configuration.

The notes name AWS IRSA, GCP Workload Identity and Azure Workload Identity as examples. Administrators benefit by configuring the relevant identity relationship once and referencing it where needed. The announcement presents this as a smoother connection between infrastructure-managed permissions and database resources.

Reuse also changes the relationship between consumers. A shared ServiceAccount represents shared identity configuration. Whether that is appropriate depends on which resources should possess the same authority. The release provides the mechanism without establishing that every database cluster should use one common account.

The Pooler changes include separate control of TLS cipher suites and minimum and maximum TLS versions for client and server connections. This matters because a pooler participates in two connections. The release notes explicitly cover both directions, giving administrators control over each side of that intermediary.

Deployment policy now includes more of the database environment

The April announcement describes signed release artifacts and container images. The release notes add SLSA provenance and SBOM generation, giving consumers more information about the supplied binaries and images. These changes support inspection of the distribution process but do not automatically validate a user-authored extension catalog.

Another boundary remains the upgrade policy. The release notes defer removal of native Barman Cloud support to 1.30.0 and continue to encourage migration to the plugin. That is a published future plan as of this release, not a claim that removal has already happened. Operators evaluating 1.29 need the actual compatibility statement when planning their configuration changes.

The extension catalog is the change that most interests me here. It lets a platform define a compatible database deployment with fewer privately assembled images. Its value depends on treating the catalog as reviewed deployment policy, including the extension environment and binary paths that become part of the running PostgreSQL process.