Kubernetes air-gapped installation guide

Why a Kubernetes air-gapped installation starts with an inventory, not an installer

In an air-gapped network, a cluster cannot reach a public registry, a package mirror or a chart repository while it installs. That means every container image, binary, chart and operating system package the cluster needs has to be carried in deliberately before the first node boots. The work that decides whether the installation succeeds is not running the installer. It is producing a complete, versioned list of what the installer will ask for, and proving that the list matches the bundle you transfer across the boundary.

The list is longer than the names people usually have in mind. Control plane images for kube-apiserver, kube-controller-manager, kube-scheduler, etcd and the proxy component are the obvious entries. The network plugin, the storage driver, the ingress controller and the monitoring stack each bring their own images, init containers, sidecars and charts. Each of those components also has transitive dependencies, such as base images, helper images referenced only in a chart default value, and packages pulled by a node-level script. Ask the platform owner to list every component by name and version, then ask each vendor or project for its full image and chart manifest rather than relying on memory or the top-level chart.

Regulated, classified and isolated networks are the usual reasons teams take on this work. In those environments, the inventory is also audit evidence: it shows what was introduced, from which source, and under which approval. Keep the inventory in version control next to the cluster configuration, with checksums for every artifact, so the same record can answer questions about provenance during an assessment. Confirm with your security team how transfers are approved, scanned and logged before the first bundle is built, because those steps often take longer than the mirror itself.

Two things make this harder than it looks. The first is hidden pulls at install time: a chart default, an operator that fetches a sidecar on first reconciliation, or a tool that downloads a plugin will try to reach the internet and fail or hang only after the rest of the install appears to have succeeded. Test the install from a network segment with no route to the internet, and log every registry and host the process attempts to contact. The second is upgrades. Each new version needs its own transfer cycle, with its own inventory diff, because the images and charts for the next release are not in the bundle you already carried in. Plan for that second cycle from the start, and check the Kubernetes release and version skew rules for the minor versions you intend to run before you commit to a schedule.

The steps that follow in this topic build on that inventory: how kubeadm pulls and points to a private registry, how package and chart repositories are mirrored, how certificates are handled without outside services, and how upgrades are rehearsed offline. High availability topology, hardening controls and etcd backup are covered in their own topics, so this section stops at the artifact list. Before you request a quote, ask the implementation partner to show how they will produce and verify that list for your chosen versions.

Which components must cross the air gap

A disconnected cluster cannot fetch anything at install time, so every artifact the bootstrap and add-on steps need must be staged inside the boundary beforehand. The cards below group those artifacts by where they are pulled from during a connected install, which is the list you need to build your transfer manifest.

Control plane container images

These are the images kube-apiserver, kube-controller-manager, kube-scheduler, kube-proxy and etcd run as. Run kubeadm config images list on a connected workstation to get the exact set for your target release, then kubeadm config images pull to fetch them. Load the results into your private registry and point kubeadm init at it with the image repository option, so the control plane never reaches for a public registry.

Add-on container images

Networking, DNS, ingress, metrics, storage drivers and any operators you install each bring their own images, often pulled from several registries. Build the list from the rendered manifests or chart values, not from memory, because a missing sidecar image is a common cause of a half-working add-on. Confirm each image's tag and digest against the vendor's release notes, and record them in the same manifest as the control plane images.

Helm charts and chart archives

Charts supply the templates that turn add-on configuration into Kubernetes objects. Pull the chart archives while connected, verify their provenance where the publisher signs them, and store them in an internal chart repository or as local files. Check that the image references inside each chart's default values point at your registry, since charts often reference public images unless you override them.

OS and container runtime packages

Node operating systems need packages for the container runtime, the kubelet, kubeadm, kubectl, and their dependencies such as conntrack, socat and certificate tooling. Mirror the distribution's package repositories for your exact OS release, including dependency closure, because a single missing library will fail a node during join. Plan a repeatable way to refresh these mirrors for security patches, not only the first install.

Node bootstrap binaries

