I'm curious about the experiences of anyone running Kubernetes (K8s) clusters in completely restricted environments—like air-gapped setups, strict firewalls, or with very limited egress and no cloud dependencies. This could apply to sectors like military, finance, healthcare, or government.
We're in the process of building K8s tooling (specifically known as Kunobi, among others) that caters to these kinds of scenarios. We're focusing on support for environments that avoid server-side deployment, telemetry, and external dependencies—essentially a standalone binary and your kubeconfig, without SSO or SAML complexities.
I'd love to learn about what tools you currently use in these restricted setups. Are you mainly using kubectl and k9s, and do you put extra effort into vetting your software? Have you tried other tools that you had to abandon due to internet access issues? And lastly, how do you handle updates and patches when you cannot access the internet?
5 Answers
I suggest reconsidering avoiding SSO or SAML. Just leverage your internal Active Directory. As for telemetry, it’s essential to route it internally. Organizations operating in air-gapped environments usually take security and monitoring seriously.
In our experience with many air-gapped clusters, we use an external container registry to pull images, then mirror that to an internal registry for our clusters. We also deploy Grafana and Prometheus for monitoring and manage configurations through Terraform.
Honestly, kubectl and k9s don't require internet access at all; they only communicate with your API server. The bigger issue in air-gapped environments is managing the image and artifact supply chain, not the basic tooling itself. Typically, this is addressed by using specific images governed by a managed container registry within your infrastructure.
The trickiest part of being air-gapped is updating your image registry across all components. If you're using a system like RKE2, you can set your cluster to look at a designated registry regardless of what’s specified in your specs. Alternatively, I’ve set up mutating webhooks to change pod image specs on the fly, making it easier to match your internal registry.
You might want to check out Zarf. It consolidates images and Helm charts into a single tar file, which is great for transferring to the other side via physical media. It packages all dependencies in OCI format, so you can easily set it up in a registry if needed.
Exactly! I really rely on Zarf for my setups.
Zarf works well if it fits your needs, but it's pretty opinionated. If you just need to ship OCI artifacts without all its extra features, Hauler might be a better fit.