plugin-docker-buildx
A drop-in rebuild of woodpeckerci/plugin-docker-buildx with the internal
Vault-PKI CA baked in.
Why
The stock woodpeckerci/plugin-docker-buildx image does not trust artifactapi's
internal CA, so k8s Woodpecker buildx jobs cannot push to
artifactapi.k8s.syd1.au.unkin.net/docker-internal/* — buildkit needs
/etc/docker/certs.d/<registry>/ca.crt inside the plugin container, and the k8s
backend has no way to inject it.
This image copies the vault-ca-cert bundle (root + intermediate) into that path
plus the system trust store, so pipelines can settings.registry: artifactapi.k8s.syd1.au.unkin.net and push over TLS.
Published as
artifactapi.k8s.syd1.au.unkin.net/docker-internal/plugin-docker-buildx:<tag> (and :latest)
Bootstrap
This image is itself built and pushed by buildah (.woodpecker/release.yaml),
not by buildx, using buildah push --tls-verify=false. buildah is used precisely
because it sidesteps the buildx CA-trust problem that this image exists to fix —
its own push therefore cannot rely on that trust yet.
Once published, point Woodpecker docker-buildx steps at this image instead of the upstream one to push to the docker-internal registry.
artifactapi login
When pushing to artifactapi.k8s.syd1.au.unkin.net with no username/password
or matching logins entry, the entrypoint logs in to Vault with the pod's service
account token (auth/k8s/au/syd1/login, role woodpecker_artifactapi_writer),
reads identity/oidc/token/artifactapi-writer and adds it as the registry password.
Override with vault_addr, vault_role and vault_oidc_role. Missing SA token or
a Vault error logs a warning and pushes unauthenticated.
Run make test to exercise the login logic inside the built image.