Air-Gapping Should Be Head-Slappingly Obvious

When you think of air-gapped security, you imagine a protective distancing that separates your sensitive data from those who would steal it. In practice, the separation is a disconnection from the Internet. If no one can get to your data, no one can steal it. 

 

However, air-gapped deployments that are completely disconnected from the Internet are not the case in all instances. It’s true that many clusters are fully air-gapped, particularly in classified government installations. In these secure air-gapped facilities, the buildings have no connection to the Internet. 

 

There also are warfighter deployments that are fully air-gapped. For example, fighter jets that run Kubernetes are fully air-gapped. 

 

Air-Gapping Takes Many Shapes

In addition to the fully disconnected air-gapped environments, there are logically air-gapped environments in which the protected systems have no connection to the public Internet, but the facility does have Internet connections.  

 

In the traditional IT model of the 1990s up to the present, the default security mode for servers deployed in a data center were essentially air-gapped. The data on the servers were protected by a firewall, which created a demilitarized zone (DMZ).

 

Each individual port opened up to the public Internet required a security review, a process that could take up to months of testing. Software, by and large, was either built internally or purchased and installed internally. Source repositories (repos) were internal. None of these systems needed an Internet connection. The “default” server was effectively air-gapped from the Internet.

 

Cloud Changes the Game

In the cloud-native era, major changes occurred. First, the apps we are running have changed. We are consuming much more software as a service (a model pioneered by companies like Salesforce, but that now includes most business applications), and those applications need access to backend systems and vice versa, so there is a greater need for external communication.

 

Second, the apps we are building are increasingly outward facing. Regardless of the industry, software has, in the words of Marc Andreeson, eaten the world. Organizations of every stripe are producing apps and services exposed to the outside world. In mobile apps, APIs, and integrations with third parties, much more of the code is written to be exposed.

 

Beyond that: The way we build, deploy, and run those apps has changed. Source control systems are often outside the firewall, we are pulling container images, and we are pulling Kubernetes itself. We have package managers that grab dependencies as part of our build process, and others that grab them as part of our deployment process. So that build/deploy process is often dependent on the Internet.

 

Finally: Infrastructure itself is now often in the cloud, and it is typically deployed in a non-centralized manner. In the past you would request a server or virtual machine (VM) from your IT group, wait two months, and IT would deliver it to you. A separate ticket was required if you needed to open a port to the Internet! Now you can simply spin up a cluster yourself in the cloud.

 

All these trends changed how we work with software deployment.

 

Use Some Air-Gapping Finesse

With the Internet and cloud computing came a new term: air-gapping! However, rather than air-gap only your most sensitive data, and in the most isolated buildings, you can reap the benefits of air-gapped security by “logically” air-gapping. 

 

You can accomplish this by creating a digital moat between your cluster and the Internet. You can use this method to secure your software supply chain and prevent image grabbing from the Internet. 

 

You can secure images for your apps as well as for your infrastructure! Think about each thing that needs to be exposed to the Internet, and only expose those things that, well, need to be exposed!

 

Adopt an Air-Gapped Mindset

So where does that lead us? To a much much better state. We get the flexibility and rapid development we seek in a Kubernetes infrastructure, as well as the scalability inherent in cloud-native development.

 

We gain all these advantages without the risk of having everything exposed. Rather, we apply what have always been best practices: Only expose the bare minimum and ensure that the things we are deploying are coming from internal sources and not from the wide-open insecure Internet.

 

When we view air-gapped security in this way, the decision to air-gap clusters becomes head-slappingly obvious!

 

To learn how D2iQ can help you deploy air-gapped environments quickly and easily, speak with the Kubernetes security experts at D2iQ.