Verifying Releases

Mon, 01 Jan 0001 00:00:00 +0000

Verifying releases #

Every temporal-operator release is built with GoReleaser, its container images and checksums are signed with Cosign (keyless, via GitHub OIDC), and a SLSA Level 3 provenance attestation is published with the GitHub Release.

Verify the container image signature #

cosign verify ghcr.io/bmorton/temporal-operator:v0.1.0 \
 --certificate-identity-regexp='^https://github.com/bmorton/temporal-operator/.github/workflows/release.yml@.*$' \
 --certificate-oidc-issuer=https://token.actions.githubusercontent.com

For a quick check that accepts any signing identity from this repo’s workflows:

cosign verify ghcr.io/bmorton/temporal-operator:v0.1.0 \
 --certificate-identity-regexp='.*' \
 --certificate-oidc-issuer=https://token.actions.githubusercontent.com

Verify the checksums signature #

cosign verify-blob \
 --signature checksums.txt.sig \
 --certificate-identity-regexp='.*' \
 --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
 checksums.txt

Verify SLSA provenance #

Download multiple.intoto.jsonl from the GitHub Release, then use the slsa-verifier:

Running on Azure

Mon, 01 Jan 0001 00:00:00 +0000

Running on Azure #

This guide covers running the Temporal operator on Azure: AKS, Azure Database for PostgreSQL Flexible Server, Application Gateway ingress, and passwordless Microsoft Entra authentication.

AKS prerequisites #

An AKS cluster (az aks create ...).
The operator installed (see the installation guide).

Persistence: Flexible Server #

Azure Database for PostgreSQL Flexible Server is the recommended SQL backend.

Create the temporal and temporal_visibility databases up front — the operator runs setup-schema but does not create databases.
Raise max_connections (~200) to avoid pool exhaustion on smaller SKUs.
TLS is required; set tls.enabled: true on each store. Azure chains to a public root, so no CA secret is needed.

Example: examples/cluster-azure-postgres-flexible.

Installation on temporal-operator