F5 Terraform modules in airgapped environments - up the game

Introduction

I previously released a series of steps for using F5’s Terraform modules in an “airgapped” environment. However, those instructions included the assumption that you have access to a workstation that has access to both the public internet and the airgapped network. So, not really airgapped. In this document, we’ll include some additional steps that require “sneaker-net” access between two workstations. We’ll refer to the public internet-facing workstation as Internet Workstation and the airgapped network-facing workstation as Airgapped Workstation.

IT Industry research, such as Accelerate, shows improving a company’s ability to deliver software is critical to their overall success. The following key practices and design principles are cornerstones to that improvement.

• Version control of code and configuration
• Automation of Deployment
• Automation of Testing and Test Data Management
• “Shifting Left” on Security
• Loosely Coupled Architectures
• Pro-active Notification

F5 has published Terraform modules on GitHub.com to help customers adopt deployment automation practices, focused on streamlining instantiation of BIG-IPs on AWS, Azure, and Google. Using these modules allows F5 customers to leverage their embedded knowledge and expertise.

But we have limited access to public resources

Not all customer Terraform automation hosts running the CLI or enterprise products are able to access public internet resources like GitHub.com and the Terraform Registry. The following steps describe how to create and maintain a private airgapped copy of F5’s modules for these secured customer environments.

Creating your airgapped copy of the modules you need

This example uses a personal GitHub account as an analog for airgapped target. So, we can’t use the fork feature of github.com to create the copy.

1. [Internet Workstation] Retrieve remote url for one of the modules at F5’s devcentral GitHub account

2. [Internet Workstation] Export the remote url for the source repository

   export MODULEGITHUBURL="[email protected]:F5Networks/terraform-aws-bigip-module.git"
   

3. [Internet Workstation] Clone the module source repository
   This example uses F5’s module for AWS

   git clone $MODULEGITHUBURL
   

4. [Internet Workstation] Prepare bundle to transport to airgapped network
   Note: In the example below we’re pushing the main branch. In some older repositories the primary repository branch may still be named master.
   Note: Pushing the tags into the airgap repository is critical to version management of the modules.

   # get the latest from the origin repository
   git fetch origin
   # create a bundle file with the main branch and all tags
   git bundle create module.bundle main --tags
   

5. [Internet Workstation] Copy file to a secure transport
   This is going to be different between organizations and environments. You should verify that your transport is compliant with organization policy.

6. [Airgapped Workstation] Retrieve file from secure transport

7. [Airgapped Workstation]

git fetch /path/to/module.bundle main:localinterimbranch

1. Create repository on target airgapped host
   Follow the appropriate directions for the airgapped hosted Git (BitBucket, GitLab, GitHub Enterprise, etc.). And, retrieve the remote url for this repository.

2. Export the remote url for the airgapped repository
   Note: The airgapped repository is still empty at this point.
   Note: The example is using github.com, your real-world use will be using your internal git host

   export MODULEAIRGAPURL="[email protected]:myteamsaccount/localmodulerepo.git"
   

3. Add the target repository as an additional remote
   Again, we’re using F5’s AWS module as an example. We’re using the remote url exported as MODULEAIRGAPURL to create the additional git repository remote.

   cd terraform-aws-bigip-module
   git remote add airgap $MODULEAIRGAPURL
   

Using your airgapped copy of the modules

1. Identify the module version to use
   This lists all of the tags available in the repository.

   git tag
   

   e.g.

   0.9.2
   v0.9
   v0.9.1
   v0.9.3
   v0.9.4
   v0.9.5
   

2. Review new versions for environment acceptance
   At this point, your organization should perform any acceptance testing of the new tags prior to using them in production environments.

3. Source reference in Terraform module using git
   Unlike using the Terraform Registry, when using git as your module resource the version reference is included in the source url. The source reference is the prefix git:: followed by the remote url of the airgap repository, followed by ?ref=, finally followed by the tag identified in the previous step.
   Note: We are referencing the airgap repository, NOT the origin repository.
   Note: It is highly recommended to include the version reference in the url. If the reference is not included in the url, the latest commit to the default branch will be used at apply time. This means that the results of an apply will be non-deterministic, causing unexpected results, possibly service disruptions.

   module "bigip" {
    source = "git::https://github.com/myteamsaccount/localmodulerepo.git?ref=v0.9.3"
    ...
   }
   

   Check out Terraform for more detailed configuration requirements

4. Source reference in Terraform module using a private Terraform registry
   If you have an instance of Terraform Enterprise it’s possible to connect the private git repository created above to the private module registry available in Terraform Enterprise.

   module "bigip" {
    source = "privateregistry/modulereference"
    version = "v0.9.3"
    ...
   }
   

Maintaining your airgapped copy of the modules

1. On-going maintenance of private respository
   Once the repository is established, perform the following actions whenever you want to retrieve the latest versions of the F5 modules. If you have a registry enabled on Terraform Enterprise, it should update automatically when the private repository is updated.

   # get the latest from the origin repository
   git fetch origin
   # push any changes to the airgap repository
   git push airgap main
   # push all repository tags to the airgap repository
   git push --tags airgap
   

2. Review new versions for environment acceptance
   When your private repository is updated, do not forget to perform any acceptance testing you need to validate compliance and compatibility with your environment’s expectations.

Other references

Installing and running iControl extensions in isolated GCP VPCs - Matt Emes covers how to install and operate iControl extensions in an air-gapped GCP environment.

Deploy BIG-IP on GCP with GDM without Internet access - Gert Wolfis covers how to use the Google Deployment Manager (GDM) to deploy BIG-IPs in an air-gapped GCP environment.