Red Hat Advanced Cluster Security, priced across the secured fleet.
Red Hat Advanced Cluster Security is the productised StackRox security platform, packaged as a Red Hat subscription that secures OpenShift clusters and any conformant Kubernetes cluster reachable from the ACS central instance. The pricing reads per worker core across every secured cluster in 2026, and the line is most often signed as a separate ACS subscription, inside the OpenShift Plus bundle on the bundle clusters, or as a hybrid where some clusters carry ACS through the bundle and others carry it standalone. The reading at the renewal table turns on which clusters in the fleet are actually under active enforcement rather than on the count of clusters that have the secured cluster services installed.
ACS as a productised StackRox, across many Kubernetes distributions.
Red Hat Advanced Cluster Security is the productised release of the StackRox security platform, acquired by Red Hat in 2021 and integrated as the security tier of the OpenShift portfolio. The product secures workloads across OpenShift clusters and across conformant Kubernetes distributions, including Amazon EKS, Azure AKS, Google GKE, and on premises Kubernetes installations1. The central instance runs on a designated cluster and connects to secured cluster services that install on each managed cluster.
The pricing reading in 2026 is that ACS is licensed per worker core across the secured cluster fleet2. The central instance carries no separate per cluster charge in the published model; the line accrues on the secured cluster cores. A buyer who secures three clusters of forty cores each carries the ACS line on one hundred and twenty worker cores. A buyer who secures fifteen clusters of forty cores each carries the line on six hundred.
The cross distribution nature of the product matters at the renewal table because ACS often secures clusters that are not OpenShift. A buyer who runs ACS to secure two OpenShift clusters and four EKS clusters carries the ACS line on the worker cores across all six clusters. The non OpenShift clusters do not avoid the ACS line by virtue of running on a different Kubernetes distribution; they carry the secured cluster services and they consume the ACS attribution.
Bundle membership, and the hybrid posture.
ACS sits inside the OpenShift Plus bundle on the bundle clusters and is sold standalone outside the bundle3. The bundle membership produces the central renewal lever for buyers running ACS at scale. Where the cluster fleet is bundled, ACS is part of the bundle line and the per core attribution is absorbed inside the bundle pricing. Where the cluster fleet is standalone OpenShift, ACS is a separate per core line on top of the platform line. Where some clusters are bundled and others standalone, the buyer has a hybrid posture that benefits from explicit cluster scoping in the contract record.
The hybrid posture is common at scale because OpenShift Plus tends to make sense on certain cluster profiles and not on others. A bundle is favourable on clusters that consume multiple OpenShift Plus products at the same time and unfavourable on clusters that use only one or two of the bundled products. A buyer who bundles the right clusters and runs standalone on the others reads a lower aggregate cost than a buyer who bundles the entire fleet.
The reading at signature should produce a cluster by cluster decomposition that lists each cluster, the OpenShift Plus components active on the cluster, the realistic per core list price under bundle versus standalone, and the net reading for each cluster. A renewal negotiation in the ninety days before signature produces the decomposition that the contract scope needs.
Secured cluster services installed, but not enforced.
The most common exposure pattern across ACS engagements is the cluster where secured cluster services are installed but ACS policies are not actively enforced. A platform team installs the secured cluster services on every cluster in the fleet as part of a standard cluster bootstrap, intends to roll out enforcement progressively, and reaches enforcement on a minority of clusters across the contract term. The audit reads the secured cluster services installed across the fleet and the ACS line on every secured cluster.
The defence at audit turns on the distinction between installation and enforcement. ACS policies that are not enforced on a cluster, scanners that are not active, and admission controllers that are not configured produce a different reading than a cluster under active enforcement. The buyer who can document the enforcement state on every cluster, and demonstrate that the line carries only on clusters under active enforcement, reads the line at a smaller scope than the install footprint suggests.
The mitigation at signature is to name in the contract record which clusters are under active ACS enforcement, decouple the ACS attribution from the cluster footprint that has the operator installed for observation only, and refresh the enforcement scope annually. The discipline does not require the buyer to suppress observation across the fleet. It requires the contract scope to reflect the operational reality.
Three counting traps on the ACS fleet.
Three counting traps produce most of the exposure observed across ACS engagements in the trailing twelve months.
The first trap is the installed but unenforced cluster described in section three4. The secured cluster services are present and the audit reads the line across every cluster with the services installed. The mitigation is the enforcement state inventory and a contract scope that names the enforced fleet.
The second trap is the EKS, AKS, or GKE cluster that joined the secured fleet without an explicit reading of the cross distribution implication. The non OpenShift cluster carries the ACS line on its worker cores even though it does not carry the OpenShift platform line. A buyer who scoped ACS against the OpenShift estate and added the hyperscaler Kubernetes clusters mid term reads the ACS line at a larger scope than the original signature.
The third trap is the hybrid posture without a documented decomposition. A buyer with some clusters in the bundle and others standalone, without a written cluster by cluster reading, signs a renewal at the bundle list or the standalone list across the wrong cluster set. The decomposition at signature tends to surface a five to fifteen percent saving against the unstructured posture, recurring annually across the term.
| Pattern | Frequency | Reading |
|---|---|---|
| Enforcement scope matches secured fleet | 4 of 12 | Pays |
| Hybrid bundle and standalone with decomposition | 3 of 12 | Pays |
| Secured cluster services installed, not enforced | 3 of 12 | Traps |
| Hyperscaler Kubernetes joined mid term | 1 of 12 | Traps |
| Hybrid posture without documented decomposition | 1 of 12 | Traps |
Reading the ACS line at the renewal.
ACS is read per worker core across the secured cluster fleet. The reading at signature should reflect the clusters under active enforcement, the cross distribution scope, and the bundle posture on each cluster. The buyer who signs against the install footprint pays the line on clusters that do not need the line; the buyer who signs against the enforced fleet pays for the security posture that the operational team actually delivers.
The discipline at signature sets four protections that hold across the term. The cluster fleet under active ACS enforcement is named in the contract record. The cross distribution scope, where applicable, is enumerated cluster by cluster. The bundle versus standalone decomposition is documented and refreshed annually. A quarterly enforcement state inventory captures cluster level policy state, scanner activity, and admission controller configuration so the audit notice arrives against a record the buyer can produce on demand.
For the broader cross product reading, see the OpenShift practice hub, the GitOps read for ACS policy distribution patterns, the Service Mesh read on the same clusters, the sandboxed containers entitlement when isolation and ACS run together, and the financial services audit posture where ACS often carries the regulator facing control attestation. For the engagement protocol, see contact.
Notes & references
- 1. Red Hat Advanced Cluster Security product page and pricing notes, accessed across 2025 and 2026. The product is the Red Hat productised release of StackRox, acquired by Red Hat in 2021 and integrated as the security tier of the OpenShift portfolio.
- 2. ACS pricing in 2026 reads per worker core across the secured cluster fleet. The central instance carries no separate per cluster charge; the line accrues on the secured cluster cores.
- 3. ACS sits inside the OpenShift Plus bundle on the bundle clusters and is sold standalone outside the bundle. Hybrid postures, where some clusters carry ACS inside the bundle and others standalone, are common at scale.
- 4. Practice observation across twelve ACS engagements settled in the trailing twelve months. The most common exposure pattern is secured cluster services installed across the fleet without active enforcement on the majority of those clusters.
- 5. Concession bands and trailing twelve month figures refer to the practice observation across signed contracts. The eighty two percent audit exposure reduction in marginalia is the trailing twelve month average across defenses settled.
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.