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.

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.

• 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.

• 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.