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.
First, go ahead and clone the examples github repo.
Let’s take care of the prerequisites:
- Create a KIC-based Runtime Group in Konnect.
- 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.