Release Notes

v0.1.29

Release date: 2026-11-05

NetappStorageClass and NetappStorageConnection record Kubernetes Events when their Ready condition changes, the StorageClasses of the module are guarded against direct changes and foreign StorageClasses are no longer touched, and the module images no longer carry the reported golang.org/x/net vulnerabilities.

Highlights

Changes in this release:

• NetappStorageClass and NetappStorageConnection record a Warning Event when Ready turns False and a Normal one when it turns True again, so kubectl describe shows when a resource broke and when it recovered.
• The module now has a validating webhook: it rejects a NetappStorageClass named after a StorageClass of another provisioner and any direct change to the StorageClasses of the module other than their annotations.
• golang.org/x/net is updated to v0.62.0 in all module binaries, which clears CVE-2026-78661 and CVE-2026-97045.

New features

This release adds:

• NetappStorageClass and NetappStorageConnection now record a Kubernetes Event when their Ready condition changes status or reason: a Warning when it turns False, a Normal one when it turns True again. The reason of the Event is the reason of the condition, ReconcileFailed or Reconciled, so kubectl describe shows when a resource broke and when it recovered. A reconcile pass that changes nothing records no Event. Both kinds are cluster-scoped, so their Events are in the default namespace, and the controller is granted the right to create them there.

Improvements

This release improves:

• A NetappStorageClass can no longer be created under the name of a StorageClass that belongs to another provisioner. The module names its StorageClass after the NetappStorageClass, and such a resource used to be admitted; a validating webhook, the module’s first, now rejects it at creation and names the StorageClass that holds the name and its provisioner. The webhook runs as a container in the controller pod.
• The StorageClasses of the module are now protected by the storage.deckhouse.io/netapp-storage-class-controller finalizer, as in the other storage modules. The controller puts it on the StorageClasses it creates and on the existing ones, and removes it when it deletes a StorageClass together with its NetappStorageClass or NetappStorageConnection; a StorageClass deleted directly stays in Terminating until its NetappStorageClass is deleted.

Fixes

This release fixes:

• The controller no longer changes or deletes a StorageClass of another provisioner that has the name of a NetappStorageClass or a NetappStorageConnection. It used to overwrite the parameters, annotations and labels of such a StorageClass and to delete it together with the NetappStorageClass or the connection. Now it leaves the StorageClass as it is, the NetappStorageClass reports Ready=False with a message naming the StorageClass and its provisioner, and deleting the NetappStorageClass or the connection no longer takes the StorageClass with it.
• StorageClasses of the csi.trident.netapp.io provisioner, which the module creates from NetappStorageClass resources, are now protected from direct changes. Only the module controller can create, change or delete them; anyone else can change only their annotations, such as the default class mark. A direct change used to be accepted and left the StorageClass out of step with its NetappStorageClass. Change the NetappStorageClass instead.
• When the module is disabled, finalizers are now removed from its StorageClasses as well. The hook that removes them looked for StorageClasses of the csi.Netapp.com provisioner, which no StorageClass of the module has, instead of csi.trident.netapp.io, so a finalizer left on a StorageClass of the module kept it in Terminating once it was deleted.

Security updates

Security updates in this release:

• golang.org/x/net is updated from v0.60.0 to v0.62.0 and golang.org/x/text from v0.42.0 to v0.43.0 in the Trident binaries (trident_orchestrator, tridentctl, node_prep, syswrap), the module’s controller and hooks (go-hooks), which clears CVE-2026-78661 and CVE-2026-97045 from scans of the module images. The new webhook image is built with the same versions.

Upgrade notes

Before upgrading, note the following:

• Nothing has to be done by hand. The controller pod restarts once with the new webhooks container. On the first reconcile after the update the existing StorageClasses of the module get the storage.deckhouse.io/netapp-storage-class-controller finalizer in place, without being recreated; volumes already provisioned are not affected. From then on a StorageClass of the csi.trident.netapp.io provisioner can be created, changed (apart from its annotations) or deleted only through its NetappStorageClass, so tooling that edits such StorageClasses directly has to switch to the NetappStorageClass.

