[ahma]

Summary

Publishing and signing a container image now happens in a dedicated job that runs only after the test, e2e,
lint and license checks, under a release environment, with the write scopes confined to that job. Every
action is pinned to a commit, the verify step takes its inputs through the environment, the debug stage
pins Delve and binds it to loopback, the build context is an allowlist, and two tooling recipes stop
doing the wrong thing silently.

Why

The security review of the repository at d515e17 (main plus #29 to #32) recorded that any push of a
tag matching the release glob, or of a release-* branch, published and keyless-signed an official image
with no quality gate and with write scopes granted to every image build, including pull requests. The
repository settings add no protection today (no rulesets, no tag protection). The review also noted
floating action tags, an unpinned Delve on an unauthenticated port, no .dockerignore, a minikube-deploy
recipe that continued on the default Docker daemon when minikube docker-env failed, and an e2e suite that
drove whatever process held port 8080.

What changed

• ci(image): the image workflow has a build job (read-only token; builds both platforms, scans, uploads
  the report) and a publish job (if: inputs.publish, needs: build, environment: release; rebuilds
  from the layer cache, pushes, signs and verifies). QEMU is dropped because the Dockerfile cross-compiles
  and the final stage has no RUN.
• ci: a read-only token by default; the image build runs after the four checks on every push.
• ci(release): a tag push now runs the same four checks before it publishes.
• build(docker): Delve pinned to v1.27.2 and bound to 127.0.0.1; .dockerignore allows only the six
  source paths.
• chore(git): ignore signing-key.pem (the README example path) and the user-database temp files.
• build(just): minikube-deploy stops when minikube docker-env fails and pins --context minikube.
• test(e2e): the suite refuses a listener on the port that is not the server it started.
• docs(readme): a "Releases" section with what publishes, what gates it, and the settings the owner sets.
• ci: the minikube profile is pinned for docker-env as it is for kubectl; the e2e issuer check normalises
  the trailing slash and states what it can tell apart.

Test plan

• just verify, just test-race and the e2e suite (in a Linux container) green on the branch head.
• Workflow files parsed and the job graph checked: every needs: target exists, every uses: is pinned.
• Negative check of the e2e guard: with another listener on the port, every case fails in setup with a clear
  message; without it the class passes.
• First CI run of this PR (run 40779970641): Test, E2E, Lint, License check and the build job of the
  split workflow passed; the build job compiled linux/amd64 and linux/arm64 by cross-compilation
  ([linux/amd64->arm64 builder] stages, provenance for both platforms) with no QEMU step; the publish
  job was skipped as designed for a pull request. The environment gate and the push, sign and verify steps
  run only on a publishing push and are still to be observed there.

Review record and residuals

Reviewed twice by an independent reviewer (plan and diff); every finding accepted. Residuals stated on
purpose: the quality gates are a property of the two current callers, not of the reusable workflow (a new
caller could skip them); the Trivy report describes the prepublication build, not the rebuilt image that
is signed; the e2e listener check does not distinguish a foreign IdP serving the same issuer (accepted on a
private runner); loopback-only binding of the e2e server waits for the server's LISTEN_ADDR support in a
later PR; the buildx BuildKit image is not digest-pinned; the digest output falls back to the build digest
and does not certify publication.

Compatibility

• Publishing from main now waits for the release environment's rules once they exist.
• The image that is signed is rebuilt from cache in the publish job; its digest may differ from the
  tarball the scan step examined. The scan remains a report, not a gate.

Settings this PR cannot provide

Until the owner configures them, anyone with push access can still publish a signed image:

1. A ruleset on tags [0-9]+.[0-9]+.[0-9]+* and branches release-* that restricts creation, update and
   deletion to the release team.
2. Protection rules on the release environment (required reviewers, deployment branches and tags).
3. Optionally, required status checks on main.

Not in this PR

A USER directive in the Dockerfile (needs a chart change for the user-database volume ownership);
Trivy as a blocking gate.

Stacked on #32 (feat/terraform-clients-token-ttl). Draft until the stack is merged.

[Copilot]

🔵 Needs a closer look

The cited PR run skipped the privileged publish job, so release-environment approval enforcement and the registry push/sign/verify flow still require maintainer validation on an authorized publishing push.

No open issues 🎉

What changed in this PR

This PR hardens container publishing for the OIDC identity provider by separating read-only builds from privileged publishing and requiring quality checks before either current workflow publishes.

Changes:

• Gate image builds on tests, e2e tests, lint and license checks; isolate publishing and signing in a release environment job.
• Pin actions and Delve, restrict the Docker build context, and ignore additional local key and database files.
• Add deployment and e2e safeguards, and document release behavior and required repository protections.

File	Description
scripts/​e2e.py	Check server process state and discovery issuer before running tests.
README.md	Document publishing gates, signature verification and owner-configured protections.
justfile	Stop on minikube environment failures and pin deployment context.
Dockerfile	Pin Delve and bind its debug API to loopback.
.gitignore	Ignore the PEM signing key and temporary user-database files.
.github/​workflows/​release.yaml	Add four quality gates before release image publishing and pin actions.
.github/​workflows/​image-build.yaml	Separate build and publish jobs, isolate write permissions and pin actions.
.github/​workflows/​ci.yaml	Default to read-only permissions, gate image builds and pin actions.
.dockerignore	Allow only required source paths into the build context.

_{Review effort: Balanced}