Many organizations follow strict security and regulatory rules to minimize external exposure. In many environments, systems are already protected through layered security controls such as firewalls, demilitarized zones (DMZs), bastion or jump hosts, reverse proxies, content delivery networks (CDNs), and virtual private networks (VPNs). Network access is often further restricted through tightly controlled subnets, encrypted communications over HTTPS, certificate-based authentication, and zero trust architecture (ZTA) principles. These principles emphasize continuous verification and least-privilege access.
While these measures significantly reduce risk, some organizations require an additional level of isolation that removes direct internet connectivity entirely. Red Hat OpenShift supports deployment in fully disconnected, or air-gapped, environments. In these environments, clusters operate without external network access. Administrators introduce all software, updates, and dependencies through controlled and validated processes. This model reduces the attack surface and helps organizations meet strict security, compliance, or data sovereignty requirements.
Recently, while helping a customer deploy OpenShift in an air-gapped configuration, we encountered several operational challenges. Many OpenShift capabilities require outbound connectivity to retrieve platform updates, container images, or operator metadata. Restricting this access requires strict processes and alternative workflows to keep the platform functioning correctly.
Initial setup considerations
Our first challenge involved the installation strategy. The customer asked whether they could initially install OpenShift with full internet access and then "lock down" the environment afterward. The customer hoped OpenShift could download all dependencies during installation before they converted the cluster to an air-gapped environment.
This approach might seem convenient, but it introduces several complications and is generally not recommended. Connected clusters typically pull platform images directly from Red Hat container registries and reference upstream release metadata. They may also install operators from marketplace catalogs that rely on external registries.
Once workloads and operators are deployed, these external references become embedded in multiple components of the cluster. Container image locations can be defined within deployment manifests, operator subscriptions can reference public catalog sources, and external registries can appear within custom resource definitions (CRDs).
Retrofitting a connected cluster into an air-gapped one therefore becomes a complex process. Image references must be rewritten, ImageDigestMirrorSets recreated, operator catalogs re-mirrored, workloads restarted, and the entire platform revalidated to ensure all dependencies resolve internally.
Operating OpenShift in a disconnected environment requires a defined operational cadence to mirror platform images, update operator catalogs, and manage platform upgrades. Without these processes in place, maintaining a fully air-gapped cluster becomes difficult and error-prone.
Establish an operational cadence
Operating OpenShift in a disconnected environment requires more than simply mirroring a set of container images during installation. In connected deployments, the platform can dynamically retrieve container images, operator catalogs, and update metadata directly from upstream registries and Red Hat services. In an air-gapped environment, these functions must instead be supported through deliberate operational processes. The customer encountered several "gotchas" that caused interruptions when installing or configuring components.
For this reason, organizations operating OpenShift in a disconnected configuration must establish a defined operational cadence for introducing platform updates, mirrored content, and security fixes into the environment. Rather than relying on real-time connectivity, administrators periodically curate and transfer approved artifacts from a connected environment into the isolated cluster.
I suggest the following six-step process for your cadence:
- Platform release mirroring: Periodically mirror new OpenShift releases from upstream registries into the internal registry used by the air-gapped cluster. This includes the OpenShift release payload, associated container images, and update graph metadata used by the cluster upgrade process.
- Operator catalog management: Operators installed through OperatorHub rely on catalog sources that reference upstream container registries. In disconnected environments, these catalogs must be mirrored internally and refreshed on a scheduled basis to ensure operators and their dependencies remain available.
- Container image promotion: Application workloads and platform components often depend on base images or external container repositories. These images must be curated, scanned, and promoted through a controlled supply chain before being mirrored into the disconnected registry.
- Security and CVE remediation: Security monitoring typically occurs in a connected environment where vulnerability feeds and advisories are available. When new vulnerabilities affect platform components or container images, updated artifacts must be imported into the air-gapped environment as part of the established cadence.
- Platform upgrade validation: Test cluster upgrades in a connected staging environment before introducing them to the disconnected environment. This step makes sure that mirrored artifacts, operator compatibility, and dependency chains function as expected. (When I was working with our customer, we found this missing step was much needed).
- Registry and artifact maintenance: The internal container registry is a critical part of the cluster. You must manage storage capacity, image lifecycle policies, and artifact pruning to keep mirrored content available. An internal registry like Quay can store these artifacts.
The mirror factory pattern
A common architectural pattern for air-gapped OpenShift environments uses a connected intermediary environment called a mirror factory. Rather than introducing artifacts directly from the internet into a disconnected cluster, organizations maintain a controlled environment that is responsible for retrieving, validating, and preparing platform dependencies before they are transferred into the isolated network.
The mirror factory operates in a connected environment where it can access upstream registries, vulnerability databases, and vendor repositories. From this environment, platform administrators retrieve the necessary OpenShift release images, operator catalogs, and container images required by the cluster. These artifacts can then be curated, scanned, and validated prior to being promoted into the disconnected environment.
This approach has several advantages. First, it creates a checkpoint where you can inspect software for vulnerabilities, validate compatibility, and approve it through internal governance. Second, it allows organizations to maintain a consistent promotion pipeline for platform components, similar to the way application code moves through development, testing, and production environments.
In practice, the mirror factory is often responsible for performing tasks such as:
- Mirroring OpenShift release payloads and associated platform images
- Mirroring operator catalogs and operator bundle images
- Importing required container base images and platform dependencies
- Performing vulnerability scanning and compliance checks on mirrored artifacts
- Validating platform upgrades prior to promotion into the air-gapped environment
- Exporting curated artifacts to portable storage or controlled transfer mechanisms
After you approve these artifacts, you can transfer them into the disconnected environment and import them into the internal registry. Use oc mirror to generate and manage these image sets; you will likely find it to be an essential tool for this workflow.
Conclusion
Running OpenShift in a fully air-gapped environment provides extra isolation to help meet strict security, regulatory, and data sovereignty requirements. By removing direct internet connectivity, organizations can significantly reduce externally reachable attack surfaces and maintain tighter control over the software and artifacts introduced into their platform.
However, achieving and maintaining a disconnected deployment requires more than simply restricting network access. Many OpenShift capabilities rely on external dependencies such as container registries, operator catalogs, and platform update metadata. When these connections are removed, organizations must implement alternative operational processes to ensure the platform continues to function correctly.
Successful air-gapped deployments therefore depend on thoughtful architecture and disciplined operational practices. Establishing a mirror factory pattern allows organizations to retrieve, validate, and promote approved artifacts into the isolated environment, while a defined operational cadence ensures that platform updates, security patches, and operator dependencies remain manageable over time.
Ultimately, air-gapping shifts the OpenShift operational model from dynamic connectivity to controlled software supply chains and lifecycle management. Organizations that plan for these processes early are better prepared to operate stable, disconnected clusters.
