OpenShift disconnected install audit posture, on the offline cluster.
OpenShift disconnected install audit considerations in 2026 sit in a distinctive posture because the cluster operates without the upstream Red Hat telemetry channel that the connected install would otherwise feed. The mirror registry inside the air gapped boundary supplies the cluster operators, the container images, and the certificate material that the install consumes, and the cluster reports its own inventory only to internal systems on the trusted side of the boundary. The audit reads against the buyer maintained evidence record because there is no upstream telemetry to corroborate or contradict the claimed footprint; the buyer who maintains the offline inventory rigorously settles at the claimed reading, and the buyer who does not settles at the assumption the audit defaults to.
The disconnected install, and what it leaves behind.
OpenShift supports a disconnected install posture in which the cluster boots, runs, and updates without reaching the public Red Hat content network or any external internet endpoint. The install requires a mirror registry inside the air gapped boundary that holds every operator image, every container image, and every signed certificate the cluster needs. The administrator runs the oc mirror tooling on a connected workstation, pulls the required content from the Red Hat content network, transfers the mirror artefacts across the air gap, and imports the content into the offline mirror registry that the cluster install configuration points at1.
The disconnected cluster runs the standard OpenShift Container Platform without modification once the mirror registry is in place. The cluster API, the scheduling behaviour, the workload runtime, and the operational tooling are identical to the connected install. The difference sits in the telemetry channel. A connected OpenShift cluster reports its inventory to the Red Hat Insights service through the cluster wide telemeter operator; the disconnected cluster does not, because it cannot reach the upstream endpoint. The Red Hat side of the audit therefore has no upstream record of the cluster's existence beyond what the contract record names2.
The audit posture on the disconnected fleet is therefore asymmetric. The buyer holds all the cluster level evidence because the cluster reports only to internal systems. Red Hat holds the contract record and the mirror registry pull logs that the oc mirror tooling produces during content synchronisation. The audit walks the contract record against the buyer maintained inventory, and where the two agree the audit concludes; where they disagree, the buyer's record is the primary source for the reading the buyer can defend.
The mirror registry, as the upstream signal.
The mirror registry inside the air gapped boundary produces the one external signal the Red Hat side of the audit can reliably read. The oc mirror tooling that synchronises content to the mirror registry pulls authenticated content from the Red Hat content network on the connected side; those pulls are logged against the buyer's organisation account on the Red Hat content network. The audit can request the pull log and reconstruct the version history, the cluster count implied by the install image releases, and the operator catalogue scope that the buyer synchronised across the term3.
The pull log is not a cluster inventory; it is a content synchronisation history. The log indicates that the buyer pulled the OpenShift 4.16 install image and the OpenShift 4.17 install image and twelve operator catalogue releases across an eighteen month window. The log does not indicate how many clusters the buyer built from those images or how many of those operators the buyer activated. The disconnected install posture deliberately separates content synchronisation from cluster deployment, and the audit cannot reconstruct cluster level state from the synchronisation log alone.
The buyer who maintains an internal inventory that reconciles cluster builds against mirror registry pulls produces an evidence record that the audit can read confidently. The buyer who synchronises content widely as a future deployment precaution and never builds against the broader scope produces an evidence record that, absent reconciliation, looks at first reading like an oversized cluster footprint. The reconciliation is the protection.
Three audit traps on the disconnected fleet.
Three audit traps produce most of the exposure observed across disconnected install engagements in the trailing twelve months.
The first trap is the mirror registry that holds operator catalogues the cluster never activated. A buyer who synchronised the full Red Hat operator catalogue to the mirror registry as a forward looking precaution reads at the audit as carrying the entire catalogue scope across the cluster fleet, even though the operational fleet activated a small subset of those operators. The mitigation is a reconciliation record that maps operator activation across the cluster fleet against the synchronisation scope at the mirror registry, with explicit naming of operators held for future deployment but not active.
The second trap is the offline cluster count that does not match the contract record. A buyer with a disconnected programme of twenty clusters in the contract scope deploys an additional eight clusters during a project that did not flow through the standard procurement channel; the additional clusters are built from the same mirror registry but are not in the contract record. The audit reads the contract record against the buyer maintained inventory and the eight additional clusters surface as unlicensed unless the buyer can produce evidence they were retired or were development only. The mitigation is a quarterly disconnected cluster inventory that ties cluster builds to procurement records.
The third trap is the air gapped expansion that connected briefly during a maintenance window. A buyer who connected a disconnected cluster to the upstream telemetry for a single content refresh window inadvertently surfaces the cluster to the Red Hat Insights service for the duration of the connection. The cluster appears in the upstream telemetry record with the partial data it was able to transmit before the window closed. The audit then reads the upstream record against the contract scope and surfaces any difference at that moment in time; the buyer who maintains an air gapped programme that allowed temporary upstream connection should hold the connection log and reconcile it explicitly in the audit response.
| Pattern | Frequency | Reading |
|---|---|---|
| Buyer maintained inventory matches contract | 3 of 9 | Pays |
| Operator activation reconciled against catalogue | 2 of 9 | Pays |
| Catalogue synchronised without activation map | 2 of 9 | Traps |
| Offline cluster count past contract scope | 1 of 9 | Traps |
| Brief upstream connection during maintenance | 1 of 9 | Traps |
Reading the disconnected fleet on the buyer record.
OpenShift disconnected install audit posture is read on the buyer maintained inventory, the operator activation map against the mirror registry catalogue, and the contract record that names the disconnected programme scope. The buyer who maintains a disciplined inventory pays the line that the inventory reads; the buyer who relies on the offline posture to obscure the cluster footprint pays the line that the audit defaults to absent evidence. The disconnected install does not reduce audit exposure; it shifts the evidence burden from the upstream telemetry to the buyer maintained record.
The discipline at signature sets four protections that hold across the term. The disconnected programme scope is named in the contract record with the cluster count, the operator activation envelope, and the mirror registry scope explicit. The buyer maintained inventory captures cluster builds with quarterly reconciliation against the mirror registry pull log. The operator activation map distinguishes synchronised content from activated content so the audit reads the activated scope rather than the broader synchronisation scope. A connection log records every brief upstream connection so the upstream telemetry surfacing can be reconciled at audit.
For the broader cross product reading, see the OpenShift practice hub, the edge deployment read where many disconnected programmes intersect with edge fleets, the single node and three node read for compact disconnected sites, the ACM pricing read for the governance posture on offline fleets, and the defense and DoD audit posture where disconnected installs cluster densely on classified and partially classified networks. For the engagement protocol, see audit defense and contact.
Notes & references
- 1. Red Hat OpenShift disconnected install documentation and oc mirror tooling notes, accessed across 2025 and 2026. The disconnected install requires a mirror registry inside the air gapped boundary that holds operator images, container images, and signed certificates the cluster needs.
- 2. Red Hat Insights telemetry on the disconnected install does not reach the upstream service because the cluster cannot connect to the public endpoint. The audit reads against the contract record and the buyer maintained inventory in the absence of the upstream telemetry signal.
- 3. The oc mirror pull log on the connected side captures content synchronisation against the buyer organisation account on the Red Hat content network. The log records what was pulled but not what was deployed; cluster level state remains on the buyer maintained inventory inside the air gapped boundary.
- 4. Practice observation across nine disconnected install engagements settled in the trailing twelve months. The most common exposure pattern is the operator catalogue synchronised to the mirror registry without an activation map across the cluster fleet.
- 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.