Some installs fetch binaries directly, such as kubeadm, kubelet, kubectl, the CNI plugin set, and the container runtime archive, rather than from a package manager. Download them from the project's published release artifacts, store them with checksums, and confirm the checksum before copying them to nodes. Keep the binary set matched to the control plane version under the version skew rules, since mismatched kubelets are a frequent source of join failures.

Certificates and signing material

A cluster needs a certificate authority, component certificates and, if you use an internal registry or chart repository, its own trust chain. Decide before transfer whether these are generated inside the air gap or imported, because they cannot be copied out later without a security review. Record which root each node trusts so that registry, package mirror and API endpoint certificates all validate on first boot.

How to get artifacts into the isolated network

This table compares four ways to move images, charts, packages and binaries into an isolated cluster environment, with the team size and change pattern where each one fits and the recurring work it creates. Read each row as a trade-off: the fastest setup is rarely the cheapest to run across several versions and sites. The main takeaway is that the image list and the scanning step drive most of the ongoing effort, whichever transfer method you choose.

Option	When it fits	Operational cost
Full mirror synchronized from a connected staging network	Few clusters, several upgrades a year, a team that can run a scheduled sync and accept a larger transfer each cycle	Every sync moves the whole set again, so repeat transfers grow with the catalog. Scanning covers everything on each import, and sites can drift if one import is skipped.
Curated subset built from a generated image list	Several clusters on the same version, a platform team that can maintain a list per release and wants smaller transfers	The list must be rebuilt for each Kubernetes and add-on version. Missed images appear only at install or upgrade time, so the list needs a check against the cluster.
Registry replicated through a controlled transfer host	Many clusters or sites that need one consistent source, and a team that runs a registry service and approval workflow	Someone operates the registry, transfer host and access controls. Scanning happens at the boundary, and replication tooling needs patching like any other service.
Manual export and import of archives	One or two clusters, infrequent changes, and an operator who can document each transfer and its checksums	Each transfer is manual and easy to get wrong. Records of what was imported and when become the only drift control, and effort repeats for every version and site.

Build the offline install in order

This sequence turns an internet-connected build into a self-contained set of images, charts, packages and binaries that a cluster can install from without any outbound access. Each step closes with a check so the isolated install does not depend on untested assumptions.

Generate the image list for the target version
The platform engineer runs kubeadm config images list against the exact Kubernetes minor version the cluster will run, using the same kubeadm configuration file that the production install will use. The output is the list of control plane images, including the etcd and CoreDNS images that kubeadm references by default. Save this list in version control so every later step works from the same record. It is done when the list is committed and a reviewer has confirmed the version matches the target in the upgrade plan.
Pull and verify images on a staging host
On a connected staging host, the engineer runs kubeadm config images pull with the same configuration, then exports each image as an archive. Record the digest of every image and store the digests with the list. The check is a comparison: pull the images again from a second session and confirm the digests match the recorded values. Any mismatch should stop the process until the cause is understood, because it means the mirror would not be the artifact you reviewed.
Render and mirror add-on images and charts
Add-ons such as the network plugin, ingress controller, metrics, storage drivers and monitoring are rendered from their charts using the exact values files used in production, so the rendered manifests name the images that will actually run. Extract every image reference from the rendered output and add it to the mirror set. The check is a diff: render again from the committed values and confirm the image references are identical to the mirror list. Charts and rendered manifests are stored alongside the image list.
Push everything to a private registry
Load the image archives into the internal registry under a stable naming scheme, such as a fixed prefix for each upstream repository and the original tag, so that references never depend on where an image was first pulled. Keep the mirror read-only for cluster nodes. The check is a pull test from a node inside the isolated network: pull a sample of images from each repository prefix and compare the digests with the staging record. Confirm that the registry rejects anonymous pushes and that nodes can reach it without outbound routes.
Point kubeadm at the private registry
Set the imageRepository field in the kubeadm configuration, or pass the image repository option to kubeadm init, so control plane images resolve to the internal registry instead of the public one. Use the same prefix that was applied during the push. The check is a preflight run: execute kubeadm init preflight checks on an isolated node with outbound access blocked, and confirm that no image pull errors or network failures appear. Fix any reference that still points upstream before running the real init.
Prepare OS and runtime packages internally
Mirror the operating system packages, the container runtime, and the kubeadm, kubelet and kubectl packages for the target minor version into an internal package repository. Pin the versions in the same record as the image list so that nodes install matching components. The check is a package install on a clean node from the internal repository alone, with the package manager pointed at no external sources. Record the resulting package versions, since they will be needed for later version skew checks.
Provision node bootstrap binaries from an artifact store
Place the binaries that nodes need during bootstrap, including the kubelet configuration tooling, CNI plugin binaries and any certificate or etcd tooling, in an internal artifact store with checksums published alongside. Nodes fetch only from this store. The check is verification: download each artifact on an isolated node, compare its checksum against the recorded value, and run the binary's version command. Once every artifact matches, the offline install has all of its inputs and the cluster can be built from the isolated network.

