Container storage interface, where the entitlement crosses.
The container storage interface specification, CSI, gives every storage vendor a uniform integration into Red Hat OpenShift. The crossover between the OpenShift entitlement and the third party storage entitlement is structurally clean and commercially uneven. The cluster carries the OpenShift line on worker cores. The storage vendor carries its own line on capacity, array count, or namespace. The buyer who reads one line and not the other underprices the storage estate at the renewal table. The buyer side discipline reads both lines against the same cluster footprint.
CSI, and what it changed.
The container storage interface specification is a stable Kubernetes contract that every storage vendor implements as a driver. The driver runs on the OpenShift cluster and translates Kubernetes persistent volume claims into the vendor's native provisioning. Pure Storage, NetApp, Dell, IBM, HPE, AWS Elastic Block Store, Azure Disk, Google Persistent Disk, and dozens of other vendors ship CSI drivers as supported integrations against Red Hat OpenShift1. The driver is the vendor's responsibility; the cluster is Red Hat's. The contractual surface between the two is the integration point that the buyer side reads at the renewal table.
The shift CSI introduced is that storage is now plug and play on Kubernetes. A buyer who deployed OpenShift in 2019 carried a small number of supported storage paths and licensed Red Hat for the integration heavy work that came with each one. A buyer in 2026 deploys OpenShift with eight or ten CSI drivers across as many storage backends and licenses Red Hat for the cluster, not for the storage integration. The Red Hat line is independent of the storage vendor count. The storage vendor lines are independent of the OpenShift line. The crossover sits at the cluster boundary.
The buyer side consequence is that the storage estate on an OpenShift cluster has more vendors and more lines than the storage estate on a comparable virtualization platform. A VMware cluster typically carried one or two storage vendors with one or two licensing constructs. An OpenShift cluster routinely carries four to six storage vendors across CSI, with persistent volume provisioning, snapshot orchestration, and disaster recovery handled by different vendors on the same cluster. The audit notice that arrives against the OpenShift cluster reads the Red Hat line. The audit notice that arrives against the storage estate reads four to six other lines.
The OpenShift side of the line.
The Red Hat OpenShift entitlement on a cluster that uses CSI drivers is the standard per core line on worker nodes, with the control plane exclusion and the hyperthreading convention as documented across the OpenShift practice. The CSI driver itself does not change the line, because the driver runs as a pod on the cluster and consumes the cluster's compute, not its licensing entitlement. A buyer who adds three CSI drivers to a cluster adds three pods to the cluster manifest; the cluster core count does not change.
Two clarifications matter at the renewal table. The first is that operator delivered CSI drivers, including the ones distributed through the Red Hat operator catalogue, are not Red Hat licensed software in their own right unless they are explicitly part of a Red Hat product line. The operator is a packaging mechanism; the underlying driver carries its vendor's licensing. The second is that OpenShift Data Foundation, which is built on Ceph and ships as a Red Hat product, is its own licensed line on top of the OpenShift base. A cluster that runs ODF carries the OpenShift core line and the ODF line; a cluster that runs a third party CSI driver carries the OpenShift core line and the third party vendor line. The structure is symmetric, the prices are not2.
The third clarification is the cluster scope where CSI drivers are installed. Some CSI drivers are cluster scoped operators that touch every node in the cluster, including infrastructure nodes. Others are namespace scoped and only touch the namespaces where they are deployed. The audit posture on the OpenShift side is unaffected by either pattern; the cluster line is the cluster line. The audit posture on the vendor side often is affected, because the vendor licensing sometimes counts namespaces, sometimes counts clusters, and sometimes counts arrays attached. For the cross product reading on OpenShift Data Foundation, see ODF pricing.
The vendor side of the line.
Third party storage vendors price their CSI integrated software on several conventions. Per terabyte of provisioned capacity is the most common. Per array attached to the cluster is the second. Per namespace or per cluster covered by the driver is the third. Some vendors price the driver itself as free and price the array hardware and maintenance separately, with the driver included as part of the support contract. Others price the driver as a software line of its own, with separate maintenance.
The buyer side reading depends on which convention the vendor uses, because each convention rewards a different deployment pattern. Per terabyte rewards thin provisioning and lean snapshots and punishes capacity overprovisioning. Per array rewards consolidation onto fewer arrays and punishes the spread of small arrays across business units. Per namespace rewards namespace consolidation and punishes the proliferation of single application namespaces. A cluster that grew through additive deployment over three years often carries a vendor line that does not match the actual storage consumption profile.
The vendor side audit surface is independent of Red Hat's. A storage vendor audit on a cluster that uses CSI drivers reads the vendor's license metric against the cluster's consumption. The reading does not involve Red Hat directly and does not credit Red Hat entitlements as offsetting the vendor line. The buyer who renews the OpenShift line carefully and does not renew the storage vendor lines carefully signs an unbalanced contract estate. The total storage cost on the cluster is the sum of the OpenShift line, the optional ODF or Ceph line, and every third party storage line attached through CSI.
Crossover patterns the practice sees.
Three crossover patterns produce most of the contractual friction observed across OpenShift storage estates in the trailing twelve months. The patterns are independent of vendor and reflect the structural relationship between the OpenShift line and the storage line on the same cluster.
The first pattern is ODF plus third party CSI on the same cluster. The buyer purchases ODF as part of the OpenShift Plus bundle and also runs a third party CSI driver against an external storage array for specific workloads. Both lines are read against the same cluster footprint, and the buyer pays for two storage backends on the same cluster. The reading at the renewal table is whether the third party line can be retired in favour of ODF, whether ODF can be retired in favour of the third party line, or whether the two backends serve genuinely separate workload categories and both are warranted.
The second pattern is third party CSI only, without ODF. The buyer runs OpenShift Container Platform as a standalone line, with no ODF or Ceph from Red Hat, and provides all persistent volumes through third party CSI drivers. The OpenShift line is clean on its own terms. The storage estate is whatever the third party vendors have priced, and the buyer carries the full vendor exposure across as many vendors as the cluster integrates. The reading is whether the storage vendor count can be consolidated.
The third pattern is migration in flight. The buyer is moving from one storage vendor to another and runs both CSI drivers on the cluster during the transition. The OpenShift line is unchanged. The two vendor lines run concurrently for the duration of the migration, and both vendors invoice for the same cluster during the overlap window. The reading at the renewal table is whether the vendor that is being retired can be downsized mid term, and whether the vendor that is being introduced can be backloaded.
| Item | Frequency | Reading |
|---|---|---|
| ODF plus third party CSI on same cluster | 4 of 11 | Both lines reviewed |
| Third party CSI only | 5 of 11 | Vendor consolidation reviewed |
| Migration with overlapping drivers | 2 of 11 | Vendor sequencing reviewed |
Reading both lines against the cluster.
The discipline at the renewal table reads the OpenShift line and every storage line against the same cluster inventory. The cluster inventory documents which CSI drivers are installed, which namespaces they serve, which arrays they connect to, and which workloads consume their persistent volumes. The inventory is the source of truth that both the Red Hat audit and the vendor audit read against, and the buyer who can produce it controls the conversation in both directions.
The inventory also exposes the consolidation opportunities that neither audit conversation surfaces. A cluster that uses three CSI drivers for three storage vendors on workloads that could share a single backend carries three vendor lines for what could be one. A cluster that runs ODF on a small footprint and a third party vendor on the larger footprint may benefit from a different split. A subscription assessment across the OpenShift estate that includes the storage line is the engagement that produces the inventory and the consolidation reading together.
The buyer side posture at the audit notice on the OpenShift line keeps the conversation on the OpenShift line. The storage vendor lines are separate audits, conducted by the storage vendor, with their own response windows and their own settlement mechanics. An audit defense on the OpenShift side does not relieve the storage vendor side and does not invite it. The discipline is to keep the two conversations separate at audit and bring them together at the renewal table, where the consolidation conversation belongs. For the storage practice hub, see storage and virtualization. For the engagement protocol, see contact.
Notes & references
- 1. Container storage interface specification, version 1.x, as adopted across the Kubernetes ecosystem. Red Hat OpenShift ships with a supported CSI plumbing layer, and storage vendors ship CSI drivers as supported integrations with explicit Red Hat OpenShift compatibility. The driver lifecycle is the vendor's; the cluster lifecycle is Red Hat's.
- 2. OpenShift Data Foundation product page and Red Hat Ceph Storage product page, accessed across 2025 and 2026. ODF is built on Ceph and shares its underlying engine with the standalone Ceph product, with different packaging, support, and entitlement structure. See the dedicated reading at OpenShift Data Foundation pricing and Red Hat Ceph Storage subscription explained.
- 3. Practice observation across eleven OpenShift storage engagements settled between July 2025 and April 2026 where CSI driver crossover was a material item. The vendor consolidation reading recovered storage estate cost in nine of the eleven cases. The recovered scope was on the vendor lines, not on the Red Hat line.
- 4. Concession bands referenced throughout reflect the practice's observation across signed contracts in the trailing twelve months. Storage vendor lines are not Red Hat's; the practice reads them at the renewal table because they sit on the same cluster as the Red Hat line.
- 5. All figures are net of fees and verified against signed contract deltas. The eighty two percent audit exposure reduction referenced in practice marginalia is the trailing twelve month average across Red Hat defenses settled, not a storage vendor figure.
Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.