TL;DR: Enterprise customers often have strict network policies and require air-gapped environments, but these can be difficult to simulate and test against. Yet, clarity about your application’s network behavior gives confidence to security-minded customers, and leads to smoother installs. We built Compatibility Matrix Network Reports so you can verify your application only makes approved network calls and ship with confidence to security-conscious customers.
If you have customers in government, defense, finance, or critical infrastructure, your software will likely need to run in an air-gapped environment. If you want to be sure your software works as intended, it’s important to test in these environments before you release it to your customer, just as you would test in staging before deploying to production.
Air-gapped customer environments defend against malicious actors by isolating services from external networks. Simulating this environment requires more than just disconnecting Wifi. Most enterprises use logical air gaps with network isolation rather than physical separation, since manually walking data between machines via USB drives limits scale. Different organizations each have their own specific solution, with a mix of firewall rules, network segmentation, or dedicated infrastructure with internal-only connectivity.
According to our State of Self-Hosted Software survey, 62.2% of surveyed enterprise software vendors support air-gapped deployments, reflecting high customer demand for software compatible with such environments. Yet, teams focused on shipping their product in fast-moving development cycles may overlook testing in air-gapped environments, which risks your customer being the first to discover unexpected network calls.
Why Air-Gapped Environments Are Difficult To Test
If you wanted to make an environment simulating your customer’s air-gapped environment, you’d start by matching the baseline environment, with a comparable Kubernetes distribution and version. Then you’d need to configure firewall rules or set up a proxy to block outbound traffic.
Blocking network egress makes install, testing, and debugging more difficult. If you don’t yet have a Replicated airgap release, you need to be sure you can deploy your software and updates into this air-gapped environment before limiting outbound network traffic. Then, you would need a network analysis tool like Wireshark to capture your application’s calls during install and runtime. But without network egress you may need to manually resolve DNS, as recognizable domains make it easier to understand whether the egress is suspicious and should be mitigated, or is legit and needs to be on your customer’s allowlist.
While this approach can work for basic validation, it’s time-intensive to set up, and tedious to reproduce if you need to test variations across environments. Manual testing risks becoming an afterthought or a bottleneck, which risks missing network behavior that might violate your customer’s security policies.
Better Air Gap Testing
Instead of manually configuring Kubernetes clusters, tweaking iptables firewall rules, and parsing output from low-level tools like Wireshark to figure out what network egress should be whitelisted, there’s a faster and easier path to air gap testing. With Compatibility Matrix (CMX), you can spin up ephemeral VMs and clusters with the Kubernetes distribution and version matching your customer’s environment, set the network policy to [.inline]airgap[.inline], and switch on Network Reports. This makes it significantly more accessible to test every release, and spot unexpected network activity before it reaches your customers.
How To Configure CMX for Air Gap Testing
CMX Network Policy simulates air-gapped conditions, while Network Reports log every outbound connection attempt for output in detail, or as an aggregated summary. You can toggle the policy to [.inline]airgap[.inline] to see how your application functions without network egress, or toggle to [.inline]open[.inline] to run your application without interruption so you can capture all outbound network activity throughout runtime.
You can toggle CMX Network Policy to airgap and enable reporting either through the Vendor Portal, or in a few commands via the CLI.
In the Vendor Portal:
- Navigate to the tab Compatibility Matrix › Network Policy in the left sidebar.
- Select your active VM or VM-based cluster.
- Toggle Reporting to start collecting data. You can set Policy Type to Airgap if you’d like to block network egress to debug your application.
Or, use the CLI:
Set the network policy to [.inline]airgap[.inline] to see how your application works with no external network access:
[.inline]replicated network update <NETWORK_ID> --policy airgap[.inline]
Enable network reporting to see details on network egress:
[.inline]replicated network update <NETWORK_ID> --collect-report[.inline]
View network report
[.inline]replicated network report <NETWORK_ID>[.inline]
(For more options, see docs)
In the Vendor Portal, you can see network events streamed in near real-time. This allows you to quickly confirm which domains your application attempts to reach, and verify that outbound calls are what you expect. Details about source IP, Port, and Process help you identify the processes attempting network egress.
Once you finish testing, you see a summary of domains requested, and destination IP addresses that were successfully connected to. This summary aggregates the number of connection attempts for each domain, and can help you understand what should be on the customer’s whitelist.
CMX Network Reports provides a high-level view of network activity from first install through application runtime. For a more comprehensive understanding, you can run a 48h test to catch intermittent network activity.
Make Network Reporting Part of Your Release Process
As your application evolves, engineers may add outbound connectivity for useful features that many customers welcome, but may violate air-gapped requirements. And even if your core functionality does not require external network access, third-party dependencies may attempt to connect externally for telemetry, updates, or error reporting.
To catch issues that may emerge across updates, add CMX Network Reporting to your automated tests to verify that new releases don’t introduce unintended network calls.
By integrating Network Policy Reports into your CI/CD pipeline, each new release is automatically checked for unexpected egress. Early verification shortens feedback loops, prevents regressions, and proves to customers that every version of your software maintains the same high security standard.To get started, open the Compatibility Matrix tab in Vendor Portal to view and manage Network Policy and Reporting. Read more about these and other CLI options in our documentation on testing in air-gapped environments.