Isolating your infrastructure from Internet access is often a best practice, but it impacts the default operational mode of VMware Telco Cloud Automation. The Airgap solution eliminates the requirement for internet connectivity.

In the non-air-gapped design, Telco Cloud Automation uses external repositories for Harbor and the PhotonOS packages to implement the VM and Node Config operators, new kernel builds, or additional packages for the worker nodes. Internet access is required to pull these additional components.

The Airgap server is a Photon OS VM that is deployed and configured for use by Telco Cloud Automation. The airgap server is registered as a partner system within the platform and is used in internet-restricted or air-gapped environments.

The airgap server allows the VMware Tanzu Kubernetes Grid clusters to pull the required Kernels, Binaries, and OCI images from a local environment.

Note:

While the Airgap server removes the requirement for Internet access to build and manage Kubernetes clusters, the Airgap server creation requires Internet access to build and pull all the external images to be stored locally.

The airgap server OVA included with Telco Cloud Platform supports multiple TKG releases. For Greenfield environments, only the TKG 2.5 artifacts may be required. However, to support multiple TKG releases, the airgap can synchronize all required repositories from TKG 2.1 through TKG 2.5, accommodating various use cases.

The Airgap server can be built on an Internet-accessible zone (direct or through proxy) and then migrated to the Internet-restricted environment and reconfigured before use.

The airgap server operates in two modes:

  • Restricted: This mode uses a proxy server between the Airgap server and the internet. In this mode, the Airgap server is deployed in the same segment as the Telco Cloud Automation VMs in a one-armed mode design.

  • Air-gapped: In this mode, the airgap server is created and migrated/moved to the air-gapped environment. The airgap server has no external connectivity requirements. You can upgrade the airgap server with a new Airgap deployment or an upgrade patch.

The Airgap server consists of the following main components along with a set of scripts for easy installation and configuration.

  • NGINX is used to request files from the local datastore or harbor environment.

  • Harbor is the container registry that hosts the OCI images required by VMware Telco Cloud Automation and VMware Tanzu Kubernetes Grid.

  • Reposync synchronizes the air-gapped repository with the upstream repository located on the internet.

  • BOM Files are used by the VMware Telco Cloud automation platform.

Design Recommendation

Design Justification

Design Implication

Where required, leverage the air-gapped solution to eliminate direct Internet connectivity requirements.

  • Provides a secure environment for the Tanzu Kubernetes Grid deployment as external access is restricted.

  • Speeds up the Tanzu Kubernetes Grid deployment process by accessing the local infrastructure, without Internet connectivity.

Requires the airgap server to be deployed, maintained, and upgraded over time.

The typical Airgap server deployment requires an Internet-accessible environment. After the server is created, it can be powered off and relocated into the Telco Cloud environment. After the server is relocated, embedded scripts can be used to reconfigure the airgap server (change IP address, certificates, and so on).

Figure 1. Airgap Deployment Scenario
Airgap Deployment Scenario

You can deploy multiple Airgap servers. The initial Airgap can reside within a DMZ and can be used to sync (as required) to the internet to download new packages and components. A secondary Airgap server can be deployed into the production environment and can be synched with the Airgap server in the DMZ, eliminating the need for internet connectivity in the production environment.

If a proxy server is used, some of the URLS get redirected. For the Airgap server to sync appropriately, add the following FQDNs and wildcards to the proxy whitelist:

vmwaresaas.jfrog.io

packages.vmware.com

projects.registry.vmware.com.

s3.amazonaws.com