Certificate and trust handling when nothing can be fetched online

The cluster's internal certificate authority is created on the first control plane node when kubeadm init runs, and it signs the certificates used by the API server, etcd, the kubelets and the front-end proxy. These certificates must be generated locally during installation because each one must match the names and IP addresses that components use to reach each other, including the load balancer endpoint in front of kube-apiserver. An air-gapped environment has no public certificate service to call, so the cluster CA is a private trust root that your organization owns and must protect. Before running init, confirm with your PKI team whether kubeadm will generate the cluster CA on the node or whether you will import an intermediate CA from your enterprise PKI. Record that decision, because it determines who signs renewals later.

The private registry creates a second trust chain. Its certificate must be trusted by the container runtime on every node, including the control plane nodes that pull the images kubeadm needs during init and the worker nodes that pull add-on images afterward. Trust is configured in each runtime, and the procedure differs between containerd and CRI-O, so check the runtime and version your nodes actually run. Distribute the registry's root or intermediate CA to every node before the first kubeadm join. A node that cannot verify the registry during join usually fails with errors that look like network faults, which slows diagnosis. Also confirm whether the registry requires client certificates and who holds those credentials.

Expiry must be checked before the cluster enters service and again on a fixed schedule. kubeadm can report the expiration dates of the certificates it manages, but you should also inspect the registry, ingress, identity provider and etcd certificates, since their lifecycle belongs to other teams. Record the expiry date of every certificate and compare it with the change windows your organization needs to renew it. Ask your PKI team for the validity periods of the root and intermediate CAs, the signing algorithms they accept, and whether a subordinate CA is permitted to sign cluster certificates. A cluster CA with less remaining life than the leaf certificates it issues will limit how long those leaf certificates can be trusted, so check that relationship early.

Renewal and CA rotation must be planned as operations, because no external service will reissue anything once the environment is offline. kubeadm can renew leaf certificates, but renewal typically requires restarting control plane components, and kubelet client certificates on each node need their own check. Rotating the cluster CA is a larger change that touches every node and every component that trusts it, so treat it as a project with a rehearsal in a staging cluster and a documented rollback. Confirm which renewal and rotation procedures apply to the kubeadm version you run, and check whether certificate lifetime settings were overridden in your kubeadm configuration at init. Those overrides change every date in this plan, so verify them in your own environment rather than relying on the defaults you may remember.

How the offline install changes by network model

This model keeps the cluster on a network that can reach the internet, but routes image and chart pulls through a private mirror or registry proxy. The mirror gives the platform team speed, a single point for scanning and caching, and resilience when an upstream registry is slow or unavailable. Nodes never pull directly from public sources, so the allowlist is short and the mirror becomes the audit point for what enters the cluster.

Image flow: control plane and add-on images are mirrored on a schedule or on demand, and nodes pull only from the mirror hostname.
Chart and package flow: Helm charts and OS packages come from internal repositories that sync from approved upstreams.
Approval: the platform owner approves new upstream sources and version pins, while security reviews scan results before images are promoted.
Node bootstrap: kubeadm can point at the mirror through its image repository setting, so new nodes join without extra transfer steps.
Upgrades: the team mirrors the target version's images before the upgrade window, and the mirror keeps the previous version available for rollback.

