Foundations: what 'disconnected' really means and the four supply chains

What changes when you take the public internet off the install path. The four supply chains a disconnected cluster has to solve, the threat model that drives them, and the evidence trail you'll learn to produce.

Before you write your first imageset-config.yaml, it helps to be clear about what disconnected install actually changes and what it doesn’t. The cluster’s behaviour at runtime is mostly the same. The thing that changes is what the cluster is allowed to need from outside. This module sets the framing.

What “disconnected” means in practice

A disconnected OpenShift cluster is one where the cluster nodes have no route to the public internet at install time or runtime. That’s a stronger claim than it sounds:

The acid test: set a default deny egress firewall on the cluster’s machine network. If the cluster installs and runs healthy through 30 days of operator upgrades, you’re disconnected.

Why the public internet drops off the install path

Three reasons cover most engagements:

1. Regulatory — BFSI, healthcare, defence, telecom, OT/ICS. PCI-DSS, HIPAA, NIS2, IEC 62443, FedRAMP-Moderate all have controls that disfavour or forbid cluster-side outbound from production workload subnets.
2. Operational — air-gapped sites with intermittent, expensive, or untrusted uplinks. Submarines, ships, ports, mines, oil platforms, plant floors, edge stores in countries with adversarial CDN posture.
3. Defensive — supply-chain-attack containment. If a malicious operator bundle hits registry.redhat.io for a few hours, a connected cluster pulling on schedule may import it; a disconnected cluster only imports what an operator put into the ImageSet and approved into the mirror.

For most teams it’s a mix — regulation requires the disconnected posture, defence-in-depth is the bonus, and the operational complexity is what you trade against the bonus.

The four supply chains

The single most important framing in this track is that disconnected install isn’t one supply chain to solve. It’s four, each with its own source, transport, custody, and verification.

A team that maps each line to “this script runs on this host, the output lands in this place, this artefact proves it” can install a disconnected cluster. A team that thinks “disconnected means mirror the registry” will get to bootstrap-complete and then watch openshift-marketplace fill with ImagePullBackOff catalog pods.

The supporting service stack

The four supply chains depend on a small set of supporting services. The Day-0 question of any disconnected install is do all of these exist and respond healthy?

The track’s Module 02 walks through each of these in the order you’d stand them up. The order matters: object storage before registry, DNS before TLS, source control before GitOps, secret custody before anything that has a secret.

The threat model that drives the design

If you skim the lab manifests, three patterns will keep showing up. They all come from the same threat model:

1. The cluster cannot pull from a host you didn’t intend it to. That’s why IDMS/ITMS rewrite every upstream registry reference to the mirror at the node level. That’s why default OperatorHub sources are disabled. That’s why built-in OLM v1 ClusterCatalog objects are set to availabilityMode: Unavailable. The cluster cannot pull from registry.redhat.io even if a workload manifest says it should.
2. A compromised mirror can poison the cluster. That’s why the install path verifies release signatures via signature ConfigMaps. That’s why operator catalogs ship as digest-pinned indexes. That’s why Subscriptions carry startingCSV — to prevent a re-mirror from silently advancing the cluster onto a digest nobody reviewed.
3. A compromised operator workstation can poison the mirror. That’s why pull-secrets live in Vault, never on disk where shell history can leak them. That’s why backup passphrases live in Vault. That’s why oc mirror runs from a dedicated host, not the operator’s daily laptop. That’s why the GitOps repo, not a console UI, is the change interface.

The disconnected posture isn’t paranoia — it’s an attempt to make the supply chain inspectable. Every artefact that lands in the cluster has a paper trail back to a reviewed change in Git.

The evidence trail

A useful litmus test for a disconnected install: pick any image running on the cluster — say, cluster-version-operator — and trace it back through six artefacts:

1. The running pod’s spec.containers[].image — a digest pin on quay.v7.comptech-lab.com/openshift-release/openshift/release-images@sha256:....
2. The IDMS that rewrote it from quay.io/openshift-release-dev/ocp-release@sha256:... to the mirror path.
3. The oc-mirror mapping.txt entry from the most recent mirror pass.
4. The imageset-config.yaml in Git that asked for that release.
5. The merge request that bumped the ImageSet to its current commit, with the reviewer’s name.
6. The oc adm release info digest match against the upstream release.

A team that can produce that chain for any image has a healthy disconnected install. A team that can’t is one re-mirror away from a surprise. Module 10 (Day-2 mirror ops) builds the tooling that makes this chain inspectable in seconds.

What changes vs a connected install

The cluster runs the same. The supply chain that feeds it is rebuilt from scratch with you as the responsible party.

The mental model

Carry these three sentences through the rest of the track:

• Disconnected install isn’t an install option, it’s an operating model. The install is two days. The model is forever.
• The mirror is the contract, the ImageSet is the spec, GitOps is the witness. Every image the cluster runs must be in the mirror; the mirror must reflect the ImageSet; the ImageSet must be in Git.
• Disconnected fails closed. A mistake produces ImagePullBackOff, which is loud. A connected install fails open — you only notice the surprise on the day a new digest lands you didn’t ask for.

Exercise

Pick a connected OpenShift cluster you have access to (a dev cluster, CodeReady Containers, anything). Run:

oc get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\n"}{end}' \
  | head -1 \
  | xargs -I{} oc debug node/{} -- chroot /host cat /etc/containers/registries.conf.d/*.conf 2>/dev/null

What you see is the file IDMS/ITMS rewrites on a disconnected cluster — empty or default on a connected one, fully populated on a disconnected one. By Module 06 you’ll know exactly what to expect there, and you’ll be the person writing the IDMS that produces it.

What’s next

Module 02 — Supporting services walks through DNS, MinIO, GitLab, Vault, HAProxy, and NetBox — the stack a disconnected cluster leans on, in the order you stand it up.