v0.1.28

Release date: 2026-10-26

Security update: the Trident binaries and the module’s controller and hooks are rebuilt against patched Go dependencies, the module’s logLevel now sets Trident’s log level, and on DKP 1.79 and later the module ships the SecurityPolicyException objects the CSI pods need.

Highlights

Changes in this release:

• The Trident binaries, the module’s controller and hooks are rebuilt against patched Go dependencies, closing CVE-2026-78669 (HIGH) and CVE-2026-56851 (HIGH) among others.
• Trident no longer logs at debug regardless of the module settings: the controller and node containers take their log level from logLevel.
• On DKP 1.79 and later, where the Pod Security Standards in system namespaces deny instead of warn, the module ships a SecurityPolicyException for the CSI controller and CSI node pods, so both keep starting.

New features

This release adds:

• The module ships a SecurityPolicyException for the CSI controller and CSI node pods. The controller’s exception allows the host network, on which Trident’s REST port 4257 is bound; the node’s allows the privileged node plugin running as root with privilege escalation, the host network and PID namespaces and the hostPath volumes it mounts. The objects are created only when the admission-policy-engine CRDs are present, so earlier DKP versions are unaffected. The CSI controller pod no longer sets UID and GID 0 at the pod level; its containers have run as UID 64535 anyway, so nothing changes for them.

Fixes

This release fixes:

• The logLevel setting of the module now reaches Trident: the controller and node containers get --log_level from it (error, warn, info, debug, trace; info when unset) instead of being started with --log_level=debug and -debug.

Security updates

Security updates in this release:

• The Trident binaries (trident_orchestrator, tridentctl, node_prep, syswrap), the module’s controller and hooks (go-hooks) are rebuilt against patched Go dependencies, closing CVE-2026-78669, CVE-2026-78659, CVE-2026-78660, CVE-2026-78663, CVE-2026-97032, CVE-2026-56851 and, in go-hooks, CVE-2026-63209. go-hooks no longer contains docker/distribution, which carried CVE-2026-85747 without a fixed release.

v0.1.27

Release date: 2026-10-01

The iSCSI stack on a node now always comes from the module’s own package and never from the node’s repositories, Trident is updated to v26.06.1, and on DKP 1.78 and later the module’s access roles follow the capability/scope RBACv2 scheme.

Highlights

Changes in this release:

• The NodeGroupConfiguration no longer asks a node’s package manager for open-iscsi and multipath-tools: every node labelled storage.deckhouse.io/csi-netapp-node gets the module’s iscsi-tools package, so a node with no route to its repositories no longer waits out the package manager on every bashible run, and the stack no longer depends on what version the repositories carry.
• NetApp Trident is updated from v26.02.1 to v26.06.1.
• On DKP 1.78 and later the module grants access to NetappStorageClass and NetappStorageConnection through the capability roles d8:system-capability:csi-netapp:view and d8:system-capability:csi-netapp:edit; below 1.78 the roles stay as they were.

New features

This release adds:

• On DKP 1.78 and later the module ships the ClusterRoles d8:system-capability:csi-netapp:view (read NetappStorageClass and NetappStorageConnection) and d8:system-capability:csi-netapp:edit (create, update and delete them), labelled with rbac.deckhouse.io/kind: capability and rbac.deckhouse.io/scope: system, so that DKP aggregates them under the new RBACv2 scheme. They replace d8:manage:permission:module:csi-netapp:view and d8:manage:permission:module:csi-netapp:edit on those clusters; a cluster below 1.78 keeps the old roles unchanged.

Improvements

This release improves:

