Fuzzball v4.2.3 release notes

Fuzzball v4.2.3 is a patch release that makes volume ownership correct on LDAP-federated deployments and makes the in-workflow API token usable on clusters that terminate TLS with a private CA. It also switches the storage service to structured logging so its warnings survive log aggregation.

Enhancements

In-Workflow API Access

Workflow containers now trust the cluster's own certificate authority without any change to the container image. Whenever a workflow-scoped API token is minted, the job or service container also receives a read-only bind mount of the node trust store at /run/fuzzball-substrate/trusted-certs, and the orchestrate substrate extension publishes the cluster CA into that directory on every node at startup. Previously the injected FB_TOKEN was unusable on a private-CA cluster unless the CA was baked into the image.

• Containers receive SSL_CERT_DIR=/etc/ssl/certs:/etc/pki/tls/certs:/run/fuzzball-substrate/trusted-certs, keeping the image's own trust roots ahead of the node trust store. A SSL_CERT_DIR set in the workflow definition -- or by a cluster experimental env injection -- is left untouched, so the container never sees duplicate keys.
• SSL_CERT_DIR is honored by Go's crypto/x509 and OpenSSL. TLS stacks that want an explicit CA file can point at /run/fuzzball-substrate/trusted-certs/root-ca.crt.
• Both the mount and the environment variable ride the existing disableWorkflowTokens feature flag: turning tokens off also turns off trust-store injection.

Observability

• The storage service now logs through the cluster's structured zap logger. Its warnings previously went out through unstructured slog calls, which log aggregation dropped -- so failures such as a skipped default volume owner were invisible in collected logs.

Bug Fixes & Stability

Storage

• Volume ownership defaulting to root on LDAP-federated deployments. On a deployment using LDAP federation, fuzzball volume create without an explicit --owner produced a volume owned by UID/GID 0. POSIX identity was read only from the database, and LDAP-federated organizations skip POSIX allocation there, so the lookup always returned zero. UID is now resolved from the caller's JWT claims first and falls back to the database; GID resolves from the selected account in the database first -- which stays authoritative for shared and team accounts -- and falls back to the JWT claim, which is what LDAP organizations supply. Organizations not using LDAP federation are unaffected: the database values are non-zero and are used exactly as before, and an explicit --owner always wins.