ProofedMesh/deploy/verification-service
CTO 5d2bf73d84
Some checks failed
build-images / signing-service image (push) Successful in 23s
build-images / verification-service image (push) Successful in 48s
build-images / dummy-sink image (push) Successful in 49s
validate / JSON Schema (ajv) (push) Successful in 23s
validate / Rego (opa fmt + opa test) (push) Successful in 15s
phase1-smoke / Phase 1 end-to-end smoke (push) Successful in 1m0s
validate / DB (migrate up/down dry-run) (push) Successful in 24s
validate / Go (vet + test) (push) Has been cancelled
deploy: verification-service + dummy-sink Phase-1 manifests (DEV-615)
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>
2026-10-25 21:09:14 +00:00
..
00-serviceaccount.yaml deploy: verification-service + dummy-sink Phase-1 manifests (DEV-615) 2026-10-25 21:09:14 +00:00
10-secret-dev.example.yaml deploy: verification-service + dummy-sink Phase-1 manifests (DEV-615) 2026-10-25 21:09:14 +00:00
20-deployment.yaml deploy: verification-service + dummy-sink Phase-1 manifests (DEV-615) 2026-10-25 21:09:14 +00:00
30-service.yaml deploy: verification-service + dummy-sink Phase-1 manifests (DEV-615) 2026-10-25 21:09:14 +00:00
40-networkpolicy.yaml deploy: verification-service + dummy-sink Phase-1 manifests (DEV-615) 2026-10-25 21:09:14 +00:00
README.md deploy: verification-service + dummy-sink Phase-1 manifests (DEV-615) 2026-10-25 21:09:14 +00:00

verification-service — deployment

Kubernetes manifests for the ADR-0006 verification-service in the agent-trust namespace. The namespace itself is created by deploy/trillian/00-namespace.yaml; this directory assumes that file (or an equivalent) is already applied.

Layout

deploy/verification-service/
├── 00-serviceaccount.yaml       — ServiceAccount (auto-mount off)
├── 10-secret-dev.example.yaml   — TEMPLATE for the dev-mode Secret
├── 20-deployment.yaml           — Deployment (non-root, read-only rootfs, distroless)
├── 30-service.yaml              — ClusterIP Service on :8084
├── 40-networkpolicy.yaml        — ingress from approval-service / testagent-transform / dummy-sink,
│                                  egress to TLog + trust-pg + Pocket-ID JWKS
└── README.md                    — this file

Apply order

kubectl apply -f deploy/trillian/00-namespace.yaml  # if not yet applied
kubectl apply -f deploy/verification-service/00-serviceaccount.yaml
# Create the dev Secret separately (see "Secret convention" below) — DO NOT
# commit the real values. The .example file is a template, not a secret.
kubectl apply -f deploy/verification-service/20-deployment.yaml
kubectl apply -f deploy/verification-service/30-service.yaml
kubectl apply -f deploy/verification-service/40-networkpolicy.yaml

Reach the service in-cluster at:

http://verification-service.agent-trust.svc.cluster.local:8084

Health check (also used by Deployment probes):

GET /healthz → 200 {"status":"ok"}

Verify endpoint (per ADR-0006 / DEV-612):

POST /api/v1/verify/chain
Content-Type: application/json

K8s secret convention

The verification-service only reads one Secret — verification-service-dev (or verification-service-prod when the key rotation uses production material). The Secret shape is a single key, VERIFICATION_SIGNER_KEYS, whose value is the comma- or newline-separated keyid=<enc>:<data> spec documented in services/verification-service/README.md.

For the GitOps path, convert the created Secret to a SealedSecret with kubeseal and commit the sealed form under the same filename as the example:

kubectl create secret generic verification-service-dev -n agent-trust \
  --from-file=VERIFICATION_SIGNER_KEYS=./signer-keys.spec \
  --dry-run=client -o yaml | \
  kubeseal --controller-namespace=sealed-secrets --format=yaml \
    > deploy/verification-service/10-secret-dev.sealed.yaml

NetworkPolicy

See 40-networkpolicy.yaml. In short:

  • Ingress: approval-service, testagent-transform, dummy-sink pods (matched by app.kubernetes.io/name).
  • Egress: transparency-log (:8080), trust-pg (:5432), external HTTPS/443 for the Pocket-ID JWKS, DNS to kube-dns.

Image

Images are built by .forgejo/workflows/build-images.yml on every push to main and pushed to:

harbor.basicstack.de/basicstack/verification-service:<git-sha>
harbor.basicstack.de/basicstack/verification-service:main      (floating)

The Deployment currently references :dev; a GitOps apply will pin it to a :<git-sha> once the image build pipeline has produced one.