• The iSCSI stack is taken only from the module’s iscsi-tools package. Its install script decides for each pair separately — iscsiadm with iscsid, multipath with multipathd: a pair the host already has stays the host’s, and the module only enables the distribution’s unit for it; a pair the host lacks lands under /var/lib/deckhouse/sds/csi-netapp with its own unit, d8-csi-netapp-iscsid.service or d8-csi-netapp-multipathd.service. A host with open-iscsi but no multipath-tools therefore now gets a multipathd from the module, where it used to get nothing because the package stepped aside as soon as the host had an iscsiadm. The multipath configuration, the NetApp ONTAP device block, the kernel modules and the storage.deckhouse.io/csi-netapp-node-ready label are applied the same way on every node.
• A node whose own tools change after the module’s package was installed — a distribution package removed, or installed next to the module’s — gets the package installed again on the next bashible run, so the decision of which pair comes from where is made anew. It used to be made once per module version, leaving a tool the host lost missing until the next release, or a distribution daemon running next to the module’s.

Fixes

This release fixes:

• On an upgrade, the files an earlier version of the iscsi-tools package placed outside its directory — the PATH wrappers in /usr/local/sbin and the multipath plugins in /usr/lib/multipath — are no longer taken for the host’s own. An upgrade of the package dropped them from its file list, so they were never removed once the node got the distribution’s pair; they are now recognised as the package’s own, listed again and cleaned up with it.
• On CentOS and RED OS nodes, when the module regenerates an empty or placeholder initiator name in /etc/iscsi/initiatorname.iscsi, it now restarts d8-csi-netapp-iscsid.service as well as the distribution’s iscsid. A node running the module’s iscsid used to keep the previous initiator name until the daemon was restarted by hand.

Security updates

Security updates in this release:

• In the Trident binaries golang.org/x/mod is raised from v0.38.0 to v0.40.0, closing CVE-2026-56864 and CVE-2026-56865; google.golang.org/grpc stays at v1.83.2.

Upgrade notes

Before upgrading, note the following:

• Nothing has to be done by hand on the nodes. A node that already runs the distribution’s iscsid and multipathd keeps them; a node that lacks either pair gets it from the module’s package on the next bashible run. Distribution packages are no longer installed on new nodes.
• On DKP 1.78 and later the roles d8:manage:permission:module:csi-netapp:view and d8:manage:permission:module:csi-netapp:edit are replaced by d8:system-capability:csi-netapp:view and d8:system-capability:csi-netapp:edit. Access granted through DKP role aggregation carries over; a ClusterRoleBinding that references an old role by name has to be pointed at the new one.

Docs

Documentation changes:

• The module’s configuration page describes where open-iscsi and multipath-tools on a node come from: the per-pair decision, what the module places on the host and where, and how to tell from a node which pair came from where.
• The Russian reference of NetappStorageClass and NetappStorageConnection now covers the status.conditions fields, and NetappStorageClass.spec carries a description in both languages.

Dependencies

Dependency updates:

• NetApp Trident: 26.02.1 → 26.06.1 (changelog)
  • Adds the tridentvolumemoves.trident.netapp.io CRD, which the module installs and grants Trident access to. The module’s patch that runs multipath and multipathd on the host through nsenter now also covers multipathd -kadd path, multipathd -kfail path, the iSCSI multipath -r reload and the FCP find_multipaths check.

v0.1.26

Release date: 2026-09-24

Security update: the Trident binaries and the module’s hooks are rebuilt against patched grpc and x/crypto.

Highlights

Changes in this release:

• google.golang.org/grpc is raised from v1.82.1 to v1.83.2 in trident_orchestrator and node_prep, 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 trident_orchestrator and node_prep, 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 trident_orchestrator, node_prep 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.

v0.1.25

Release date: 2026-09-09

A node whose repositories cannot provide the iSCSI stack now gets it from the module’s own package image, a NetappStorageConnection decides how much of a volume is kept for the superuser — nothing, by default, where ext4 used to keep 5% — and the module controller exports metrics and takes its log level from a module setting.

Highlights

Changes in this release:

