PostgreSQL

It is possible to deploy Immuta without the use of cloud-provided managed services by using enterprise-ready tools for Kubernetes.

This article describes deploying a PostgreSQL cluster in the Immuta installation namespace using CloudNativePG (CNPG), a CNCF Sandbox project that manages the full lifecycle of highly available PostgreSQL clusters on Kubernetes.

Deploying CloudNativePG

This section relies on the CloudNativePG official documentation found at the link below.

Installation and upgrades | CloudNativePGcloudnative-pg.io

Install the operator

kubectl apply --server-side -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.28/releases/cnpg-1.28.1.yaml

Verify the operator is running:

kubectl get deployment -n cnpg-system
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
cnpg-controller-manager   1/1     1            1           60s

If you are upgrading an existing CNPG installation, add the --force-conflicts flag to take ownership of the CRD fields from the previous installation:

kubectl apply --server-side --force-conflicts -f \
  https://raw.githubusercontent.com/cloudnative-pg/cloudnative-pg/release-1.28/releases/cnpg-1.28.1.yaml

Deploy a PostgreSQL cluster

The following manifest creates a single-instance PostgreSQL 16 cluster with the immuta, temporal, and temporal_visibility databases required by Immuta. The pgcrypto extension is installed automatically in the immuta database.

cat <<EOF | kubectl apply -f -
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
  name: immuta-postgresql
  namespace: immuta
spec:
  instances: 1
  imageName: ghcr.io/cloudnative-pg/postgresql:16
  bootstrap:
    initdb:
      database: immuta
      owner: immuta
      postInitSQL:
        - ALTER ROLE immuta SET search_path TO audit,bometadata,now,public;
        - CREATE DATABASE temporal OWNER immuta;
        - CREATE DATABASE temporal_visibility OWNER immuta;
        - GRANT ALL ON DATABASE temporal TO immuta;
        - GRANT ALL ON DATABASE temporal_visibility TO immuta;
      postInitApplicationSQL:
        - CREATE EXTENSION IF NOT EXISTS pgcrypto;
  storage:
    size: 50Gi
EOF

postInitSQL runs against the postgres database as the superuser, which is why CREATE DATABASE statements are placed there. postInitApplicationSQL runs against the immuta database, where the pgcrypto extension is needed.

Verifying cluster health

kubectl get -n immuta cluster
NAME                AGE   INSTANCES   READY   STATUS                     PRIMARY
immuta-postgresql   60s   1           1       Cluster in healthy state   immuta-postgresql-1

Configure databases

After the cluster is healthy, create the btree_gin extension in the temporal_visibility database:

kubectl exec -n immuta immuta-postgresql-1 -- \
  psql -U postgres -d temporal_visibility -c "CREATE EXTENSION IF NOT EXISTS btree_gin;"

Validate connectivity

The immuta user password is stored in the secret created automatically by CNPG.

PASSWORD=$(kubectl get -n immuta secret immuta-postgresql-app -o go-template='{{.data.password | base64decode}}')

Forward the port in a separate terminal:

kubectl port-forward -n immuta service/immuta-postgresql-rw 5432

In the original terminal with the password set, connect using psql:

psql -h localhost -U immuta -d immuta

Verify the databases, extensions, and search path:

\l
\dx
SHOW search_path;
\c temporal_visibility
\dx

Immuta Helm Values

Use the following postgresql configuration in your Immuta Helm values to connect to the in-cluster CNPG deployment. The immuta user password is stored in the secret created automatically by CNPG.

PASSWORD=$(kubectl get -n immuta secret immuta-postgresql-app -o go-template='{{.data.password | base64decode}}')
echo $PASSWORD

global:
  postgresql:
    host: immuta-postgresql-rw.immuta.svc.cluster.local
    port: 5432
    username: immuta
    password: <password-from-secret-above>
    ssl: true