Kuadrant: Gateway policies for Kubernetes

Gateways play a pivotal role in application connectivity. In the Kubernetes cloud-native world, Gateway API is gaining traction as a powerful standard for defining gateways and exposing your applications and services in a security-focused and scalable way. Kuadrant, a Red Hat-sponsored project, brings together Gateway API and Policies to help you scale, load-balance, and secure your gateways in single or multi-cluster environments.

What are we announcing?

Earlier this year, we wrote about how you can use Kuadrant to add rate limiting and AuthN/Z to your services. Since then we have evolved those policies and developed some new policies with a focus on solving large-scale multi-cluster application connectivity problems. We have been busy working on our first upstream release, with lots of documentation updates, new guides, and reference material, and we are pleased to announce it is now ready. 

In this post, we have included more details on what the project is, who it is for, how it works and what's coming in the future. However, if you'd prefer to jump in and try it out yourself, give our quickstart a go.

Who is Kuadrant for?

At its core, Kuadrant provides a set of Kubernetes APIs for managing your application connectivity problems, such as AuthN/Z, rate limiting, DNS, unhealthy endpoint mitigation and TLS. So first and foremost, Kuadrant is for platform engineers who are looking to define infrastructure and protect it, but it can also be leveraged by application developers who want to define how their own applications should be accessed and rate-limited.

These APIs are intended to give the platform engineer a cloud-native, declarative way to manage important areas such as global load balancing and TLS and gateway definition and placement. They also enable platform engineers and application developers to configure, protect, and help secure their application endpoints. This concept is important for a zero trust architecture.

For example, the platform engineer can manage DNS for all application hosts centrally via a DNSPolicy. They can also enforce security for all applications in a set of gateways via a TLSPolicy, providing a safe set of coarse-grained behavior. Application developers can use the AuthPolicy and RateLimitPolicy APIs to configure the fine-grained aspects of their applications.

If (or when) the platform engineer needs to scale their platform beyond a single cluster, Kuadrant can scale alongside the platform. It has a concept of a multi-cluster gateway, which implements the Gateway API spec. A multi-cluster gateway allows the platform engineer to define a gateway centrally and have multiple instances of it deployed to multiple clusters. An additional benefit of this is being able to manage DNS weighting, geo-based routing, load balancing, and endpoint health checks across different gateway instances. This advanced feature is intended for applications deployed to multiple locations for reasons such as resiliency or compliance.

How does Kuadrant work?

In a single Kubernetes cluster, the Kuadrant components Authorino and Limitador and the associated operators reconcile any AuthPolicies and RateLimitPolicies from application namespaces. AuthPolicy and RateLimitPolicy are Kubernetes CRDs introduced by Kuadrant. Those components interact with the Gateway API provider to enforce those policies. Policies can target specific HTTPRoutes, or an entire set of listeners in a gateway. At this time, Kuadrant supports Istio as the Gateway API provider.

The multi-cluster Kubernetes environment extends on the single-cluster environment by leveraging OCM (open cluster management) for its placement and status aggregation capabilities and installing an additional component, the Multicluster Gateway Controller. This controller runs in a hub cluster, while the other Kuadrant components run in spoke clusters. The controller understands the Gateway API specification for gateway resources, specifically a multi-cluster gateway. A multi-cluster gateway is declared once in the hub cluster and gets instantiated in spoke clusters alongside applications. Policies defined in the hub cluster, like DNS and TLS, can target a multi-cluster Gateway. The controller has sufficient context about spoke clusters to manage DNS records and distribute TLS certificates to the right clusters. 

Kuadrant currently supports Google Cloud DNS and Route 53 for DNS management. TLS capabilities use the cert-manager project, which supports many certificate issuers, like Lets Encrypt and ZeroSSL.

What's next for Kuadrant?

The Kuadrant project is transitioning from early development to sharing for collaboration. There are lots of opportunities to get involved and influence where the project goes from here. That being said, some things are high on our list of priorities, such as:

• Additional DNS provider support for CoreDNS and Azure DNS
• Integration with external-dns
• Envoy Gateway support
• Extending the policy set to work seamlessly in both single- and multi-cluster environments (e.g., rate limiting across clusters or single-cluster DNSPolicies)
• Allowing overrides and defaults as part of the policy definitions as per Gateway API inherited policy attachment concepts
• We have been experimenting with East-West multi-cluster architectures using Skupper and Submariner.
• We also have an early-stage multi-cluster observability architecture using Prometheus metrics federation and a set of Grafana dashboards.

We are also working closely with Red Hat product management on opportunities to include Kuadrant as part of a future product offering.

If you are interested in trying out the Kuadrant project, check out our Getting Started guide. You can get in touch with the developers on Kubernetes Slack if you have any questions, problems, or suggestions. If you really like the project and would like to get involved, check out our Community page for details. We also have a YouTube channel for demos, and a weekly community call where we discuss priorities, proposals, and implementation.