• The module installs open-iscsi and multipath-tools from its own package image when a node’s repositories cannot provide them. Such a node used to be left as it was, and every attach on it failed with nsenter: failed to execute iscsiadm.
• A NetappStorageConnection can ask for a share of the filesystem to be kept for the superuser — the classic ext4 reserve — with the storage.deckhouse.io/ext4-reserved-percent annotation. Volumes are formatted with no reserve unless it is asked for, where before every ext4 volume kept ext4’s default 5% for root.
• A restart of node-driver-registrar no longer wedges the node plugin. That deadlock left one or two nodes of a cluster without csi.trident.netapp.io in their CSINode, unable to attach a volume, while their siblings were fine.

New features

This release adds:

• A node whose package repositories cannot install open-iscsi and multipath-tools (iscsi-initiator-utils and device-mapper-multipath on RPM distributions) now gets them from the module’s own iscsi-tools package image: the payload lands under /var/lib/deckhouse/sds/csi-netapp, every binary runs against its own library path, and two units come up for the daemons, d8-csi-netapp-iscsid.service and d8-csi-netapp-multipathd.service. The distribution’s packages stay the preferred path and the two never mix — a node that has an iscsiadm of its own keeps everything of its own, because a client of one version does not speak to an iscsid of another. Everything the NodeGroupConfiguration does after the install runs on such a node exactly as on any other: the find_multipaths no override, the NetApp ONTAP device block, the kernel modules and the storage.deckhouse.io/csi-netapp-node-ready label the CSI node waits for.
• storage.deckhouse.io/ext4-reserved-percent on a NetappStorageConnection sets the percentage of the filesystem kept for the superuser: a whole number from 0 to 50, default 0. Note the resource — unlike the other storage modules of the fleet, the value is set per connection and not per StorageClass, because Trident keeps the mkfs options on the backend, so it applies to every StorageClass served by that connection. The reserve applies to volumes created afterwards; an existing filesystem keeps the reserve it was created with. An invalid value leaves the NetappStorageConnection with Ready=False and the reason in its status, instead of breaking volume creation later.
• The module setting logLevel sets how much the controller logs: ERROR, WARN, INFO, DEBUG or TRACE. It is INFO by default, where the controller used to log at DEBUG with no way to change it.
• The controller exports metrics and a PodMonitor puts them in front of the cluster’s main Prometheus: what controller-runtime reports for every controller of the module — reconcile counts and durations, workqueue depth, client-go latency. The controller binds its metrics endpoint on 127.0.0.1, and a kube-rbac-proxy in the same pod authorises every scrape.

Improvements

This release improves:

• 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, so the console shows the notes in the language of the reader; the releases cut before this one keep the previous flat format and render on the same page exactly as before.

Fixes

This release fixes:

• The formatOptions the module writes onto a Trident backend reach Trident at all now. They used to sit at the top level of the TridentBackendConfig spec, where the driver has no such field: Trident reads them from under defaults, so a value at the top level was parsed into nothing and dropped without a word. The -E nodiscard the module has always asked for was therefore never applied, and every volume was formatted with mkfs discarding the whole device.
• A restart of node-driver-registrar no longer takes the CSI driver with it. The csi-node liveness probe watched a port the registrar serves but was attached to the driver container, and the two deadlocked: the registrar exits by design when registration fails, its port goes with it, the probe kills the driver, the CSI socket disappears, and the restarted registrar can no longer reach it. A node came up with the node plugin wedged — a dozen restarts and no csi.trident.netapp.io in its CSINode, so no volume could be attached there — while other nodes of the same cluster were fine. The probe now sits on the container that serves it.
• A change to the multipath configuration no longer fails on a node where multipathd is enabled but not started: such a unit refuses a reload outright, and the node configuration step then retried forever, leaving the module’s find_multipaths no unapplied — which is what Trident’s own pre-flight checks read before they agree to stage a volume. The handler restarts the unit when it cannot reload it, and covers the module’s own d8-csi-netapp-multipathd.service as well.
• 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:

