Upgrade

A Helm upgrade. Migrations are compiled into the binary and applied on first connection, so there is no separate step to forget.

Upgrading

helm upgrade attestkeep oci://ghcr.io/attestkeep/charts/attestkeep \
  --namespace attestkeep --wait

Pin the version if your change process needs it:

helm upgrade attestkeep oci://ghcr.io/attestkeep/charts/attestkeep \
  --namespace attestkeep --version 1.3.2 --wait

What happens to the database

Each migration is recorded when it runs, so it runs exactly once no matter how many replicas start at the same time. Findings, decisions, exceptions and evidence survive the upgrade; nothing is rebuilt from scratch.

1.3.1 to 1.3.2

helm upgrade attestkeep oci://ghcr.io/attestkeep/charts/attestkeep \
  --version 1.3.2 \
  --namespace attestkeep --wait

No migrations and no new values; helm rollback to 1.3.1 works. If you copied the falcoctl values from the 1.3.1 rule editor, add falco-rules:5 back to install.refs and follow.refs; see the 1.3.2 notes.

1.3.0 to 1.3.1

helm upgrade attestkeep oci://ghcr.io/attestkeep/charts/attestkeep \
  --version 1.3.1 \
  --namespace attestkeep --wait

Migrations 0026 to 0032 are applied on the first start of the new version. They move forward only: a return to 1.3.0 is a restore from backup, not a helm rollback.

Remove runtime.enforceBlocks from your policy files. Runtime blocks are gone in 1.3.1 and the policy resource no longer has a runtime field. kubectl apply, with its default strict validation, refuses a policy that still carries it with unknown field "spec.runtime". A runtime rule written as block becomes a notify rule with an issue on, by the migration; nothing at runtime changes an admission decision any more. To act on a pod, give a runtime policy stop, which needs rbac.allowEnforce: true; see stopping the pod.

helm upgrade --reuse-values works across this version: integrations.falco.connection is read with its default, mtls, so a Falco connected directly keeps arriving as before. Existing notification channels keep their subscriptions; only a channel created from 1.3.1 on is subscribed to runtime_alert by default.

1.2.x to 1.3.0

helm upgrade attestkeep oci://ghcr.io/attestkeep/charts/attestkeep \
  --version 1.3.0 \
  --namespace attestkeep --wait

Migration 0025 is applied on the first start of the new version. It moves forward only: a return to 1.2.x is a restore from backup, not a helm rollback.

Re-activate the cluster. A 1.3.0 operator needs a certificate that carries the node ceiling, and a certificate issued before licence service 1.3.0 does not. One without it is refused with "re-activate with a key issued by licence service 1.3.0 or later". See the node ceiling.

Nothing else changes. helm upgrade --reuse-values works across this version: nodes.pollInterval and nodes.graceDays are read with their defaults, 5m and 14.

1.1.x to 1.2.0

Migrations 0021 to 0024 are applied on the first start of the new version. They move forward only: the database cannot be taken back to a 1.1.x schema by a Helm rollback, so a return to 1.1.x is a restore from backup, not a helm rollback.

helm upgrade --reuse-values works across this version. The values 1.2.0 adds are read with their defaults when an upgrade carries the previous release's values forward — the Falco integration off, integrations.port 8444, and stored runtime events kept for 90 days.

• If Falco sends you events through Falcosidekick with a bearer token, they stop on upgrade. That endpoint is gone; integrations.falco.existingSecret and integrations.falco.minPriority are no longer read. Connect Falco's own http_output over mutual TLS as runtime events describes, then delete the old token Secret.
• Deleting a user now disables the account rather than removing it. Accounts deleted before the upgrade are already gone; nothing is restored.
• Evidence packages generated after the upgrade name accounts as user:<account id>; packages generated before it keep what they were signed with. See compliance frameworks.

Nothing about an installed policy or licence changes. runtime.enforceBlocks defaults to false, so no runtime block refuses a pod until a policy says so.

1.0.2 to 1.1.0

Migrations 0013 to 0020 are applied on the first start of the new version. They move forward only: the database cannot be taken back to a 1.0.2 schema by a Helm rollback, so a return to 1.0.2 is a restore from backup, not a helm rollback.

helm upgrade --reuse-values works across this version. Every value 1.1.0 adds carries a chart default, so an upgrade that keeps your installed values takes those defaults — kev.source pointing at CISA's catalogue, the Falco endpoint off, and the data key generated rather than supplied.

Three things appear on the upgrade itself:

• The chart generates a <release>-data-key Secret and preserves it from then on. Add it to your backup set. It encrypts the issue-tracker credentials this installation stores, and a credential sealed under a key you no longer hold cannot be opened: each tracker channel then needs its token entered again. See Backup and restore.
• Tracker channels configured before 1.1.0 hold their token in plain text. One pass on the first start, on the leader, seals them in place and logs how many it changed. There is nothing to run by hand.
• The ClusterRole gains read access to Services and Ingresses, which is what the exposed signal reads. An installation that manages its own RBAC has to grant the two rules itself; an operator that cannot list them derives exposure from the pod spec alone, logs a warning and admits.

Nothing about an installed policy, licence or evidence document changes. Existing policies behave as before: the two new gates that have a default, endOfLifeOS and knownExploited, default to warn, and the provenance, VEX and deployment-context blocks are off until you write them.

What happens to admission during the rollout

With the default two replicas, one keeps answering while the other is replaced. With failurePolicy: Ignore a moment with no replica means unreviewed rather than blocked; with Fail it means deployments wait. That is the same trade described in Admission, and an upgrade is exactly when it becomes visible.

Verifying what you are about to run

Every release is signed. Check it before you upgrade:

cosign verify ghcr.io/attestkeep/attestkeep-k8s:1.3.2 \
  --certificate-identity-regexp '^https://github.com/attestkeep/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

A product that checks your signatures should be checkable the same way. The chart is signed too, and the release page carries the digest for each artefact.

Rolling back

helm rollback attestkeep --namespace attestkeep