Getting Started With Alkira And Terraform (Part 2)

In Part 1, we started with a scalable foundation that can adapt over time as the business grows and adjusts to changing markets. With Alkira’s Network Cloud, we take a cloud native approach in enabling our customer’s transformation. No appliances need to be provisioned in remote VPCs or VNets, and no agents need to be installed on workloads. Getting started is as easy as kicking off a build pipeline. For Part 2, let’s connect some networks from AWS, Azure, and GCP.

Scenario

#

In Part 1, we set up a hypothetical Line of Business called LoB - Digital, which has the following network requirements:

• Cloud Native applications will be deployed in AWS; Application lifecycle requires DEV, TEST, STAGE, and PROD VPCs
• Azure gets the same network types as AWS for cloud native workloads; In addition, Azure will also get a MIGRATION VNet which will act as a landing zone for workloads being migrated from on-premises
• A new product surrounding data analytics is being established, and the product team wants to leverage GCP; The product is not production-ready, so only DEV, TEST, and STAGE VPCs are required

Since no appliances get installed inside cloud networks, how does Alkira interface with the cloud providers? Alkira takes the cloud native approach of using existing authentication methods in each cloud. For instance, in AWS, this would be IAM Policies and with Azure, Service Principals. Most enterprises are already interacting with the cloud this way today, so integrating with their existing automation + pipeline strategy is seamless.

Resources

#

We will be using the following Terraform Resources in this post:

Connecting The Cloud

#

Alkira’s Terraform Provider does quick work of connecting cloud networks to our foundation. The following snippet will connect an Azure VNet, place it in the group we provide, and attach a billing tag.

azure_connector.tf

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

// Source credential
data "alkira_credential" "credential" {
  name = var.credential
}

// Source billing tag
data "alkira_billing_tag" "tag" {
  name = var.billing_tag
}

// Provision connector
resource "alkira_connector_azure_vnet" "connector" {

  // Azure values
  name            = var.vnet
  azure_vnet_id   = var.vnet_id
  azure_region    = var.region

  // Alkira values
  cxp             = var.cxp
  size            = var.size
  group           = var.group
  segment_id      = var.segment_id
  billing_tag_ids = [data.alkira_billing_tag.tag.id]
  credential_id   = data.alkira_credential.credential.id
  
  // Route table option
  routing_options = var.route_option

}

Organizing Things

#

HashiCorp recommends One Workspace Per Environment Per Terraform Configuration. Since we are provisioning and connecting so many networks + environments across all three cloud providers, I simplified a few things. With Azure, for example, repositories map to Workspaces like this:

Provisioning

#

Like Part 1, we will use Terraform Cloud for provisioning. A successful merge to our main branch will automatically trigger a plan, and apply.

Validation

#

Twelve VPCs/VNets across three public clouds couldn’t be easier! By default, networks connected to our corporate segment have full-mesh connectivity to each other. Later in this series, we will build automated policies to work with our groups that produce some logical micro-segmentation.

Conclusion

#

For Part 1, we built a scalable foundation, and in this post, we connected networks from AWS, Azure, and GCP to it. One area where enterprises struggle is securely connecting their data center or remote offices to the cloud. This use-case often maps back to migrating workloads to the cloud or running Tiered Hybrid Workloads. In Part 3, we will connect a few on-premises networks into the mix to see how Alkira can help solve this problem.