All insights

Air-Gapped & On-Prem

Container Registries in Disconnected Networks

· 10 minute read

If the run room can still docker pull from the public internet, you do not have a registry problem. You have an air-gap problem. Here is how the internal registry should actually work.

Disconnected Kubernetes clusters fail in the first twenty minutes for one reason: someone typed a public image name. The chart was 'offline ready'. The chart referenced ingress-nginx:latest. The hall's DNS still resolved. The pull either succeeded and broke the gap, or failed and broke the install. Both outcomes are the SI's fault for not owning a registry story.

A registry in a disconnected network is not a nice internal Docker Hub. It is the artefact library for every container you will ever run: app, model server, vector engine, SIEM forwarder, your own debug CLI. If it is not in the registry, it does not exist. That sentence is the whole discipline.

The OCI distribution spec is the boring standard that lets you change registry software later. Use it. Do not invent a folder of tarballs with tribal names.

Two registries and one promotion

Keep a build-side registry (or a cache) on the connected room, and a run-side registry in the enclave. Nothing runs from the build-side. Promotion is the bag: copy a digest, verify, push to run-side, record the promotion. Officers never point a workload at the build-side name.

ObjectBuild roomRun room
Public pullsAllowed, logged, scannedImpossible by network
Unsigned experimental tagsAllowed in a sandbox repoRejected by policy
prod digestSource of a promotionOnly thing schedulers may pull
DeletesAllowed with careAlmost never — prefer immutability
InternetYesNo

Pin, sign, scan, prune

  • Pin digests in your deployment manifests. Tags are aliases for humans, not for kubelets.
  • Sign with a key you hold. Cosign-style or equivalent — the important part is that the run room can verify without calling a public Rekor and without phoning the vendor.
  • Scan on ingest. A scanner that needs the internet at query time is another leash. Import vulnerability DBs through the bag on a calendar.
  • Prune unused digests on a policy, not when the disk fills during an incident. Keep last-known-good.
  • Mirror Helm charts and OCI artifacts the same way you mirror images. Charts that pull subcharts from GitHub are a trap.

Air-gapped Kubernetes specifics

If you run Kubernetes, treat the control plane images as first-class: etcd, coredns, CNI, CSI, ingress, metrics. They all have versions. They all have CVEs. A cluster that only pins the app is a cluster that will pull a CNI on a bad day. Write the full image set into the bag SOP.

Day-2 operations

  1. Backup the registry metadata and the blob store together.
  2. Monitor disk like a database. Layers are large once models sit in images — consider keeping weights out of images and in the artefact library.
  3. Document how a new node authenticates to the registry without a human pasting a password into a node.
  4. Test a restore of the registry itself. If the registry dies, your cluster cannot self-heal.

Objections you will hear — and what to do with them

We will use the vendor's offline installer.

Use it to seed once, then take inventory of every image it unpacked and import those into your registry. The next installer will be a different version. Your registry is the continuity.

Mirroring everything is too much work.

Then your image set is too large for an enclave. Shrink the product. An enclave that needs four hundred images is an enclave that will cheat.

Signing is ceremony we do not have time for.

Then an attacker only needs to swap a bag. Signing is the cheapest part of the ceremony. Learn it in week two of the bootstrap.

A fifteen-day registry playbook

  1. Days 1–3: stand run-side registry, deny its outbound, create prod and staging projects.
  2. Days 4–8: render every chart, list every image, import the minimum set, pin digests.
  3. Days 9–12: turn on signature verify and a scanner with an imported DB.
  4. Days 13–15: delete a tag on purpose in staging, prove prod cannot, restore a blob, write the SOP.

How this shows up in the file

The runbook should say: if it is not in the run-side registry, it does not run. Attach the image list and the last promotion log. That page is how you answer a CISO who asks what code is in the cage.

Model weights are not layers

Stuffing a 10–70 GB weight file into a container layer makes every registry operation painful and every pull on a new node a ritual. Prefer a thin serving image and a weight object in the artefact library, mounted read-only, verified by hash at start. The registry then stays a code store. The artefact library stays a model store. Both use the same ceremony style.

