5d2bf73d84
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>
3.2 KiB
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-sinkpods (matched byapp.kubernetes.io/name). - Egress:
transparency-log(:8080),trust-pg(:5432), external HTTPS/443 for the Pocket-ID JWKS, DNS tokube-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.