IPAM Automation

Andi Lamprecht ·2026-05-11· 3 min read· Accepted

IPAM Automation

Status: Accepted

Deciders: sybil.melton@droneup.com, eric.brookman@droneup.com

Date: February 19, 2024

Technical Story

Document NetBox automation for Terraform workspaces and NetBox API tokens

Context and Problem Statement

• NetBox is the chosen IPAM solution. We would like to automate the deployment,
  as well as the ability to request prefixes and addresses with a Terraform provider that is already available.
• As an ITOps Comms engineer,
  I need my IPAM automation to be scalable
  so that the size of the Terraform state does not become too large when the enterprise scales at a rapid pace.
• There are already instances (github automation) where the plans and applies take a very long time because the size of the state file. We do not want a large GCP implementation to affect the main configuration or NetBox physical location automation and vice versa.
• If we split up the implementation into multiple workspaces now, we do not have to try to split it up later. This also allows us to more easily assign separate API tokens for each workspace, i.e. dev & prod, read-write for ITOps repos & read-only for shared infrastructure.

Decision Drivers

• Scalability
• Self service

Considered Options

1. Multiple TFC workspaces
2. Single TFC workspaces

Decision Outcome

Multiple TFC workspaces

The following folders and corresponding workspaces will be added as the initial rollout to the it-ipam-automation:

Only the workspaces for the it-ipam-automation repo will have a read-write token.

A read-only token will be available in the droneup-shared-infrastructure workspaces so that once a prefix is available, users can use a Terraform data source to simply retrieve the reference to the subnet.

• Good, because additional folders can be added to the it-ipam-automation repo as additional needs for NetBox components grow.
• Good, because the folder pattern follows what is already in place for other workspaces (pe-github-automation, it-okta)
• Bad, because more complex
• Bad, because every workspace that needs access will need to add an API token as a secret

Consequences

Each workspace that would like to connect to the NetBox service can request an API token.

Pros and Cons of the Options

Single TFC workspaces

• Good, because simpler design
• Bad, because state files may become very large in the future, when considering the unknown number of DroneUp locations

Supporting Information

• Example relationship diagram for GCP
• Terraform example
• Example DroneUp IPAM Implementation