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.
We're very excited to announce Kong Mesh 2.12 to the world! Kong Mesh 2.12 delivers two very important features: SPIFFE / SPIRE support, which provides enterprise-class workload identity and trust models for your mesh, as well as a consistent Kuma R
Meet Emily. She’s an API product manager at ACME, Inc., an ecommerce company that runs on dozens of APIs. One morning, her team lead asks a simple question: “Who’s our top API consumer, and which of your APIs are causing the most issues right now?”
Today, we’re announcing that Kong has acquired OpenMeter , the open source and SaaS leader for real-time usage metering and billing. OpenMeter’s capabilities will be integrated into Kong Konnect, enabling usage-based pricing, entitlements, and invo
It’s been almost a year since we released our Konnect Terraform provider . In that time we’ve seen over 300,000 installs, have 1.7 times as many resources available, and have expanded the provider to include data sources to enable federated managem
In the last two parts of this series, we discussed How to Strengthen a ReAct AI Agent with Kong AI Gateway and How to Build a Single-LLM AI Agent with Kong AI Gateway and LangGraph . In this third and final part, we're going to evolve the AI Agen
In my previous post, we discussed how we can implement a basic AI Agent with Kong AI Gateway. In part two of this series, we're going to review LangGraph fundamentals, rewrite the AI Agent and explore how Kong AI Gateway can be used to protect an LLM