Automate Oracle Cloud Infrastructure VCN Peering with Terraform

May 23, 2018 | 3 minute read
Changbin Gong
Principal Product Manager and Cloud Advisor
Text Size 100%:

The goal of this blog post is to show how to automate Oracle Cloud Infrastructure VCN peering setup using Terraform. 

Oracle Cloud Infrastructure VCN peering is the process of connecting multiple virtual cloud networks (VCNs). You can use VCN peering to privately connect one VCN to another, so that traffic does not traverse the internet. 

To setup VCN peering manually,  it requires multiple steps with creation of several different resources.  So, this blog post describes how to automate the VCN peering setup using Terraform.    

The recommended Terraform and Oracle Cloud Infrastructure Terraform Provider versions are:

  • Terraform:  v0.11.7
  • OCI Terraform Provider:  v2.1.8   (This version also supports remote VCN peering.)

Local VPN peering across different tenancies is one of the most challenging setups since it requires different tenancies and very complex group policies. I use this example to describe how to use Terraform to automate the VCN peering setup.

For local VCN peering with Terraform, a key resources is the "oci_core_local_peering_gateway" (LPG). To establish a local VCN peering connection, the LPG of one tenancy will be a requestor and initiate the peering connection request with another LPG as an acceptor that is in a different tenancy.  As LPG resources are across tenancies, we need to define two different "oci" Terraform providers in the Terraform code. 

For instance, one "oci" provider is defined as a requestor, the other is defined as an acceptor. 

provider "oci" {

  alias = "requestor"

  region = "${var.requestor_region}"

  tenancy_ocid = "${var.requestor_tenancy_ocid}"

  user_ocid = "${var.requestor_user_ocid}"

  fingerprint = "${var.requestor_fingerprint}"

  private_key_path = "${var.requestor_private_key_path}"

}

provider "oci" {

  alias = "acceptor"

  region = "${var.acceptor_region}"

  tenancy_ocid = "${var.acceptor_tenancy_ocid}"

  user_ocid = "${var.acceptor_user_ocid}"

  fingerprint = "${var.acceptor_fingerprint}"

  private_key_path = "${var.acceptor_private_key_path}"

}

 

To create resources on each tenancy, you must use the corresponding "oci" provider. 

For instance, to create an LPG resource in the requestor tenancy, specify:

resource "oci_core_local_peering_gateway" "requestor" {

  depends_on = ["oci_identity_policy.requestor_policy"]

  provider = "oci.requestor"

  compartment_id = "${var.requestor_compartment_ocid}"

  vcn_id = "${oci_core_vcn.requestor_vcn1.id}"

  display_name = "requstor_localPeeringGateway"

  peer_id = "${oci_core_local_peering_gateway.acceptor.id}"

}

Peering between two VCNs requires explicit agreement from both parties in the form of Oracle Cloud Infrastructure Identity and Access Management (IAM) policies that each party implements for their own VCN's compartment or tenancy. In our example, where the VCNs are in different tenancies, each administrator must provide their tenancy OCID and specify special policy statements to enable the peering.

For instance, the requestor policies are defined as:

resource "oci_identity_policy" "requestor_policy" {

  provider = "oci.requestor"

  name = "requestorPolicy"

  description = "Requestor policy"

  compartment_id = "${var.requestor_tenancy_ocid}"

  statements = ["Define tenancy Acceptor as ${var.acceptor_tenancy_ocid}",

                "Endorse group Administrators to manage local-peering-to in tenancy Acceptor",

                "Endorse group Administrators to associate local-peering-gateways in compartment         

                    ${var.requestor_compartment_name} with local-peering-gateways in tenancy Acceptor"

               ]

}

The acceptor policies are defined as:

resource "oci_identity_policy" "acceptor_policy" {

  provider = "oci.acceptor"

  name = "acceptorPolicy"

  description = "Acceptor policy"

  compartment_id = "${var.acceptor_tenancy_ocid}"

  statements = ["Define tenancy Requestor as ${var.requestor_tenancy_ocid}",

                "Define group RequestorGrp as ${var.requestor_administrators_group_ocid}",

                "Admit group RequestorGrp of tenancy Requestor to manage local-peering-to in compartment

                    ${var.acceptor_compartment_name}",

                "Admit group RequestorGrp of tenancy Requestor to associate local-peering-gateways in tenancy

                    Requestor with local-peering-gateways in compartment ${var.acceptor_compartment_name}"

               ]

}

Please note, the resource "oci_identity_policy"  depends on the home region.   You need to ensure that the region of "oci" provider is the home region of the corresponding tenancy for this "oci_identity_policy". 

Finally, to enable communication between VCNs through the local VCN peering connection, you need to update the VCN's routing to enable traffic between the VCNs. The route rule specifies the destination traffic's CIDR and that your LPG is the target. Your LPG routes the traffic that matches that rule to the other LPG, which in turn routes the traffic to the next hop in the other VCN.

For instance,  the resource "oci_core_route_table" for requestor is defined as:

resource "oci_core_route_table" "requestor_route_table" {

  depends_on = ["oci_identity_policy.requestor_policy"]

  provider = "oci.requestor"

  compartment_id = "${var.requestor_compartment_ocid}"

  vcn_id = "${oci_core_vcn.requestor_vcn1.id}"

  display_name = "requestorRouteTable"

  route_rules {

    cidr_block = "${var.acceptor_cidr}"

    network_entity_id = "${oci_core_local_peering_gateway.requestor.id}"

  }

}

 

 

 

We hope that this blog post made it simple to automate the VCN peering connection setup with Terraform on Oracle Cloud Infrastructure.   

Changbin Gong

Principal Product Manager and Cloud Advisor

Changbin is a high energy leader, experienced product manager and solution architect with excellent product and project management skills.  He is currently focus on building Oracle's next great cloud that operates at high scale in a broadly distributed multi-tenant cloud environment and provides with best-in-class compute, storage, networking, database, security, and an ever-expanding set of foundational cloud services. 

Show more

Previous Post

New Autonomous Platform Services, Powered by Infrastructure

Leo Leung | 2 min read

Next Post


Build a Continuous Integration pipeline using GitHub, Docker and Jenkins on Oracle Cloud Infrastructure

Abhiram Annangi | 8 min read