zeekayandHanzo Dev
b8f260c3f2
The official golang images set GOTOOLCHAIN=local. A floating golang:<minor> tag
that resolves behind the `go` directive in go.mod therefore kills the container
build outright:
go: go.mod requires go >= 1.26.5 (running go 1.26.4; GOTOOLCHAIN=local)
This already shipped as a live failure in hanzoai/visor v1.108.16.
Why this repo and not its sibling KMS forks: this is de-branded first-party code
(module github.com/hanzokms/kubernetes-operator, June 2026 relicense to
BSD-3-Clause and CRD group move to kms.hanzo.ai), so it is maintained and worth
hardening. The three still-upstream Infisical forks alongside it
(agent-injector, cert-issuer, k8s-kms-plugin) are deliberately left untouched.
Two orthogonal changes:
- pin the base to golang:1.26.5 -> hermetic; the image and the directive
always agree, nothing to download.
- ENV GOTOOLCHAIN=auto -> resilient; if go.mod later moves past the
pin, the toolchain is fetched (checksum-verified via sum.golang.org) instead
of hard-failing. This is what stops the class recurring.
Note this moves the builder two minor versions (golang:1.24 -> golang:1.26.5)
to put the repo on the same toolchain as the rest of the fleet. The `go`
directive in go.mod stays at 1.24.0 on purpose: a newer toolchain building an
older directive is always valid, and raising the directive would propagate a
floor to every consumer. If that jump is unwanted, the same fix holds with
golang:1.24.<latest> — only the tag changes, GOTOOLCHAIN=auto still applies.
Verified on go1.26.5 against the 1.24.0 directive:
go build ./... EXIT=0
go vet ./... EXIT=0
go test $(go list ./... | grep -v /e2e) -- with KUBEBUILDER_ASSETS from
setup-envtest, exactly as the Makefile `test` target runs it:
internal/services/kmssecret ok; internal/controller 2 passed / 1 failed.
That one failure is PRE-EXISTING and is not fixed here: the scaffolded spec
"KMSSecret Controller ... should successfully reconcile the resource" creates a
KMSSecret with no managedKubeSecretReferences, which the controller now rejects
("KMSSecret CRD must have at least one managed secret reference set"). The test
has not kept up with the validation. Reproduced identically on the pristine
pre-change tree, which has zero modified files, so it is not caused by the
builder pin.
Co-authored-by: Hanzo Dev <[email protected]>
Hanzo KMS Kubernetes Operator
| Documentation | Website | Slack |
Introduction
Hanzo KMS is the open source secret management platform that teams use to centralize their secrets like API keys, database credentials, and configurations.
The Hanzo KMS Operator is a collection of Kubernetes controllers that streamline how secrets are managed between Hanzo KMS and your Kubernetes cluster. It provides multiple Custom Resource Definitions (CRDs) which enable you to:
- Sync secrets from Hanzo KMS into Kubernetes (
KMSSecret). - Push new secrets from Kubernetes to Hanzo KMS (
KMSPushSecret). - Manage dynamic secrets and automatically create time-bound leases (
KMSDynamicSecret).
Security
Please do not file GitHub issues or post on our public forum for security vulnerabilities, as they are public!
Hanzo KMS takes security issues very seriously. If you have any concerns about Hanzo KMS or believe you have uncovered a vulnerability, please get in touch via the e-mail address [email protected]. In the message, try to provide a description of the issue and ideally a way of reproducing it. The security team will get back to you as soon as possible.
Note that this security address should be used only for undisclosed vulnerabilities. Please report any security problems to us before disclosing it publicly.