Confirm with your distribution vendor which mirror or registry proxy features it supports, and whether its add-on charts reference hardcoded public registries that you must rewrite.

What drives the effort of an air-gapped Kubernetes install

This table lists the factors that change how much work an offline Kubernetes install takes, how each one moves cost, and what keeps it under control. Read each row as a lever: the first column names the driver, the second explains its effect on effort, and the third gives the practices that reduce it. The main takeaway is that most of the effort comes from how many artifacts move across the air gap and how many approvals each one needs, so standardizing those early pays back across every cluster.

Driver	How it changes cost and effort	How to keep it down
Number of add-ons and dependency depth	Each add-on brings its own images, charts and CRDs, and charts often pull in subcharts with further images. Every extra layer adds artifacts to mirror, verify and re-mirror at each upgrade.	Limit add-ons to those with a clear need, pin chart versions, and generate the image list from rendered charts with a script rather than by hand.
Clusters and nodes sharing one artifact set	A single artifact set serving many clusters is mirrored and reviewed once. Separate sets per cluster multiply transfers, checks and version records.	Define one standard artifact set per Kubernetes minor version and reference it from every cluster, with only cluster-specific values varied.
Distinct minor versions supported at once	Kubernetes maintains the three most recent minor releases, so running clusters on mixed versions means mirroring and testing several sets of control plane and add-on images in parallel. Confirm current end-of-life dates on kubernetes.io/releases before planning.	Keep fleets on as few minor versions as possible, and schedule upgrades one minor version at a time so each step uses a single new artifact set.
Security review of incoming artifacts	Each image, chart and binary crossing the boundary may need scanning, signature checks and a documented review. Review time grows with artifact count and with the number of unfamiliar publishers.	Agree a review checklist with the security team, verify digests and signatures in a scripted step, and reuse prior review records for unchanged artifacts.
Approval gates per transfer	Each transfer may need sign-off from security, change management and data owners. Every gate adds waiting time and a chance for a rejected item to delay the whole batch.	Bundle transfers into a small number of predictable batches, agree gate criteria in advance, and ask the approving bodies for their standing requirements.
Quality of existing internal package and registry infrastructure	A working private registry, package mirror and chart repository shortens setup. Missing or unmanaged infrastructure adds work for storage, access control, certificate trust and garbage collection before Kubernetes itself is installed.	Assess the current registry and package mirror before scoping, and confirm that they support OCI images, Helm charts and the OS packages the nodes need.

Security controls for artifacts and the private registry

An offline cluster is only as trustworthy as the artifacts that enter it. The controls below cover how images and packages are verified, who can write to the internal registry, how incoming content is scanned, and which nodes may pull what. They sit alongside, not inside, the pod security and benchmark work covered elsewhere.

Verify digests and signatures before import

Record the digest of every image and chart in the transfer manifest, and check each one on the high-side network before it is pushed to the registry. Where the publisher provides signatures, verify them against keys you obtained through a separate, trusted channel. Confirm with each vendor which signing method they use and where the verification keys are published.

Restrict who can push to the registry

Limit write access to the internal registry to a small mirroring service account and the named release engineers who run imports. Read access for nodes should be separate and narrower. Check that the registry's authentication model supports separate push and pull roles, and that every push is logged with the identity that made it.

Scan incoming images and packages

Run vulnerability and policy scans on each image, OS package set and chart before it is promoted into the registry the cluster uses. Define the policy you enforce, such as blocking critical findings or unapproved base images, and record exceptions with an owner and expiry. Ask your scanner vendor whether its vulnerability database can be updated offline and how often you must transfer updates across the gap.

Keep the registry inside the trust boundary

Host the registry, its storage and its backups in the same security zone as the cluster, with no route to public registries. Confirm that the storage backend is encrypted at rest and that access to the underlying volumes is limited to the registry service. Treat the registry as a tier-zero asset, since a tampered image there reaches every node that pulls from it.

