Secrets and keys

You do not have to create any secrets to install Lembos. A setup job runs before every install and upgrade and makes sure each one exists.

Where each secret comes fromCopy Anchor Link

For every secret, in order:

1. A Secret you manage — named with existingSecret, for instance from Sealed Secrets, External Secrets or SOPS. Lembos leaves it alone.
2. A value in your values file, which the job writes.
3. The value already in the cluster, which the job keeps.
4. Generated by the job.

Nothing is rotated by an upgrade. To rotate a value, delete that key (or the whole Secret) and upgrade.

What is in themCopy Anchor Link

The release's Secret, lembos-secrets, holds the services' client secrets, Identity's encryption key, the bootstrap administrator's password, and the PostgreSQL and Redis passwords.

Four key pairs sit beside it: the key Identity signs tokens with, and the certificates that protect each service's sign-in key ring. Self-signed pairs are right for all four. If you issue them with cert-manager, use a long duration and never rotate the private key.

Back them upCopy Anchor Link

helm uninstall deliberately leaves these Secrets behind, so reinstalling into the same namespace picks them up again. Deleting the namespace removes them.

Verifying the imagesCopy Anchor Link

Every Lembos image is signed when it is published, and the signature is recorded in the public Rekor transparency log. Verify by digest rather than by tag — a tag can move after signing:

cosign verify \
  --certificate-identity-regexp '^https://github.com/lembosproj/platform/\.github/workflows/release\.yml@refs/heads/main$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ghcr.io/lembosproj/platform/orchestrator@sha256:<digest>

An admission controller that checks signatures, such as Kyverno or Sigstore's policy controller, takes the same two values.