• Volumes created after the upgrade carry no reserve for the superuser, so the whole volume is available to the workload; a filesystem that already exists keeps the 5% it was created with. Nothing has to be done by hand — the controller rewrites the TridentBackendConfig of every connection on its own, and existing volumes and PVCs are not affected.
• The controller logs at INFO after the upgrade, where it used to log at DEBUG unconditionally. Set settings.logLevel to DEBUG or TRACE to get the previous verbosity back.
• A node whose csi-node pod was stuck in the registration deadlock recovers as the DaemonSet rolls out the fixed pod — no pod has to be deleted by hand.

Docs

Documentation changes:

• The module’s configuration page describes both ways the iSCSI stack reaches a node — the node’s own repositories and the module’s package image: which path is preferred and why, what the fallback puts on the node and where, how to tell from a node which of the two it took, and the two arrangements that stay invisible until a volume fails to mount.
• The same page describes the share of a volume kept for the superuser: the annotation, that it belongs on the connection rather than on a StorageClass, the range of values, and that the reserve applies only to volumes created afterwards.

v0.1.24

• Fix: the release image is no longer built from cache with an outdated changelog.yaml — git-mapping dependencies are bound to the install stage, where the file is copied
• Update base images to v2.1.4
• Internal build changes for the module

v0.1.23

• Bugfix: a successful NFS mount is no longer reported as a failure - the image now ships /etc/mtab (a symlink to /proc/self/mounts), without which mount returned exit code 16
• Bugfix: the controller is granted patch on events instead of list - a repeated event write is no longer denied by RBAC
• CVE fixes
• Base images updated to v2.1.2, Go to 1.26.6 and lib-helm to 1.72.14

v0.1.22

• Bugfix: the secret with credentials is created before the TridentBackendConfig that references it, otherwise Trident rejected the backend with the error “backend credentials not found”; When deleting, the order is reversed. At the same time, an early exit from reconcile was eliminated, in which Ready=True was published before the creation of the secret, StorageClass and VolumeSnapshotClass
• Update base images to v1.3.25, Go 1.26.5 and lib-helm to 1.72.13
• Internal changes: work with conditions has been transferred to the general library

v0.1.21

• The snapshot-controller module is no longer a required dependency: VolumeSnapshotClass is created only if the snapshot.storage.k8s.io CRD is present, otherwise NetappStorageClass and NetappStorageConnection are processed without the snapshot part
• Update base images, Go 1.26.5 and lib-helm to 1.72.12
• Fixed a vulnerability in gRPC (GHSA-hrxh-6v49-42gf)
• Internal changes in module assembly

v0.1.20

• Fix: Deckhouse registry access secrets are now limited to the active image source
• Update base images, Go 1.26.5 and lib-helm to 1.72.10
• Internal changes in module assembly

v0.1.19

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

v0.1.18

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

v0.1.17

• Internal changes in the structure and assembly of the module

v0.1.16

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

v0.1.15

• Corrections to the module structure

v0.1.14

• csi-netapp has been transferred to the distroless build of Trident (host binaries via nsenter), the node plugin’s resistance to restarts has been increased
• Added status.conditions and printer columns to CRD NetappStorageClass and NetappStorageConnection
• Added NodeGroupConfiguration for installing iscsi/multipath on Altlinux, RedOS-like and Ubuntu-like
• Fixed vulnerabilities (CVE) in Trident binary dependencies

v0.1.13

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

v0.1.12

• Added missing mount points in the csi-netapp distroless image
• Update base images, Go and lib-helm (CVE fix)
• Clarifications in the documentation

v0.1.11

• 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)
• Fixes in working with snapshots
• Changes in CSI work

v0.1.10

• Fix HA-mode, now it works correctly

v0.1.9

• Updated base images versions
• Fixes in docs

v0.1.8

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

v0.1.7

• Added release notes

v0.1.6

• Added additional mountings for containerd v2 support

v0.1.5

• Added information about snapshot-controller requirement for module operation
• Added readonlyRootFilesystem for enhanced security

v0.1.4

• CVE fixes

v0.1.3

• Added fixes for containerd v2 support
• Added dependency on snapshot-controller

v0.1.1

• CVE closure
• Module refactoring, fixed manifest errors
• Documentation improvements