Limit which nodes can pull

Decide which node pools and namespaces may pull from the registry, and enforce that with network rules and registry credentials scoped per pool where the registry supports it. Pull credentials are stored as Secrets, which Kubernetes keeps unencrypted in etcd by default. Enable encryption at rest, restrict list and watch access to those Secrets with least-privilege RBAC, and review who can read them.

How upgrades work when every artifact needs a transfer

An offline upgrade is a new artifact release cycle, and it starts long before any node is touched. For each target minor version, the team generates the control plane image list with kubeadm config images list, adds the add-on images, chart versions and operating system packages the cluster will need, and mirrors all of them into the private registry and package repositories inside the enclave. Only after that bundle is complete should someone run test pulls from a host that matches each node's role to confirm every reference resolves. A missing image discovered during a node upgrade turns a planned change into an incident, so the pull test is the gate that decides whether the window opens.

The version skew rules let the transfer work be staged. kube-apiserver is upgraded first, one minor version at a time, followed by kube-controller-manager and kube-scheduler. Kubelets may run up to three minor versions older than kube-apiserver, so node upgrades do not have to happen in the same window as the control plane. That gives the team room to move nodes in batches as each transfer bundle is approved and verified. The trade-off is that every kubelet version still in use needs its own images and packages in the mirror until its nodes are upgraded, so a staged rollout requires a bundle that covers more than the newest release. Confirm with your distribution's documentation that the components it ships follow the same skew bounds.

Plan the transfer window around the supported release dates. The Kubernetes project maintains the three most recent minor releases. As of September 2026, these were 1.37, with end of life on October 28, 2027, 1.36, with end of life on June 28, 2027, and 1.35, with end of life on February 28, 2027, according to the Kubernetes releases page. Releases arrive about three times a year, so the supported set changes several times within a single planning cycle. Confirm the current versions and end-of-life dates on that page before you set the calendar, and treat each supported minor version you run as another artifact set to keep current.

Turn those dates into a calendar of transfers, working backward from end of life. Decide how many transfer cycles per year your security team will approve, who builds and signs each bundle, and how each one is scanned before it crosses the boundary. When you ask an implementation partner for a quote, request the mirror, verification and transfer effort per release cycle as a recurring line item, separate from the one-time build of the registry and repositories. The detailed upgrade procedure, deprecated API checks and rehearsal plan are covered in the upgrades topic, so this section sets the cadence those steps have to fit into.

Questions buyers ask before an air-gapped Kubernetes install

How much does an air-gapped Kubernetes install cost?

No single figure applies to every environment, because cost follows the written scope. Upstream Kubernetes is licensed under Apache 2.0, so the spend is mainly labor, infrastructure and the approvals around the work. The main drivers are the artifact count (control plane images, network and storage add-ons, chart and package repositories), the number of transfer approvals the content needs, and how ready your registry and PKI already are. Ask any provider for a quote that separates one-time work (artifact list, mirror build, cluster build, hardening, handover documentation) from recurring work (mirror refreshes, upgrade rehearsals, support retainers). DeployOpen prepares quotes from a written scope before work starts.

How long does an air-gapped Kubernetes build take?

The timeline depends mostly on what you already have in place, so confirm those items before you accept any schedule. Teams with an approved transfer path, an internal container registry, an internal package mirror and a working certificate authority move faster than teams that must build each one. Approval cycles often set the pace, because security reviewers and network owners each add calendar time that engineering effort cannot shorten. Ask for milestones in the written scope: artifact list approved, mirror populated and verified, cluster built without internet access, etcd snapshot tested, and handover completed. Your own change calendar and the number of environments (lab, staging, production) will also shape the schedule.

Which people on our side must be involved in an offline build?

