Kuadrant Controller

Table of contents
Overview
Kuadrant is a re-architecture of API Management using Cloud Native concepts and separating the components to be less coupled,
more reusable and leverage the underlying kubernetes platform. It aims to deliver a smooth experience to providers and consumers
of applications & services when it comes to rate limiting, authentication, authorization, discoverability, change management, usage contracts, insights, etc.
Kuadrant aims to produce a set of loosely coupled functionalities built directly on top of Kubernetes.
Furthermore it only strives to provide what Kubernetes doesn’t offer out of the box, i.e. Kuadrant won’t be designing a new Gateway/proxy,
instead it will opt to connect with what’s there and what’s being developed (think Envoy, GatewayAPI).
Kuadrant is a system of cloud-native k8s components that grows as users’ needs grow.
- From simple protection of a Service (via AuthN) that is used by teammates working on the same cluster, or “sibling” services, up to AuthN of users using OIDC plus custom policies.
- From no rate-limiting to rate-limiting for global service protection on to rate-limiting by users/plans
towards a full system that is more analogous to current API Management systems where business rules
and plans define protections and Business/User related Analytics are available.
CustomResourceDefinitions
A core feature of the kuadrant controller is to monitor the Kubernetes API server for changes to
specific objects and ensure the owned k8s components configuration match these objects.
The kuadrant controller acts on the following CRDs:
| CRD |
Description |
| APIProduct |
Customer-facing APIs. APIProduct facilitates the creation of strong and simplified offerings for API consumers |
| API |
Internal APIs bundled in a product. Kuadrant API objects grant API providers the freedom to map their internal API organization structure to kuadrant |
For a detailed description of the CRDs above, refer to the Architecture page.
List of features
| Feature |
Description |
Stage |
| OpenAPI 3.x |
OpenAPI driven configuration. The document can be read from a configmap or served from the upstream API service |
Ready |
| Path Match based routing |
HTTP routing rules will be configured based on request path expressions. Accepted values are Exact, Prefix and RegularExpression |
Ready |
| Service Discovery |
kubernetes annotations and labels for a seamless integration |
Ready |
| AuthN based on API key |
Protect your service with a simple API key based authentication mechanism |
Ready |
| AuthN based on OpenID Connect (OIDC) |
Kuadrant can verify OIDC (JWTs) tokens to authenticate users |
Ready |
| Global Rate Limiting |
Single global rate limit for all requests. Main use case for protecting infrastructure resources |
Ready |
| Rate Limiting Per Remote IP |
Rate limit configuration per each remote IP address. Main use case for protecting infrastructure resources |
Ready |
| Authenticated Rate Limiting |
Rate limit configuration per each authenticated client |
Ready |
| Server TLS |
TLS termination for downstream connections |
Planned |
| Upstream TLS |
Client certificates upstream connections |
Planned |
| mTLS |
Mutual TLS termination for downstream connections |
Planned |
| Gateway API |
Implementation of kuadrant features on top of the Gateway API |
Planned |
| Monitoring and Alerting |
Observability based on Grafana and Prometheus |
Planned |
For a detailed description of the features above, refer to the Architecture page.
Architecture
The Architecture section of the docs covers the details of protecting your APIs with Kuadrant.
User Guides
Contributing
The Development guide describes how to build the kuadrant controller and
how to test your changes before submitting a patch or opening a PR.
Licensing
This software is licensed under the Apache 2.0 license.
See the LICENSE and NOTICE files that should have been provided along with this software for details.