We’re excited to announce a new addition to our Kong Konnect EKS Blueprint Family: the Kong Konnect Mesh EKS Blueprint Add-on to deploy your Mesh Zones. Deploy your zones securely on AWS with the new Mesh Manager offering in Kong Konnect. It gives you an opinionated install of Kong Mesh to quickly ramp up on Kong Konnect’s Mesh Manager on Amazon EKS. Let’s dive in.
Earlier this year we announced two EKS Blueprint Add-ons:
(You can check out our quickstart for more on these add-ons.)
Today, we're releasing a new add-on into the Kong Konnect fold: the Kong Konnect EKS Blueprint Add-on for Mesh Zones.
The purpose of the add-on is to provide an express lane for deploying and leveraging Kong Konnect’s Mesh Manager / Kong Mesh offering on EKS.
It provides an opinionated install of the Mesh Zones to quickly ramp up on the technology on Amazon EKS, while seamlessly integrating with AWS Secrets Manager and leveraging Terraform as the Infrastructure as Code best practices.
Before diving into what the add-on does, it's important to understand the architecture pattern of Kong Mesh and the Mesh Manager offering in Kong Konnect.
Kong Mesh within Konnect’s Mesh Manager leverages the multi-zone deployment topology. With this model, within Mesh Manager, customers are allowed to deploy global control planes (global CP). In turn, zones are deployed into infrastructure such as EKS, ECS, or even EC2. The zones act as a remote control plane receiving their configuration from a global control plane that resides in Mesh Manager. The zone control planes will proxy configuration from the global control plane down to data planes (Kong Mesh side cars) and vice versa.
Figure 1. High-level Kong Mesh Zone Architecture
This is a bit of an oversimplification. Zones are not just proxies between the global control plane and data planes. The goal of Kong Mesh is automatic connectivity regardless of physical infrastructure barriers.
With zones in place, engineers can easily construct service meshes that can span across the zones, essentially building a hybrid service mesh. The outcome of this is interconnectivity of microservices across those zones, interoperating as if they were in one network, none the wiser.
The Kong Konnect Add-ons play a crucial role in seamlessly integrating Konnect deployments with AWS Secrets Manager via External Secrets Operator. Our add-ons are purpose-built to conform to the AWS Well-Architected Framework security principles around least privilege.
From a deployment perspective, three key attributes are required to get a zone up and running:
In the context of our add-ons, there's a necessity to securely store and closely manage access to elements like zone JWT tokens or the data plane certificates required by the Kong Gateway Add-on.
AWS Secrets Manager extends beyond mere access control functionalities, making it indispensable for any production-ready workload, with automatic secret rotation, encryption in transit and at rest, programmatic access via APIs, and auditing features.
However, AWS Secrets Manager itself doesn't directly interface with Kubernetes to deposit secrets. That’s the role of the External Secrets Operator.
The External Secrets Operator (ESO) reads and automatically injects AWS Secrets into Kubernetes clusters while ensuring fine-grain access of AWS secrets to specific service accounts.
Again, in the context of the Kong Konnect Add-ons, this integration is purpose-built for retrieving secrets for Kong — whether it be the zone JWT token or data plane certificates.
Configuring the External Secrets Operator to interface with AWS Secrets Manager requires significant prerequisite knowledge of AWS IRSA, IAM Policies, as well as the External Secrets Operator configuration itself, and how to apply it to Kong-related assets.
The add-ons streamline this process for you. Specifically in the context of the Mesh Add-on, the primary concern is hosting and retrieving the zone JWT token.
At a high level, the add-on abstracts away the three major activities (Figure 2):
Configuring AWS IRSA and IAM policies with the necessary access to the AWS secrets.
Installing the External Secrets Operator and configuring all needed CRDs to properly deposit the zone token into EKS.
Finally, deploying the Mesh zone into the EKS cluster, with the configuration necessary to integrate with a global CP residing in Mesh Manager.
Under the hood, the Kong Mesh Helm chart is deployed by the AWS EKS Add-on framework with the AWS-specific configuration abstracted away.
All that's required is a small subset of values to understand where your Konnect Mesh Manager global CP is located, and how to locate the AWS secret.
Figure 2. Mesh Zone Add-on
So, I've thrown a lot of information at you. Let’s cut to a demo to understand how to run the add-on.
There are three phases we need to run through.
There are three prerequisites that need to be in place:
Create or have an existing global CP within Konnect’s Mesh Manager
Within the global CP, create the zone name and respective zone JWT token
Host the JWT token in AWS Secrets Manager (in the same region as your EKS cluster)
To get you started, we've extended the kong-konnect-runtime-instance-cert-generator CLI tool. The CLI tool requires you to be logged into the AWS via the CLI and defaulted to the AWS Region where the EKS Cluster is deployed.
Execute the CLI cmd like below to complete the prerequisites:
The expected output should look similar to the following:
Save all these attributes for inputs to the terraform script in the next step.
One last item: navigate to AWS Secrets Manager to validate you can locate the zone token secret.
Here we're following the example found in add-on git repo.
There are numerous ways to slice and dice this, so we’ll give an abridged version here. For examples of best practices in setting up an AWS EKS cluster with the Kong add-ons, look to the examples repo for all Kong Konnect blueprints.
1. In the main.tf you will have an add-on module that looks similar to the following:
The required configuration is defined via the kong_config, any optional configuration can be passed as helm values file to the values attribute.
2. Next, we’ll create the terraform.tfvars. Here we input the CLI outputs like below:
The key takeaway from all of this is the install of a Mesh zone has been simplified down to the core attributes needed to install the zone.
Now, we’ll run `terraform apply` to deploy the zone. Let's validate our setup.
1. Let’s check pod state, execute: `kubectl get pods -n kong-mesh-system`
In this example, I have 3 zone pods, 1 egress, and 1 ingress pod. All are healthy.
2. Let’s check on the zone token secret, execute `kubectl get secret cp-token -n kong-mesh-system`:
3. Let’s validate how this token got here. Execute `kubectl get externalsecret -n kong-mesh-system ` and you'll see the external secret used by the operator to retrieve the token from AWS Secrets Manager:
Lastly, let’s make sure everything is happy in Mesh Manager. Navigate up to your Konnect Console.
In the Mesh Manager Overview Page, navigate to your Global Control Plane. Mine for this example is eks-blueprint, and you should see a list of your zones and their status. Similarly, if you view all zones, you can see more details on the zone.
Clean-up is easy. We’ll execute `terraform destroy –auto-approve`:
There you have it. From zero to hero in 30 minutes!
The purpose behind all of our Kong Konnect add-ons is to provide you with a quick and opinionated install of our products on Amazon EKS.
They're here to quickly get started with AWS best practices in mind — to abstract secrets to AWS Secrets Manager and abstract away the complexity of integrating External Secrets Operator and the corresponding AWS configuration — but still deploy Kong Mesh zones quickly.
Give the add-on a go and let us know what you think! We’re excited to have the Kong Mesh Add-on included in the family of Kong Konnect EKS Blueprint Add-ons.
"To prioritize the safety and security of the ecosystem, Kubernetes SIG Network and the Security Response Committee are announcing the upcoming retirement of Ingress NGINX . Best-effort maintenance will continue until March 2026. Afterward, there w
A quick refresher: Kong Cloud Gateways Kong Cloud Gateways are fully managed, high-performance data planes running on customer-dedicated infrastructure, orchestrated and operated by Kong through Kong Konnect . Customers can choose between: Serverle
Using Konnect Advanced Analytics for a faster real-time measurement of what your users are experiencing Earlier this year the Kong Konnect Analytics team was looking to leverage the stability and flexibility of our own Kong Gateway to handle the e
This blog addresses the common challenges organizations face with fragmented API management in Kubernetes environments and presents Kong Konnect combined with the Kong Ingress Controller (KIC) as a comprehensive solution. We'll highlight the issues
Deploying Kong Mesh on ECS The focus of this blog is to provide step-by-step instructions for deploying and configuring Kong Mesh with Kong Konnect on an AWS ECS instance so that anyone will be able to get pre-production installation of Kong Mesh st
We recently released Kong Gateway Operator 1.4 with support for managing Konnect entities from within the Kubernetes clusters. This means users can now manage their Konnect configurations declaratively, through Kubernetes resources powered by Kong
In my previous post , we discussed how to take advantage of VPA to implement automatic vertical scaling for our Konnect Data Planes. In this post, we'll focus on HPA for horizontal Kubernetes Pods autoscaling. HPA VPA docs recommend not using VPA