Four roles carry most of the decisions. Network owners define the transfer path, egress rules, DNS and the load balancer in front of the API server on port 6443. The PKI owner issues or approves certificates for the API server, etcd peers and kubelets, and decides how the internal CA is trusted on every node. Security reviewers approve the artifact list, review image sources and check hardening against your baseline. The registry owner manages storage, access, retention and tag policy for the mirrored images. A platform lead should also be named to sign off the design. Confirm early who holds each role, because a missing approver usually stops the build, not the engineers doing the work.

Can our own team run an offline Kubernetes install without a partner?

Yes, if the team already has the skills to maintain an artifact pipeline. That means Linux administration, kubeadm, container image tooling, registry administration, certificate management and etcd operations. The pipeline must be repeatable, because every later upgrade needs a fresh set of images and packages checked and moved across the boundary. Test this before you commit: ask the team to walk through a dry run in a lab, including a restore from an etcd snapshot. If gaps appear, you can hire a partner for a fixed-scope build with documented handover, or add a retainer for upgrades and support. Either path should end with runbooks your staff can follow without the partner present.

How do Kubernetes upgrades change the work when there is no internet?

Each upgrade needs its own mirror set, because the images for the target version must be listed, pulled and transferred before the cluster can move. The kubeadm config images list command reports the control plane images for a given version. Upgrades must go one minor version at a time, with kube-apiserver first, then kube-controller-manager and kube-scheduler, then kubelets, and kubelets may run up to three minor versions behind the API server. Kubernetes releases come roughly three times a year on a cycle of about 14 weeks. As of September 2026, the supported minor releases were 1.37, 1.36 and 1.35. Plan upgrades around that cadence and budget a staging rehearsal for each one.

Does an offline cluster change how we handle certificates and trust?

Yes. Without internet access, the cluster and the registry both depend on certificates from your internal CA, so trust must be set up before the first join. Your PKI owner should decide the certificate authority, the validity periods, how the registry certificate reaches every node, and how renewal will happen without public services. kubeadm generates many cluster certificates, but the trust chain for the registry and any package mirror is your responsibility. Ask for a written list of certificates, owners, expiry dates and renewal steps, and test renewal in staging. Errors here often appear as image pull failures or failed node joins, so include certificate checks in the verification steps.

Are Secrets and etcd backups harder to manage without internet access?

The core controls are the same, but backups and key handling need more planning. Kubernetes stores Secrets unencrypted in etcd by default, so you should configure encryption at rest and restrict list and watch access with least-privilege RBAC. etcd snapshots are taken with etcdctl snapshot save and restored with etcdutl, and both the snapshots and the encryption keys must stay inside your network with access limited to a few named operators. Confirm where backups are stored, who can read them, how keys are rotated and how restores are rehearsed. Ask the provider to show a restore drill in your environment, not only a written procedure.

How DeployOpen scopes, builds and hands over an air-gapped Kubernetes install

DeployOpen plans, builds and hands over Kubernetes clusters that run inside networks with no internet access, including air-gapped networks in your own data center or cloud account. The work centers on a mirrored image and chart workflow, a private registry, offline package repositories and a documented upgrade path for each supported minor release.

How we scope

The written scope lists every mirrored image, chart, package repository and certificate authority in the offline bundle.
Scope also fixes the Kubernetes minor version, the control plane topology and the registry and repository hosts.
Engagements are fixed-scope, with deliverables and timing agreed in writing before any work starts.

How we build

Mirror control plane images using kubeadm config images list and pull, then push them to the private registry.
Point kubeadm init at the private registry with --image-repository, then test node joins with no outbound access.
Configure etcd snapshots, Secrets encryption at rest and Pod Security Standards before any workloads are admitted.

How we hand over

Operator runbooks cover bundle refresh, registry sync, certificate renewal and offline upgrade steps for each minor release.
Etcd snapshot restores are rehearsed and the results recorded, so your team has a tested recovery path.
Evidence packs map the configuration to CIS Kubernetes Benchmark recommendations for your auditors to review.

How we support

Upgrades follow the version skew policy: one minor version at a time, kube-apiserver first, then kubelets.
Staying inside the three supported minor releases requires a planned bundle refresh before each upgrade window.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.

Kubernetes air-gapped installation