Skip to content

Latest commit

 

History

History

ipam-autopilot

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

IPAM Autopilot

IPAM Autopilot is a simple Docker Container and Terraform provider that allows you to automatically manage IP ranges for GCP VPCs.

It connects to Cloud Asset Inventory to also retrieve already existing subnets and ranges, in order to allow for a mixed usage.

Architecture showing Terraform, CloudRun, CloudSQL and Cloud Asset Inventory

IPAM Autopilot consists of two parts, a backend service that provides a Rest API and a terraform provider.

The provider uses application default credentials to authenticate against the backend. Alternatively you can directly provide an identity token via the GCP_IDENTITY_TOKEN environment variable to access the Cloud Run instance, the audience for the identity token should be the domain of the Cloud Run service.

IPAM Autopilot Backend

The infrastructure folder contains a sample Terraform setup with which the IPAM Autopilot backend can be deployed to CloudRun. The required APIs are created during the deployment. The deployment instructions also provision a small CloudSQL instance as well. The container is build as part of the deployment. The Dockerfile containing the build instructions is at the top level, since the container needs files that are generated during the infrastructure deployment.

The following GCP services are used as part of the deployment, and might cause cost:

A self-contained registry for discovery of the provider is part of the backend and the deployment. It uses GCS with signed URL for providing the provider binaries. Please be aware, this approach towards Terraform provider registry can be brittle.

You can also disable the automatic database migration using DISABLE_DATABASE_MIGRATION if you prefer to do the database migration manually. Therefore you have to set the value to TRUE. Or in Terraform use the disable_database_migration variable.

Deploying

In order to use the provider later from terraform we need to provide the providers binaries in a way that Terraform can resolve them. For this we need to first build the provider binaries. The Terraform deployment instructions will use the binaries to bundle the provider for discovery by the Terraform clients. For this you will need to have PGP set up so that the checksum file that accompanies the binaries can be signed.

The infrastructure deployment takes the following variables, you can either set them via environment variables TF_VAR_ or in a .tfvars file.

Variable Default Value Description
organization_id ID of the organization, that holds the subnets that are queried via Cloud Asset Inventory.
project_id Project ID of the project to which the IPAM Autopilot should be deployed.
region europe-west1 GCP region that should contain the resources.
artifact_registry_location europe Location for the Artifact Registry location, containing the Docker container image for the IPAM Autopilot backend.
container_version 1 Version of the container, since the container is build by the infrastructure automation, you can use this variable to trigger a new container image build.
provider_binary_folder ../provider/bin The folder relative to the infrastructure folder containing the binaries of the provider, is generated by make release
provider_version 0.1.0 Version of the provider, needs to match the version in the Makefile
disable_database_migration FALSE Whether the CloudRun service should automatically migrate the databse

In order to deploy, you will need to execute the following commands.

  1. Build the Terrafrom provider by calling make release from the provider folder.
  2. Deploy the infrastructure terraform init and terraform apply

Setting up the local Terraform setup

In order to be able to download the provider from the CloudRun service, the Terraform CLI will need to authenticate against CloudRun. You will need to setup your ~/.terraformrc file so that it conaints a valid identity token for a user with roles/run.invoker. You can obtain that token with gcloud auth print-identity-token and manually create the entry in your terraformrc file.

credentials "<cloud run hostname>" {
  token = "<identity token>"
}

Or as a condensed command echo "credentials \"<cloud run hostname>\" { \n token = \"$(gcloud auth print-identity-token)\" \n }" > ~/.terraformrc

An example configuration

Below is a Terraform example for using IPAM Autopilot

terraform {
  required_providers {
    ipam = {
      version = "0.1"
      source = "<cloud run hostname>/ipam-autopilot/ipam"
    }
  }
}

provider "ipam" {
  url = "https://<cloud run hostname>"
}

resource "ipam_ip_range" "pod-ranges" {
  range_size = 22
  name = "gke services range"
}

output "range" {
  value = ipam_ip_range.pod-ranges.cidr
}

Subnet selection logic

IP Subnet selection logic

A simple example might shed some light on how the selection works. Let's assume we want a /24 range in the 10.0.0.0/8 subnet. In the IPAM Autopilot database, the subnets 10.0.0.0/28 and 10.0.0.16/28 are allocated. From Cloud Asset Inventory a VPC with a subnet 10.0.0.64/26 is discovered as well. This means that the subnet 10.0.0.0/24 will collide with this subnets, so IPAM Autopilot will allocate 10.0.1.0/24.