Managing Kong with Terraform

One of the superpowers of Kong Gateway that its users most appreciate is its declarative configuration management capabilities, facilitated by the decK command line tool. Declarative configuration enables you to manage your Kong Gateway configuration using GitOps practices, including federated configuration management, mandatory review processes, and automated policy enforcement via CI/CD.

This is a great start, but it’s not enough anymore. With the advent of Kong Konnect, Kong’s next-generation API management platform, there are a lot more entities that need configuration. You can deploy Kong Mesh control planes, publish API Products, configure your Developer Portal, and more. Declarative configuration only works if all of your configuration is declarative. 

The Konnect platform provides a whole set of new capabilities that need to be managed declaratively. Being able to configure which APIs are published to which Developer Portal, and which branding that portal should have is a key workflow for API Product owners. Being able to do it declaratively is a requirement when it comes to operating at scale.

The Kong team considered expanding decK to manage Konnect entities in addition to Gateway entities, but it didn’t feel right to us. decK manages entities that live inside a single Kong Gateway control plane, and adding support to create control planes or manage organization settings was confusing to our users. So we went back to the drawing board and looked for alternatives. 

Why we chose Terraform

Many of our users are already using Terraform to manage their infrastructure on AWS, Azure, and GCP. Kong is infrastructure too, so why don’t we let you manage Kong Gateway and all other entities above it at the Kong Konnect level with Terraform? This allows users to use a tool that they’re already familiar with.

Enabling customers to practice GitOps is a north star for Kong, and tools such as Atlantis allow us to ship Terraform support knowing that GitOps is at the heart of every successful workflow. Existing Terraform users are likely to have this automation in place already, and by shipping a Terraform provider we slot right into that existing infrastructure. All the benefits with none of the CI/CD toil.

Introducing terraform-provider-konnect GA

It’s with great pleasure that we announce that terraform-provider-konnect is now generally available. We’ve been using it internally and with our beta testers for the last six months, and I’m not exaggerating when I say that 90% of the projects I see day to day are using the Terraform provider to manage their Konnect configuration.

The provider has already been installed over 7,500 times, and supports everything you need to get started with Konnect:

• Manage Gateway and Mesh control planes ✅
• Manage organization teams and roles ✅
• Create API Products and publish them to a Developer Portal ✅
• Manage Kong Gateway entities such as Services, Routes, and Plugins using Terraform ✅
• Deploy Dedicated Cloud Gateways and Serverless Cloud Gateways ✅
• And more! See the provider documentation for a full list of resource

What about decK?

You might be wondering what the future looks like for decK now that we have Terraform support. decK isn’t going anywhere. It’s still a strategic tool for Kong Gateway, and the declarative configuration format that decK uses forms the basis for our whole APIOps story.

We see Terraform and decK co-existing indefinitely. There are a lot of things that you can do with decK that you can’t do with Terraform:

• Convert an OpenAPI specification to Kong declarative configuration
• Automatically update the declarative configuration with deck file patch
• Validate configurations (e.g., a read_timeout must be set) using deck file validate
• Enforce platform-level configuration using deck file merge

However, we know that many of you want to use Terraform but also benefit from decK’s APIOps capabilities. That’s why we’ve built deck file kong2tf, which takes a decK declarative configuration file and generates Terraform manifests automatically. This means you have two options when it comes to APIOps:

1. Use Terraform to provision control planes in Konnect, then decK to sync your config (you can even run deck from Terraform).
2. Use deck file kong2tf to convert your declarative config to Terraform and use Terraform for everything

If I were looking to adopt Terraform today, I’d use deck file kong2tf to provide a complete pipeline that means that the development team only has to write an OpenAPI spec. And thanks to the power of openapi2kong and kong2tf the infrastructure team gets to interact with Terraform manifests that they’re comfortable with.

One more thing

Some of you may be thinking, “But I don’t use Konnect!” If that’s the case, I have two things for you:

1. You should! Kong Konnect takes all the pain out of managing your control plane and database.
2. We haven’t forgotten about on-prem users.

In addition to the terraform-provider-konnect GA release, I’m excited to share that we have a beta release of terraform-provider-kong-gateway for you all to test.

The two providers are almost identical, except that the on-prem provider doesn’t require you to specify a control plane ID on your entities. Other than that, all the same Kong Gateway resources can be managed using identical Terraform resources.

Get started with Terraform and Kong

Kong and Terraform are a great match. Terraform helps configure critical infrastructure and prevent configuration drift, and Kong Gateway is a key part of that infrastructure.

If you want to try it out, the quickest way to get started is to create a free Konnect account and use terraform-provider-konnect.

If you’re an existing on-prem user, you can use terraform-provider-kong-gateway to manage your deployment.

No matter which provider you choose, we’d love to hear from you via GitHub about what you’re doing with Kong Konnect or on-prem.