Kong Konnect Runtime Instance and Konnect-KIC AWS EKS Terraform Blueprints AddOns
Senior Partner Developer, Kong
With our AWS partnership, we jointly created two Kong Konnect AWS EKS Terraform Blueprints AddOns, eks-blueprint-konnect-runtime-instance and eks-blueprint-konnect-kic, to help bootstrap your Kong Konnect instances on EKS.
In this post, we'll discuss what AWS EKS Blueprints AddOns for Terraform are and their benefits. We'll also demo the Kong Konnect AddOns we’ve built out.
When it comes fundamentally to standing up a production-ready EKS cluster, there’s more to it than meets the eye: deploying drivers, integrating with AWS Secrets Manager, integrating with AWS logging infrastructure, and understanding the AWS IAM Roles for Service Accounts (IRSA) integration. The AWS EKS Blueprints in Terraform framework was designed to solve these needs by providing guardrails while adhering to community-wide infrastructure as code standards.
AWS EKS Blueprints AddOns is an AWS-developed framework based on Terraform and Helm to easily bootstrap EKS clusters. It comes with native EKS Addons, such as AWS CNI, AWS EBS CSI driver, and the most popular third-party technologies such as Kong Konnect. The objective of the framework is to get you to a production-ready environment quickly by simplifying and consolidating Day 2 operations with AWS best practices built into the AddOns themselves.
Overall, AWS EKS Blueprints for Terraform helps customers get a production-ready EKS Cluster as quickly as possible.
How do the Kong Konnect Blueprints AddOns work?
The Kong AddOns deploy Kong with either the Kong Gateway data plane independently or alongside Kong Ingress Controller, both of which integrate with Kong Konnect.
Under the hood, it’s still the Kong Helm chart deployed by the AWS EKS Add-On framework. However, what we’ve done is create an AWS-specific default Helm configuration for you, so that all you need to provide is a small subset of required values — runtime group ExID, the region, etc. Bear in mind, you still have the opportunity to override the defaults, if required.
But the Kong modules are more than just another deployment mechanism for the Kong data planes; they also prescribe to AWS EKS best practices. For Kong, this means providing a production-ready mechanism for managing the data plane certificates.
Kong Konnect uses a hybrid deployment model — Kong Konnect acts as the control plane and each gateway is a data plane with an mTLS connection to Konnect (See Konnect Architecture for more details.) As such, each data plane needs the certificates, stored as secrets in Kubernetes, to complete the mutual TLS handshake.
To achieve this, the Kong Konnect Blueprints modules install the External Secrets Operator, which is also a part of the add-on ecosystem. Then they configure the necessary AWS IRSA privileges and the necessary CRDs in order to leverage AWS Secrets Manager. With this integration in place, the data plane TLS certificates stored in AWS Secrets Manager are automatically injected as a Kubernetes Secret.
Overall, the Kong modules will do the following:
Configure AWS IRSA with appropriate IAM policies needed by the External Secrets Operator to reach AWS Secrets Manager
Deploy the External Secrets Operator via the same EKS Blueprints framework
Deploy External Secrets CRDs needed to retrieve the data plane certs in AWS Secrets Manager → that triggers the creation of the Kong TLS Kubernetes Secret
Deploy Kong Gateway or Kong Ingress Controller
There are a few prerequisites to be aware of before getting started.
First, you need an EKS cluster. Don’t worry. The AWS team has a very robust Terraform module for that as well, AWS EKS Terraform module, and it will run inline without addon modules.
Secondly, there are a few Kong Konnect prerequisites that need to be in place.
The runtime group needs to be created in advance. This will depend on the type of data plane you choose to use: Kong Gateway or Kong Ingress Controller.
The data plane certificates need to be pushed up to the runtime group and pushed to AWS Secrets Manager in the same AWS region as the EKS cluster. These activities can be done either via the Kong Konnect and AWS console or the respective Konnect API and AWS CLI.
With those criteria in place, you’re ready to bootstrap your EKS cluster with Kong Konnect.
Let’s install Kong Ingress Controller to Kong Konnect
The name of the game is how fast we can automate provisioning an EKS cluster with Kong Ingress Controller to Kong Konnect. I’m going to bet we’ll be up and running in about 15 minutes.
Create and upload data plane certs to the Runtime Group and AWS Secrets Manager.
Log into Kong Konnect, navigate to Runtime Manager, and create a Kong Ingress Controller Runtime Group.
And we can see below I’ve created a new Runtime Group called KIC Demo:
Now, create the data plane certificates.
We put together a CLI tool (kong-konnect-runtime-cert-generator) to get you jump-started here. The CLI tool is going to create a self-signed cert, push it to the new Kong Konnect Runtime Group and also to AWS Secrets Manager:
The output should be something similar to below. Save this output — you’ll need it for the next step.
OK! Now for the finale. In the example repo, navigate into the konnect-kic directory. The Terraform script does three main things:
Creates an AWS VPC
Creates the EKS Cluster using the AWS Terraform module
Creates the Kong Konnect KIC instance with our EKS add-on module
To run the Terraform script, create a terraform.tfvars file with the following output from the CLI tool:
And now run the Terraform with `terraform apply`:
And that is it. KIC is Fully Operational.
We really enjoyed this project, and we’re looking forward to the community’s reaction.
Give it a go and let us know what you think! hould we cover more Day 2 Operations? Are there more configurations you’d like to see? Don’t hesitate to create a GitHub issue.
In the meantime, we have several more examples to get you kickstarted — Fargate, AWS Graviton — and there’s a video if you’d rather watch.