commercial-spilo-fips

packaged by Chainguard

Chainguard Container for commercial-spilo-fips

FIPS-compliant Commercial Spilo — highly available PostgreSQL cluster (Zalando Spilo) built from the commercial-spilo-fips package.

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/commercial-spilo-fips:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Compatibility Notes

This is the FIPS variant of the commercial-spilo container image. It contains the same software, configuration, and entrypoint, and is a drop-in replacement for deployments already using scram-sha-256 password authentication. Clusters still relying on MD5 need the migration described under FIPS Support first.

This image contains the TSL-licensed build of TimescaleDB, which enables features gated behind the Timescale License (e.g., compression, continuous aggregates). See the TimescaleDB editions feature comparison for a complete list.

It is designed to provide a secure and minimal environment for running Spilo while maintaining functional parity with the upstream image.

Spilo is a highly available PostgreSQL distribution for Kubernetes, developed by Zalando. It combines PostgreSQL with Patroni for high availability and automatic failover, providing a robust database solution for cloud-native applications. This image includes PostgreSQL 18 with integrated support for Patroni, WAL-E/WAL-G for continuous archiving, and connection pooling capabilities.

FIPS Support

This Chainguard Container ships with a validated redistribution of OpenSSL's FIPS provider module. PostgreSQL, libpq, pgbouncer, pam-oauth2, and CPython all link the system OpenSSL dynamically, so they take their cryptography from that provider. Patroni is a Python application and is covered by that same CPython path. The Go components, WAL-G and timescaledb-parallel-copy, are built with the FIPS Go toolchain, which routes their cryptography through the same system OpenSSL. For more on FIPS support in Chainguard Containers, consult the guide on FIPS-enabled Chainguard Containers on Chainguard Academy.

Because MD5 is not a FIPS-approved algorithm, it is unavailable in this image. In practice this means:

• Passwords must be stored as scram-sha-256 verifiers. PostgreSQL 14 and later default password_encryption to scram-sha-256 and Spilo does not override it, so this needs no configuration. Note that Spilo's generated pg_hba.conf still names the md5 method, which is fine: PostgreSQL transparently negotiates SCRAM on an md5 line whenever the stored verifier is SCRAM, so no MD5 hashing is performed.
• Roles whose passwords were created as MD5 verifiers in a non-FIPS deployment must have their passwords reset before they can authenticate against this image.
• SQL calls to md5() fail with could not compute MD5 hash: unsupported.

Getting Started

Docker

Run a standalone Spilo instance with Docker:

docker run --rm cgr.dev/ORGANIZATION/commercial-spilo-fips:latest

This deploys a single-node PostgreSQL cluster with Patroni.

Kubernetes

To deploy Spilo on Kubernetes, use the Zalando Postgres Operator Helm chart. Add the Helm repository:

helm repo add postgres-operator-charts https://opensource.zalando.com/postgres-operator/charts/postgres-operator
helm repo update

Override the default images in a values.yaml file. The chart defaults to the upstream ghcr.io/zalando/* images for the operator itself, the logical-backup job, and the connection pooler, so point each at its Chainguard FIPS counterpart alongside the Spilo image:

cat <<EOF > values.yaml
rbac:
  create: true
  createAggregateClusterRoles: false
image:
  registry: cgr.dev
  repository: ORGANIZATION/postgres-operator-fips
  tag: latest
configGeneral:
  docker_image: cgr.dev/ORGANIZATION/commercial-spilo-fips:latest
  enable_pgversion_env_var: false
  kubernetes_use_configmaps: true
configLogicalBackup:
  logical_backup_docker_image: cgr.dev/ORGANIZATION/postgres-operator-logical-backup-fips:latest
configConnectionPooler:
  connection_pooler_image: cgr.dev/ORGANIZATION/zalando-pgbouncer-fips:latest
EOF

Only the operator image is deployed from these values by default. The logical-backup and connection-pooler images are per-cluster opt-ins: the operator pulls them once a postgresql resource sets spec.enableLogicalBackup: true or spec.enableConnectionPooler: true (spec.enableReplicaConnectionPooler for replicas). Leaving either at the chart default puts a non-FIPS image into the deployment at that point, and the pooler matters most, since it terminates client connections and so sits in the data path alongside Spilo.

Install the Postgres Operator:

helm install postgres-operator \
  postgres-operator-charts/postgres-operator \
  -f values.yaml \
  --namespace commercial-spilo-fips \
  --create-namespace \
  --wait

Create a PostgreSQL cluster:

kubectl apply -f - <<EOF
apiVersion: "acid.zalan.do/v1"
kind: postgresql
metadata:
  name: my-postgres-cluster
  namespace: commercial-spilo-fips
spec:
  teamId: "my-team"
  volume:
    size: 1Gi
  numberOfInstances: 2
  users:
    myuser:
      - superuser
      - createdb
  databases:
    mydb: myuser
  postgresql:
    version: "18"
EOF

Verify the cluster is running:

kubectl get postgresql -n commercial-spilo-fips
kubectl get pods -n commercial-spilo-fips -l cluster-name=my-postgres-cluster

Documentation and Resources

• Spilo GitHub
• Postgres Operator documentation
• Postgres Operator Helm Chart
• FIPS-enabled Chainguard Containers

What are Chainguard Containers?

Chainguard's free tier of Starter container images are built with Wolfi, our minimal Linux undistro.

All other Chainguard Containers are built with Chainguard OS, Chainguard's minimal Linux operating system designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a development, or -dev, variant.

In all other cases, including Chainguard Containers tagged as :latest or with a specific version number, the container images include only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager.

Although the -dev container image variants have similar security features as their more minimal versions, they include additional software that is typically not necessary in production environments. We recommend using multi-stage builds to copy artifacts from the -dev variant into a more minimal production image.

Need additional packages?

To improve security, Chainguard Containers include only essential dependencies. Need more packages? Chainguard customers can use Custom Assembly to add packages, either through the Console, chainctl, or API.

To use Custom Assembly in the Chainguard Console: navigate to the image you'd like to customize in your Organization's list of images, and click on the Customize image button at the top of the page.

Learn More

Refer to our Chainguard Containers documentation on Chainguard Academy. Chainguard also offers VMs and Libraries — contact us for access.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.