The drive to finesse software application development practices aligned to specific types of applications and data services continues to expand and diversify. Among the more ‘high-end’ software engineering disciplines is the move to harness air-gapped development practices.
When we talk about air-gapping (actually we don’t use it as a verb, but we can do in this context for illustrative purposes), we are referring to the development of software that is excluded from any ability to connect with external applications, services, operating systems, the Internet or any other source via either wired or wireless connection points.
Working in air-gapped software environments is useful for mission-critical (or indeed life-critical) scenarios where it is necessary to exclude the software code from any third-party source of any kind. Applications range from military security environments to petrochemical installations to hospitals and everywhere in between.
Well-versed in working with this strain of programming is Deepak Goel, CTO at D2iQ, a company known for its enterprise Kubernetes platform technology.
The ‘connected network’
Let’s remember that Kubernetes, by design, is for the ‘connected network’ where both cluster provisioning and application deployment pulls container images from publicly hosted container registries over the Internet. In fact, the default configuration of containers in a deployment assumes that the container image is available on the Docker registry. This model has worked well as it has alleviated the pain of managing various container images. It has also made it easy to share and deliver new images fairly easily.
“However, this ease proves to be the main challenge for an air-gapped environment,” stated Goel. “In an air-gapped environment, you need to host your own container registry, secure it, make it highly available and fault tolerant. This is no easy work and adds to the operational burden. On top of that, you need to manage the cluster lifecycle including cluster creation, cluster updates and application lifecycle through this container registry. Kubernetes doesn’t make it easy either as the configuration is hidden deep in container runtime and you need to have a deep understanding of Kubernetes to be able to successfully do that.”
This initial point doesn’t even cover the operating system dependencies of Kubernetes components, which contributes to folks spending many, many months and still ending up unsuccessful in managing Kubernetes in an air-gapped environment.
Goel explains that one of the things that will affect air-gapped development is the transfer process speed of data, because that’s going to define the limitations of an air-gapped system. If we have a very long transfer process, it’s likely that we will hold off on updates and then quite quickly fall behind the community and have security vulnerabilities. Then, the whole idea that you’re secure by virtue of being air-gapped won’t hold much water. The developer might be ‘more’ secure and ‘less’ vulnerable, but he or she is still vulnerable.
“One way to mitigate this transfer process issue is to have another cluster assist that is just like your air-gapped cluster except actually connected to the Internet. This cluster will help resolve bugs, enhance speed of delivery, help developers not miss things, help with security requirements and upgrade tests, and it can then be used as a deployment without an image repository,” said Goel.
Most systems are connected to other systems, so for air-gapped Kubernetes, you have to think about the network boundaries you’re going to set up with your cluster and how you’re exposing your cluster to your larger IT system. For internal Kubernetes, at D2iQ, the team always recommends fully open source. It’s generally best for operations and consistency not to add that additional configuration, to put a proper boundary around the network and only poke holes where you need to
But when we talk about your network boundaries, we’re also starting to talk about infrastructure and this starts to matter a lot in air-gapped environments because we tend to see on-premises hardware deployed most often for air-gapped systems.
Internet-connected niceties
“When you get the data in, what do you do with the data? In an air-gapped system on-premesis, you don’t have all the niceties of an Internet-connected system. Your machines might not have the latest GPUs, for example, so when you think about data processing, if you’re doing your development connected to the Internet and not on the air-gapped system with the actual hardware, it’s easy to start bringing in requirements that your air-gapped system isn’t actually capable of meeting purely on a technical hardware level,” said Goel.
So we have to understand our air-gapped system in terms of where we have access and where we don’t – what we can use and what we can’t. This concludes Goel, all means that we have to design the system with those things in mind.