ServiceAccount, Deployment, Service, and NetworkPolicy per
sub-directory, matching the signing-service template (non-root,
read-only rootfs, distroless, agent-trust namespace).
verification-service — NetworkPolicy allows ingress only from
approval-service, testagent-transform, and dummy-sink, and egress
only to transparency-log, trust-pg, Pocket-ID JWKS (HTTPS/443),
and kube-dns.
dummy-sink — adds a 1Gi longhorn PVC `dummy-sink-data` mounted at
/data/dummy-sink, projected trust-api SA token at
/var/run/secrets/tokens/trust-api, Pocket-ID client creds from a
dev Secret, strategy Recreate (RWO PVC). NetworkPolicy allows
ingress from testagent-transform and egress to verification-service,
signing-service, transparency-log, HTTPS/443 (Pocket-ID OIDC), and
kube-dns.
build-images workflow — adds verification-service and dummy-sink
jobs mirroring signing-service's BuildKit + Harbor pipeline.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Harbor robot usernames are of the form `robot$basicstack+forgejo-ci`.
Forgejo Actions substitutes `${{ secrets.HARBOR_USERNAME }}` into the
`run:` script before bash runs it, so `set -u` sees the resulting
`robot$basicstack+forgejo-ci` and dies with "basicstack: parameter
not set" trying to expand `$basicstack`. Pass the Harbor credentials
as env vars on the step; bash then reads them from the environment as
plain strings instead of parsing them for parameter expansion.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
The signing-service Dockerfile uses the BuildKit `--mount=type=cache`
syntax, which the legacy Docker builder rejects. Debian trixie's
`docker-cli` package does not pull in a BuildKit builder, so even
`DOCKER_BUILDKIT=1` fails with "the --mount option requires BuildKit".
Install Debian trixie's `docker-buildx` package (registers the plugin
at /usr/libexec/docker/cli-plugins/docker-buildx) and switch the build
step to an explicit `docker buildx build --load` so BuildKit frontend
features work regardless of docker-cli aliasing. `--load` ensures the
result is in the local daemon for the subsequent `docker push`.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
The signing-service Dockerfile ([DEV-609](/DEV/issues/DEV-609))
starts with `# syntax=docker/dockerfile:1.7` and uses
`RUN --mount=type=cache,...` for Go build/module caches. The legacy
Docker builder rejects both; the image-build job has been failing on
main since DEV-609 landed:
the --mount option requires BuildKit. Refer to
https://docs.docker.com/go/buildkit/ to learn how to build images
with BuildKit enabled
Fix: set `DOCKER_BUILDKIT=1` on the job env so the daemon routes the
build through the declared Dockerfile frontend.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Debian trixie split the Docker CLI into its own `docker-cli` package.
`docker.io` now only pulls in the daemon, and the CLI dep is a
Recommends — which `--no-install-recommends` skips. Both the new DB
dry-run job in validate.yml and the pre-existing signing-service image
job in build-images.yml were failing with `docker: not found` after
install.
Add `docker-cli` explicitly to both apt install lines.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
- Dockerfile: multi-stage (golang:1.23-alpine3.21 → distroless/static:nonroot),
CGO off, trimpath, stripped, UID/GID 65532, read-only rootfs friendly.
- deploy/signing-service/: ServiceAccount, Deployment (2 replicas, probes,
tight SecurityContext), ClusterIP Service on :8081, NetworkPolicy
(ingress from agent-trust, DNS egress), example Secret, and README with
the full dev + prod secret convention.
- .forgejo/workflows/build-images.yml: builds image on push + PR,
pushes :<git-sha> + :main to harbor.basicstack.de on main pushes only.
Clone pattern matches validate.yml (sha256 repo, manual git clone).
- README updates: service README gains Deployment section; repo README
layout now mentions services/signing-service, services/transparency-log,
deploy/, and the new workflow.
Scope matches DEV-605. OpenBao, OPA and Pocket-ID JWKS stay stubs and move
in their own follow-up subtasks; the prod secret shape is documented so
those subtasks can plug in without reshaping the Deployment.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
