LinkedIn
Twitter
TL;DR the new Apigee Terraform Modules Repository on GitHub provides end to end examples and reusable modules for composing Apigee deployment architectures.
Some weeks ago we introduced the first version of the Terraform Modules for Apigee Organizations and Instances in the open-source Cloud Foundation Fabric GitHub Repository. The goal of these modules is to simplify the provisioning of Apigee Resources and abstract away some Apigee specific dependencies like the relationships between an Apigee Organization, Environments, and Environment Groups that are required by the Google Terraform Provider. With the help of these modules you are able to provision an Apigee X instance that can receive traffic on an internal endpoint and immediately start working with the Apigee platform. For many real-world scenarios and more elaborate PoCs however, these modules will need to be augmented with other resources that provide the required cryptographic key management or networking components to securely route external traffic to the internal Apigee instance endpoint.
Defining a functioning end to end architecture for integrating Apigee with all the other necessary components requires knowledge in the areas of networking, cryptography and security. For this reason having access to reference architectures that can be adapted to customer’s needs can go a long way to simplify the required setup. In our new Apigee Terraform Modules repository we therefore provide additional terraform modules and example configurations that make it easier to provision fully functional end to end architectures for Apigee. The example configurations are meant to serve as reference architectures such that they can be easily adapted according to customer requirements e.g. by configuring the IP address ranges and regions that should be used by the Apigee runtime. The example configurations also illustrate the modular nature of the Apigee terraform modules and the augmenting Cloud Foundation Fabric modules. By following the same modular composition pattern you are able to build your own modules that switch out specific pieces to better align with your own existing infrastructure or requirements.
Example Configuration Overview
Based on our experience across our customer engagements we have identified some of the most common Apigee deployment topologies and built end to end samples for them. Note that the availability features of the GCP networking components and Apigee are as of the time of writing of this article and might have changed. Treat the following descriptions of the example configurations as an illustration only and refer to the documentation in the repository for the latest version.
Apigee X - Basic Setup
This module configures a complete Apigee X Organization with one or more instances as well as the required components for key management and service networking. It can be used to configure Apigee Deployments for EVAL or PAID scenarios and is the foundation for more elaborate architecture patterns.
An example configuration for a simple Apigee Organization with two environments and a runtime instance can be configured like this:
ax_region = "europe-west1"
apigee_environments = [ "test1", "test2" ]
apigee_envgroups = {
test = {
environments = ["test1", "test2"]
hostnames = ["test.api.example.com"]
}
}
apigee_instances = {
euw1-instance = {
region = "europe-west1"
cidr_mask = 22
environments = ["test1", "test2"]
}
}
network = "apigee-network"
peering_range = "10.0.0.0/22"
If you want to deploy a PAID Apigee X Organization you only need to modify the instance’s cidr_mask block as well as the size of the peering_range for the service networking.
Apigee X - External HTTPS Load Balancer
For use cases where the APIs provided by Apigee need to be consumed from outside the VPC you need to provide an external Load Balancer and route traffic to the internal endpoints. We created an end to end module to automate the provisioning of all the necessary components to achieve an external exposure. In addition to provisioning the basic Apigee X organization and instances as described above, the module also creates a set of network bridges, load balancers and trusted, Google-managed TLS Certificates. To reduce complexity and the requirement to register a domain name the module relies on a DNS service to decode a hostname that contains the external load balancer IP address.
The configuration for such this module only requires the additional specification of the subnet that should be used to host the network bridges.
ax_region = "europe-west1"
apigee_environments = [ "test1", "test2" ]
apigee_envgroups = {
test = {
environments = ["test1", "test2"]
hostnames = ["test.api.example.com"]
}
}
apigee_instances = {
euw1-instance = {
region = "europe-west1"
cidr_mask = 22
environments = ["test1", "test2"]
}
}
network = "apigee-network"
peering_range = "10.0.0.0/22"
# Additional Configuration for Exposure
exposure_subnets = [
{
name = "apigee-exposure"
ip_cidr_range = "10.100.0.0/24"
region = "europe-west1"
secondary_ip_range = null
}
]
Apigee X - Internal Network Load Balancer with Passthrough TLS and Client Authentication
In some use cases customers wish to expose their Apigee endpoints only to the internal VPC and not allow external ingress traffic. Based on the zero trust model and a multi-layered security approach they also want to authenticate clients i.e. the API consumers based on mutual TLS (mTLS). The basic deployment option as described initially would suffice to expose an internal endpoint but doesn’t allow for mTLS.
To implement the mTLS authentication, we replace the network bridges with envoy proxies that can validate the client certificate of the API consumer. For high availability, we front the Envoy proxies with an internal network load balancer. As internal network load balancers are regional the setup is replicated for each region where we provision an Apigee instance.
The configuration in this case also requires the CA certificate to validate the client traffic as well as the TLS credentials for TLS termination at the Envoy proxy.
ax_region = "europe-west1"
apigee_environments = [ "test1", "test2" ]
apigee_envgroups = {
test = {
environments = ["test1", "test2"]
hostnames = ["test.api.example.com"]
}
}
apigee_instances = {
euw1-instance = {
region = "europe-west1"
cidr_mask = 22
environments = ["test1", "test2"]
}
}
network = "apigee-network"
peering_range = "10.0.0.0/22"
# Additional Configuration for Exposure
exposure_subnets = [
{
name = "apigee-exposure"
ip_cidr_range = "10.100.0.0/24"
region = "europe-west1"
secondary_ip_range = null
}
]
# Additional Configuration for mTLS
ca_cert_path = "./certs/certs/apigee-test-CA.pem"
tls_cert_path = "./certs/certs/servercert.pem"
tls_key_path = "./certs/certs/serverkey.pem"