I might drink this beer


I am a jack of some trades and definitely a master of none. That doesn't mean I haven't had some experience and a handful of opinions to go with it. All of the opinions expressed here are my own and do not reflect the views of my employer or the voices beamed into my head from the sophons in the sky. For now I'll start with things I like to drink

View My GitHub Profile

Encrypted chat via Keybase markjmenger


9 June 2021

F5 Terraform modules in airgapped environments - up the game

by Mark J Menger


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.

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 GitHub clone url

  2. [Internet Workstation] Export the remote url for the source repository
    export MODULEGITHUBURL="git@github.com: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="git@github.com: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


  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.

tags: big-ip - automation - hashicorp - terraform - devops