Install

One Helm command. The chart pulls straight from the registry — there is no repository to add.

Before you start

• Kubernetes 1.27 or newer, any conformant distribution.
• Permission to create a ValidatingWebhookConfiguration — cluster-scoped, so cluster-admin on the first install.
• A namespace of its own. The chart creates one.
• Roughly 20 GiB for the bundled PostgreSQL, or the DSN of one you already run.

Install

# installs from the registry; no `helm repo add` needed
helm install attestkeep oci://ghcr.io/attestkeep/charts/attestkeep \
  --namespace attestkeep --create-namespace \
  --set clusterName=production-eu \
  --wait

clusterName is the one value worth setting on the first install, even for a trial. It is the label every notification and every evidence document uses to say which installation it came from, and it cannot be inferred from the cluster. Nothing topological leaves the cluster, so this is a name you choose, not a hostname.

Confirm it is running

kubectl -n attestkeep get pods
kubectl -n attestkeep port-forward svc/attestkeep 8080:8080

Then open http://localhost:8080. The first screen asks for an activation key; see Licensing for where to get one.

The database builds itself

Migrations are compiled into the binary and applied on first connection, each recorded so it runs exactly once. There is no SQL for you to run and no migration step to forget on upgrade.

To use a database you already run, put the DSN in a secret rather than on the command line — an inline value lands in your Helm release history and stays there.

kubectl -n attestkeep create secret generic attestkeep-db \
  --from-literal=dsn='postgres://user:pass@db.internal:5432/attestkeep?sslmode=require'

helm upgrade attestkeep oci://ghcr.io/attestkeep/charts/attestkeep \
  --namespace attestkeep \
  --set postgresql.enabled=false \
  --set externalDsnExistingSecret.name=attestkeep-db

Private registries

Nothing to configure. The operator resolves the same image pull secrets the pod references, and those on its service account, and uses them for both the scan and the signature check.

High availability

The webhook runs two replicas by default, spread across nodes by anti-affinity: one is enough to serve, two to survive a node. The serving certificate lives in a secret rather than on each replica, so a rotation reaches every replica without a restart.

Uninstall

helm uninstall attestkeep --namespace attestkeep

Removing the release removes the webhook configuration with it, so admission stops being reviewed the moment it is gone. The database volume is not deleted; findings and evidence survive an uninstall unless you remove the PVC yourself.