Release Notes

v0.2.25

Release date: 2026-10-01

Volumes stay mounted when the csi-node Pod restarts, because geesefs now runs as a systemd service of the node, and a deleted S3StorageClass keeps its credentials until its PersistentVolumes are gone.

Highlights

Changes in this release:

• geesefs runs as a transient systemd service of the node (geesefs-<volume>.service) instead of inside the csi-node container, so a restart, eviction or update of csi-node no longer leaves the volumes of that node answering “Transport endpoint is not connected”.
• Deleting an S3StorageClass removes its StorageClass at once but keeps the Secret csi-s3-<name> in d8-csi-s3 and the S3StorageClass itself until every PersistentVolume that refers to the Secret is deleted, so those volumes can still be mounted and their buckets are removed on deletion.

Improvements

This release improves:

• On DKP 1.78 and later the module’s access roles follow the capability/scope RBACv2 scheme: d8:system-capability:csi-s3:view grants read-only access to S3StorageClass, and d8:system-capability:csi-s3:edit grants create, update and delete. They replace d8:manage:permission:module:csi-s3:view and d8:manage:permission:module:csi-s3:edit there and are still aggregated into the storage viewer and manager roles. Below DKP 1.78 the previous roles are rendered unchanged.

Fixes

This release fixes:

• geesefs was started inside the csi-node container and died with it on every restart, eviction (including VPA in-place updates) or update of the Pod, leaving each volume mounted on that node unreachable until it was unstaged. The driver now starts geesefs through the node’s systemd, which keeps it running independently of the Pod. The S3 credentials of the service are passed in a root-only file under /run/csi-s3 instead of the unit’s Environment property, which any node user could read with systemctl show. The certificates from customCACertificates are copied to the node so that geesefs still trusts them, and geesefs resolves the endpoint through the cluster DNS of the csi-node Pod, so an endpointUrl given as a Service name (https://<service>.<namespace>.svc) keeps working although the node’s own resolver does not know the cluster domain. A dead FUSE mount left on the node is unmounted in NodeStageVolume, NodePublishVolume and NodeUnstageVolume instead of failing the operation.
• Deleting an S3StorageClass deleted the Secret csi-s3-<name> and removed the finalizer immediately, even while PersistentVolumes of the class existed. external-provisioner reads the deletion credentials from that Secret, so these volumes stayed Released for good and their buckets were never removed. The controller now deletes the StorageClass right away, which stops new provisioning, and keeps the Secret and the finalizer while any PersistentVolume of the driver refers to the Secret, whatever its reclaim policy. Meanwhile the Ready condition is False with the reason Deleting, and its message lists the PersistentVolumes it is waiting for. The controller now has read access to persistentvolumes.
• customCACertificates accepts each certificate as PEM text, as the documentation says, as well as Base64-encoded PEM. Before, only Base64 worked: a PEM value was rejected by the ModuleConfig webhook, or, in a ModuleConfig applied before the module was installed, ended up in the csi-s3-custom-ca ConfigMap as an error text instead of the certificate, and every request to the endpoint failed with x509: certificate signed by unknown authority. Values already set in Base64 keep working.

Upgrade notes

Before upgrading, note the following:

• Updating the module restarts the csi-node Pods. Volumes mounted before the update are still served by geesefs processes inside the old containers, and those stop with them: on each node, Pods that use csi-s3 volumes get “Transport endpoint is not connected” until they are recreated. Recreate such Pods after the update. Their volumes are then mounted through the node’s systemd, and later csi-node restarts no longer affect them.
• On DKP 1.78 and later the ClusterRoles d8:manage:permission:module:csi-s3:view and d8:manage:permission:module:csi-s3:edit are replaced by d8:system-capability:csi-s3:view and d8:system-capability:csi-s3:edit. Access granted through the storage viewer and manager roles is not affected. A RoleBinding or ClusterRoleBinding that refers to one of the old names directly has to be switched to the new name.
• An S3StorageClass deleted while it still has PersistentVolumes now stays in the cluster with Ready=False and reason Deleting until they are gone. Delete the PVCs of the listed volumes. A PersistentVolume with the Retain reclaim policy is never deleted automatically: delete the PersistentVolume object yourself; its data stays in the bucket.

Docs

Documentation changes:

• The FAQ explains why a deleted S3StorageClass stays in the cluster, how to read the list of PersistentVolumes it is waiting for, and what to do with volumes that have the Retain reclaim policy.

Dependencies

Dependency updates:

• geesefs: 0.43.7 → 0.43.9 (changelog)
  • The geesefs FUSE file system used to mount the volumes is updated. The dependency patches are combined into one and still raise grpc, x/crypto and OpenTelemetry to versions that close the known CVEs.

v0.2.24

Release date: 2026-09-24

Security update: the CSI driver, geesefs and the module’s hooks are rebuilt against patched grpc, x/crypto and OpenTelemetry.

Highlights

Changes in this release:

• google.golang.org/grpc is raised from v1.82.1 to v1.83.2 in the CSI driver (s3driver) and geesefs, closing CVE-2026-84303, CVE-2026-84304 and CVE-2026-84445.

Security updates

Security updates in this release:

• google.golang.org/grpc is raised from v1.82.1 to v1.83.2 in the CSI driver (s3driver) and geesefs, closing CVE-2026-84303, CVE-2026-84304 and CVE-2026-84445.
• golang.org/x/crypto is raised from v0.53.0 to v0.57.0 in the CSI driver (s3driver), geesefs and the module’s hooks (go-hooks), closing CVE-2026-56854 (authentication bypass by source address in x/crypto/ssh), CVE-2026-56855 and CVE-2026-78662.
• The OpenTelemetry modules (go.opentelemetry.io/otel, metric, sdk, trace) are raised from v1.44.0 to v1.45.0 in geesefs, closing CVE-2026-81870.

v0.2.23

Release date: 2026-09-15

The module logs at INFO by default instead of DEBUG, so an installation that never chose a level stops writing debug output from its controller.

Highlights

Changes in this release:

• logLevel defaults to INFO instead of DEBUG. Where the level was never set in the module configuration, the controller and its validating webhook become markedly quieter after the update; setting logLevel: DEBUG brings the previous verbosity back.

Improvements

This release improves:

• The default of logLevel in the module configuration is now INFO. The setting reaches the controller and the validating webhook that share its pod, so DEBUG as the default meant that every installation which never touched the setting ran at troubleshooting verbosity and paid for it in log volume. A logLevel stated explicitly in the ModuleConfig is honoured exactly as before, whatever it says.

Upgrade notes

Before upgrading, note the following:

• Nothing has to be done in the module configuration. Where logLevel is not set, the components come up at INFO as the controller pod rolls out with the update; where it is set, the level stays as configured. To keep the previous behaviour, set logLevel: DEBUG explicitly.

v0.2.22

Release date: 2026-09-09

The controller metrics announced in the previous release are actually collected now: the kube-rbac-proxy in front of them could not authorise a single scrape.

Highlights

Changes in this release:

• Prometheus collects the controller metrics, which it never once managed to do since they were introduced in the previous release. The kube-rbac-proxy that fronts them had no permission to create the TokenReview and SubjectAccessReview every scrape is authorised with, so it rejected all of them: up == 0 for the csi-s3-controller job and a TargetDown that never cleared.

Fixes

This release fixes:

• The kube-rbac-proxy in front of the controller metrics is bound to the d8:rbac-proxy ClusterRole now, so it can authorise a scrape. Without that binding it failed closed on every scrape, and the only symptom was an unreachable target: not one metric of the module’s controller reached Prometheus — reconcile counts and durations, workqueue depth, client-go latency, all of them — and TargetDown fired for as long as the module was installed.

Upgrade notes

Before upgrading, note the following:

• Nothing has to be done in the module configuration. A TargetDown firing for the csi-s3-controller job clears on its own once the new controller pod is running and the first scrape succeeds.

v0.2.21

Release date: 2026-09-04

The module controller now exports Prometheus metrics, scraped through the kube-rbac-proxy of its own pod, and writes structured logs; a release of the module is described in sections and in both languages.

Highlights

Changes in this release:

• Controller metrics are collected by Prometheus with no configuration: a ServiceMonitor in d8-monitoring scrapes them under the job csi-s3-controller, so reconcile counts and durations, workqueue depth and client-go latency become visible.
• The controller writes structured logs — a component name and key-value fields instead of the [main]-style prefixes — so anything that parses its log lines has to be adjusted.
• A release is described in sections — summary, highlights, new features, improvements, fixes — in English and in Russian, and the console shows the notes in the language of the reader.

New features

This release adds:

• The controller now exports metrics.

Improvements

This release improves:

• The controller logs through the shared logger of the storage modules: every line carries the component it came from and its fields as key-value pairs. settings.logLevel keeps working exactly as before (ERROR, WARN, INFO, DEBUG) — what changed is the shape of a line, not the level.
• Release notes are written per locale in .release-notes/<tag>.yaml and <tag>.ru.yaml with the sections summary, highlights, new_features, improvements, fixes, security, breaking, upgrade_notes, known_issues, docs and dependencies. Both locales reach the cluster; the releases cut before this one keep the previous flat format and render on the same page exactly as before.

Fixes

This release fixes:

• A release tag with no release notes used to publish an empty changelog.yaml, leaving ModuleRelease.spec.changelog blank with a green build. Such a tag now fails the build.

Upgrade notes

Before upgrading, note the following:

• Nothing has to be done in the module configuration.

v0.2.20

• Bugfix: the controller is granted patch on events instead of list - a repeated event write is no longer denied by RBAC
• Base images updated to v2.1.2, Go to 1.26.6 and lib-helm to 1.72.14

v0.2.19

• S3StorageClass publishes status.conditions and status.observedGeneration, added Ready column. The status.phase field retains the same set of values, but is now calculated from the Ready condition
• Update base images to v1.3.25, Go 1.26.5 and lib-helm to 1.72.13

v0.2.18

• Update base images, Go 1.26.5 and lib-helm to 1.72.12
• Fixed vulnerabilities in third-party dependencies
• Internal changes in module assembly and CI, added a set of e2e tests

v0.2.17

• Update base images, Go 1.26.5 and lib-helm to 1.72.9
• Internal changes in module assembly

v0.2.16

• Fixed the formation of the registry access secret (deckhouse-registry): now it only includes authorization data for the active image source
• Updating container-base images to v1.1.8, Go 1.26.4 and lib-helm to 1.72.4

v0.2.15

• When forwarding labels from S3StorageClass to StorageClass, labels with specified ignored prefixes are now excluded
• Update base images and lib-helm to 1.72.0

v0.2.14

• Labels from S3StorageClass are now forwarded to the managed StorageClass Kubernetes
• Update base images, Go 1.25.10 and lib-helm 1.71.12

v0.2.13

• Added dataNodes.nodeSelector parameter to control the placement of DaemonSet csi-node; an empty object is rejected by the validating webhook
• Added controller that synchronizes nodeSelector value with DaemonSet csi-node

v0.2.12

• Internal changes in the structure and assembly of the module

v0.2.11

• Update base images, Go 1.25.10 and lib-helm 1.71.11
• Internal changes to the module assembly

v0.2.10

• Corrections to the module structure

v0.2.9

• Changes in CI: DistroPackagesProxy and env proxy in werf, improvements to CVE scans (role_name, checkout)
• Added user-authz cluster roles in templates

v0.2.8

• Added infrastructure and missing mount points for distroless images
• Update base images, Go and lib-helm (CVE fix)
• Documentation on module configuration parameters

v0.2.7

• Update base images and golang version
• Updated hooks that work when a module is removed
• Disabled Capacity request from k8s (CSI does not support issuing Capacity)
• Update version k8s-csi-s3 to 0.43.3

v0.2.6

• Reworking module manifests

v0.2.5

• Updated base images version to v0.5.46
• Updated Go version to 1.24.11
• Fixed S3StorageClass field names in documentation examples
• Fixed YAML syntax errors in FAQ examples
• Merged controller and webhooks into single deployment
• Added HA mode support for CSI controller

v0.2.4

• Updated base images versions

v0.2.3

• Updated Go version to 1.24.9
• Updated lib-helm to deckhouse_lib_helm-1.64.1

v0.2.2

• Added release notes

v0.2.1

• Added readonlyRootFilesystem for enhanced module security

v0.2.0

• Module refactoring
• Service account changed to “csi”

v0.1.5

• Minor documentation fix

v0.1.4

• Module refactoring without changing functionality for end users
• Added Deckhouse version requirements (>= 1.67)

v0.1.3

• Added support for custom CA certificates
• Updated GeeseFS to version 0.43.0