How to Connect an Air-Gapped Kubernetes Cluster Without Opening Firewall Ports

The problem nobody wants to own

You evaluated a Kubernetes management platform, the engineers liked it, and then it reached the security review. The answer came back: "It's SaaS. It needs access to our cluster's API server. No."

That's not obstruction — it's the correct instinct. Handing a third-party service a path into your control plane is one of the highest-leverage attack surfaces you can create. This article is about why that objection is right, what the alternatives actually are at the network level, and how to connect a cluster — including a fully air-gapped one — without ever opening an inbound port.

Most of what follows is vendor-agnostic. The pattern applies whether you build it yourself or buy it.

Why exposing the API server is the wrong trade

To manage a cluster from outside, a platform needs to reach the Kubernetes API. The naive way is to make the API server reachable from the platform's network. Three things go wrong:

1. You've published your most sensitive endpoint. The kube-apiserver is the single point through which every read and write to cluster state flows. Exposing it — even behind auth — puts it on the internet's scan surface. Shodan is full of :6443 endpoints that were "only temporary."

2. Credentials now live off-cluster. For the platform to authenticate, it holds a kubeconfig or a service-account token with broad rights. That secret now sits in someone else's infrastructure. If their systems are breached, your cluster is breached — and you find out last.

3. It doesn't survive the network reality. Production clusters sit behind NAT, corporate firewalls, private VPCs, or in physically isolated environments. "Just allow inbound from these IPs" turns into a change request per environment, per firewall team, per quarter — and is a non-starter the moment a cluster is genuinely air-gapped.

What the security team is actually objecting to

It helps to separate the objections, because they have different fixes:

• Inbound ports. Anything that requires opening a port into the network. This is the hard no.
• Exposed API server. The control plane reachable from outside the cluster boundary.
• Off-cluster credentials. Long-lived kubeconfigs or tokens held by a third party.
• New infrastructure to secure. A bastion or VPN concentrator is itself a box that must be patched, monitored, and audited.

A solution that only fixes one of these isn't enough. A VPN removes the exposed-API objection but adds infrastructure and still often needs inbound rules. The bar to clear is: no inbound ports, no exposed API, no off-cluster credentials, no new box to run.

The three ways to bridge the gap

Bastion / jump host

A hardened host inside the network that the platform reaches, which in turn talks to the API server. Removes direct API exposure, but: it's a new box to secure, it usually still needs an inbound path, and a compromised bastion is a compromised cluster.

VPN / private link

A network tunnel between the platform's network and yours. Strong isolation, but heavy: a concentrator to run, routing to manage, per-environment setup, and it collapses in air-gapped environments where there is no route out to build a VPN over in the first place.

Outbound agent tunnel (the one that fits the constraints)

Invert the direction. Instead of the platform reaching in, a small agent inside the cluster reaches out over a single outbound HTTPS/WebSocket connection on 443 — the same egress every cluster already uses to pull images and call cloud APIs. The control plane runs over that connection.

Why this clears every objection at once:

• No inbound ports. The connection is established from inside, outbound. Firewalls allow outbound 443 by default.
• API server never exposed. It's only ever reached from inside the cluster, by the agent, over localhost/in-cluster networking. Nothing external can address it.
• Credentials never leave. The agent authenticates to the local API with its in-cluster ServiceAccount token, mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. That token never travels off the cluster.
• No new box. The agent is a workload in the cluster, not a separate host.

  Traditional (inbound)                 Outbound agent tunnel
  ─────────────────────                 ─────────────────────

   Platform ──► :6443  API              Platform ◄──── 443 ──── Agent (in cluster)
     (must open inbound port,             (agent dials OUT;          │ in-cluster SA token
      expose API, hold creds)             no inbound, no exposed     ▼
                                          API, token stays local)   kube-apiserver

How an outbound tunnel works, concretely

The mechanics are simple enough to reason about — which is the point; security teams approve what they can audit.

1. Install. A manifest deploys the agent, typically as a DaemonSet, in its own namespace. Leader election (a Kubernetes Lease) ensures exactly one pod holds the active tunnel.
2. Dial out. The agent opens a WebSocket over TLS to the backend on 443 and authenticates with a short-lived registration token baked into the install command.
3. Request/response over the socket. The backend serializes each Kubernetes operation into a message with a request_id; the agent executes it against the local API using its ServiceAccount and streams the response back. Heartbeats keep the connection alive; the agent auto-reconnects with exponential backoff if it drops.
4. Least privilege by allowlist. The agent enforces an allowlist of verbs and resources, so the tunnel can't be coerced into arbitrary calls.

Nothing here requires an inbound rule. If the cluster can reach github.com to pull an image, it can hold this connection.

What actually breaks in air-gapped environments

"Air-gapped" is a spectrum, and the failure modes are rarely the tunnel itself — they're the surrounding assumptions. If you're doing this for real, plan for:

• Private registries. The agent image must come from your registry, not a public one. Mirror it and pin by digest:

  image: registry.internal.example.com/srexpert/agent@sha256:<digest>
  imagePullPolicy: IfNotPresent
  

• Egress allowlists. A truly isolated cluster may not even have outbound 443 to the internet. Then the backend must live inside the perimeter (self-hosted), and the agent dials the internal backend address. This is the case where SaaS-only tools simply cannot play.
• DNS. Split-horizon or internal-only DNS means the backend hostname must resolve inside the perimeter. Test resolution from a pod, not from your laptop.
• Certificate trust. If your backend uses an internal CA, the agent must trust it. Mount the CA bundle rather than disabling verification:

  volumeMounts:
    - name: internal-ca
      mountPath: /etc/ssl/certs/internal-ca.pem
      subPath: ca.pem
  

• Time and cert rotation. Air-gapped nodes drift; expired certs and skewed clocks break TLS handshakes silently. NTP to an internal source is not optional.
• No implicit cloud metadata. On-prem clusters have no IMDS. Anything that assumed a cloud identity endpoint needs an explicit credential.

None of these are exotic — they're the same things that bite every air-gapped rollout. Naming them up front is the difference between a thirty-second install and a two-day debugging session.

A note on self-hosting

The outbound tunnel removes the network objection. Self-hosting the backend removes the data-residency one. For regulated environments — finance, healthcare, defense, government — the requirement is often absolute: no cluster data may leave the network boundary, full stop. That rules out any SaaS-only control plane, no matter how good its tunnel is. The combination that survives that review is web-based operation + self-hosted backend + outbound agent — you get a modern UI and your data never crosses the perimeter.

Where SRExpert fits

SRExpert implements exactly this pattern. You install the agent with a single command:

curl -sL https://<your-backend>/api/v1/agent/install/<token> | kubectl apply -f -

The agent deploys as a DaemonSet in the srexpert-system namespace, elects a leader, and opens an outbound WebSocket to the backend on 443. From that point you get full multi-cluster management — workloads, security scanning, compliance, Helm — with no inbound ports, no exposed API server, and the cluster's credentials never leaving the cluster. For isolated environments, SRExpert is self-hosted via Helm, so the backend runs inside your perimeter and no data crosses the boundary. It's the same platform whether the cluster is a managed EKS instance or a physically air-gapped rack.

If your security team has said no to SaaS Kubernetes tooling, this is the architecture that gets a yes — and you can read every line of what the agent does before you apply it.

---

Related: SRExpert Agent — zero-firewall cluster import · Kubernetes Security Scanner: Vulnerability & Secrets Detection · Kubernetes Security Best Practices for 2026