Skip to content

lakeFS Mount CSI Driver v1.2.0

Changelog

  • Bumped the bundled everest mount binary from 0.9.2 to 0.11.0.

Write support

  • NodePublishVolume now supports writable mounts. Volumes with accessModes: [ReadWriteMany] and without the CSI readonly flag are mounted read-write — the driver passes --write-mode to everest mount-server — instead of being rejected; read-only volumes (ReadOnlyMany, or readOnly: true) still mount with --read-only.
  • everest uploads writes to an ephemeral branch off the mounted ref and surfaces them as uncommitted changes; persist them with a lakeFS commit (no commit-on-unmount).
  • The Mount Pod's everest mount-server control server now binds the Mount Pod IP (injected via the downward API as EVEREST_POD_IP, applied as --control-listen=$POD_IP:0) instead of 127.0.0.1, so a workload Pod can reach it over TCP to run everest commit. The control channel is gated by everest's .everest/control_auth_token (mandatory once the control server is routable). Requires an everest binary with --control-listen support.
  • Relies on the bundled everest mount binary's FUSE write support.

V2 re-fork from upstream awslabs/mountpoint-s3-csi-driver v2.5.0

V1 of this driver was an old fork of an earlier upstream version, heavily customized (host-mounted everest binary spawned by systemd, privileged in the tenant namespace). V2 starts fresh from upstream's V2 architecture and adds the lakeFS-specific bits as small, focused changes on top.

Architectural changes (inherited from upstream V2): - Unprivileged Mount Pods. The CSI Node DaemonSet opens the FUSE fd and hands it to the Mount Pod over a Unix socket; the Mount Pod itself runs without privilege in the tenant cluster namespace. - MountpointS3PodAttachment CRD for Mount Pod sharing — multiple workloads on the same node with the same bucket × auth × mount-options share one Mount Pod. - Pluggable credential provider interface (pkg/driver/node/credentialprovider/provider.go).

Everest-specific additions: - authenticationSource: secret — third credential provider for lakeFS-issued access keys delivered via the standard CSI nodePublishSecretRef mechanism. Required because the lakeFS S3 gateway authenticates against its own access-key DB; STS-issued AWS credentials (what upstream's driver/pod modes produce) aren't currently validated by the gateway. - Renamed all customer-facing identifiers: CSI driver name s3.csi.aws.com → csi.everest.lakefs.io, Helm chart aws-mountpoint-s3-csi-driver → everest-lakefs-csi-driver, binaries aws-s3-csi-{driver,controller,mounter} → everest-csi-{driver,controller,mounter}, Mount Pod namespace mount-s3 → everest-lakefs-csi, PriorityClasses mount-s3-* → everest-lakefs-csi-*. - Preserved error propagation: NodePublishVolume preserves the gRPC status code from the underlying mounter error instead of unconditionally wrapping as Internal, so InvalidArgument from configuration errors reaches kubelet correctly. - CI: lint + unit tests + controller envtest matrix (K8s 1.30-1.35) on every PR, with both Ginkgo-level and workflow-level retry to absorb known upstream test flakes.

  • treeverse/lakeFS-Enterprise#2533 — S3 gateway returned IsTruncated=true without NextContinuationToken when max-keys=0, violating the AWS S3 contract. Strict clients (mount-s3) rejected the response. Fix: set IsTruncated=false when caller requested zero results. The bug surfaced once V2 put mount-s3 directly in front of the lakeFS S3 gateway.

Docker

docker pull treeverse/everest-lakefs-csi-driver:1.2.0

Verify the signature (optional)

Requires Cosign:

cosign verify treeverse/everest-lakefs-csi-driver:1.2.0 \
    --certificate-identity-regexp='^https://github\.com/treeverse/everest\-lakefs\-csi\-driver/\.github/workflows/' \
    --certificate-oidc-issuer='https://token.actions.githubusercontent.com'
Expected output 
Verification for index.docker.io/treeverse/everest-lakefs-csi-driver:1.2.0 --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The code-signing certificate was verified using trusted certificate authority certificates