If you must ship weights as images, treat them as a separate project with a slower promotion and a longer retention. Do not put them in the same cleanup policy as a 40 MB microservice or someone will delete the only copy of a model to free disk at 1 a.m.

  • Start-up must fail if the hash does not match. Do not 'warn and continue'.
  • Keep last-known-good weights even when the new ones promote.
  • Do not fetch weights from a personal Hugging Face token inside the run room.

Document how a second node gets the weights without the first node becoming a file server on the side. Side file servers become shadow registries with no signatures.

This article is a field guide, not legal, procurement, electrical or engineering advice. Confirm numbers, duties and designs against the current Gazette, CERT-In directions, your SDC / NIC / campus standards, a site survey and your counsel before you file them.

How to prove this on a rack, not on a slide

“Container Registries in Disconnected Networks” only matters if a CISO can fail it. A P4 Systems Integrator should be able to point at a cable, a registry, a licence file, a PDU reading or a SIEM index and say: this is the control. If the only evidence is a brochure that mentions “offline container registry”, you do not have the control.

If the run room can still docker pull from the public internet, you do not have a registry problem. You have an air-gap problem. Here is how the internal registry should actually work. Air-gap and on-prem programmes die in the second month, when the first update, the first crash, or the first GPU lead-time slip arrives. Budget the boring path — media, offline licence, local registry, local traces — in the same note as the model name.

On-prem is not air-gapped. An India region is not either. Write the forbidden path (outbound HTTPS, licence phone-home, crash reporter, hidden model API) as a numbered list and test it with the internet off. Whatever still dies was a dependency you did not draw.

  1. Draw the data path for one user-visible answer under “offline container registry”.
  2. Disable outbound internet on staging and run the demo script.
  3. List every remaining hop: update, licence, registry, NTP, DNS, SIEM.
  4. Give each hop an owner inside the department, not only the SI.
  5. Minute the restore or the media-transfer once before go-live.

Close this loop before the next CAB

Put “Container Registries in Disconnected Networks” on the next change-advisory or bid-opening agenda as a single line item with an owner. If it cannot earn a line item, it will not earn a control. The owner should be a P4 Systems Integrator, not “the vendor.”

Revisit the item when the model, the GeM term, the region, or the SI changes. “offline container registry” is not a one-time workshop. It is a watch item. Date the last check. Unsigned watch items are souvenirs.

What the next noting must contain

“Container Registries in Disconnected Networks” belongs in a file, not only in a search result. A P4 Systems Integrator should be able to point at one artefact that proves “offline container registry”: a packet capture, a processing schedule, a scored evaluation row, a dated notice, or a refusal rule. If the only evidence is a slide, you have a heading.

If the run room can still docker pull from the public internet, you do not have a registry problem. You have an air-gap problem. Here is how the internal registry should actually work. DPDP 2023 does not define sovereign AI and does not write a blanket localisation rule for every model hop. CERT-In’s 28 April 2022 directions still set specified incident clocks and 180-day log retention in India for in-scope events. The November 2025 AI governance text is guidance, not a statute. A Proprietary Article Certificate, when it is lawful, lives in GFR Rule 166 — not Rule 161.

Write three dated sentences under C2 Air-Gapped & On-Prem: what was decided, which designation owns it after the next posting order, and when it will be re-checked. Unsigned sentences are souvenirs. Dated sentences are controls.

  • Name the designation that owns “offline container registry”, plus a deputy.
  • Attach one artefact a stranger can open next year.
  • Name the instrument you are actually using — Act, direction, GFR clause, GeM term, or guideline paragraph.
  • Leave unsourced percentages, GMV slides and house forecasts out of the noting.
  • Revisit when the model, the SI, the notice, the region or the posting changes.

Questions this usually raises

Is Harbor / a generic OCI registry mandatory?
An OCI-compliant private registry is mandatory in spirit. The brand is not. Pick something you can snapshot, scan, and operate without its own phone-home. Read the operator chart.
Can we vendor a USB of images without a registry?
For a single appliance, maybe, once. For anything that will patch, roll back or scale to a second node, you want a registry as the source of truth inside the enclave. Tarballs on a desk become mystery versions.
How do we trust what we imported?
Pin by digest, verify signatures you understand, scan on the build side and again if you can on the admit side. A tag called prod is not trust.
What about base images and distro mirrors?
They are part of the same problem. Host an internal mirror or import bases through the bag. Nodes that apt-get to the internet are not disconnected, even if the app image is local.

Sources