Implementing Runtime API Governance in Traefik Hub

In a recent blog post, we discussed the top five policies for runtime API governance. Now, let’s look at how Traefik Hub implements these policies. Traefik Hub is a Kubernetes-native API management solution built with scalability, flexibility, and simplicity in mind. Traefik Hub helps route traffic to services in dynamic, microservices-oriented environments.

In the following sections, we will provide examples of configuration implementation in Traefik Hub to support the standards we have discussed. But note that our examples are not exhaustive - Traefik Hub supports many more capabilities and configuration options!

Policy 1: Use a developer-friendly, traceable, and easy-to-rollback approach for API deployments

As a Kubernetes-native solution, Traefik Hub supports declarative resource configuration. Traefik Hub configuration can be done through Kubernetes resources like Ingress and Service, and Traefik Custom Resource Definitions (CRDs) like IngressRoutes, Middleware, API, APIPortal, APIAccess, APIVersion, and APIRateLimit. Configuration can be version-controlled in Git and automatically applied to the Kubernetes cluster using GitOps tools like ArgoCD and Flux.

For example, defining external traffic routing to a service involves creating an API CRD and exposing the API with an IngressRoute. The following resource definition declares an API called hello-api, and provides the path to its OpenAPI description.

---
apiVersion: hub.traefik.io/v1alpha1
kind: API
metadata:
name: hello-api
namespace: apps
spec:
openApiSpec:
path: /openapi.yaml

Next, specify an IngressRoute CRD with routes to connect incoming requests to services that can handle them. The following resource definition declares a router that matches a request with the host api.example.com to the hello-api-service.

---
apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
name: hello-api-ingress
namespace: apps
annotations:
hub.traefik.io/api: hello-api # Name of the API object
spec:
routes:
- match: Host(`api.example.com`)
kind: Rule
services:
- name: hello-api-service
port: 8080

Developers can save configurations to a Git repository, and GitOps operators ensure that these configurations are consistently applied across environments. The diagram below illustrates this process.

The declarative nature of Traefik configuration, combined with GitOps workflows, supports advanced and progressive deployment capabilities. Teams can follow blue-green deployments and canary releases using GitOps operators like ArgoCD and FluxCD. If any issues are detected, changes can be rolled back to a stable version by reverting the changes in the Git repository.

TIP: For an in-depth treatment on how to do load-balancing in Traefik and support advanced deployment techniques, see Traefik’s Advanced Load Balancing course.

Policy 2: Make comprehensive and correct API documentation available to users

Traefik Hub API management includes an API Developer Portal to make API documentation accessible to developers and other API users. In the portal, users can explore available API endpoints, understand their usage, and test them in real time.

The APIPortal CRD creates and configures the portal, generating a web interface for browsing the API documentation. The visibility of API documentation depends on user groups. An API will be visible to an API consumer if they belong to a specified group with access to the API, as configured by the APIAccess CRD.

You can create an API developer portal by applying an APIPortal resource as follows:

---
apiVersion: hub.traefik.io/v1alpha1
kind: APIPortal
metadata:
name: my-portal
namespace: default
spec:
title: "My Portal" # The title for the Portal
description: "API documentations" # A short description of the Portal
trustedUrls:
- "https://portal.example.com"
ui:
logoUrl: https://traefik.io/favicon.png # URL to a picture used as logo

To expose the portal, create an IngressRoute resource, as demonstrated below:

---
apiVersion: traefik.io/v1alpha1
kind: IngressRoute
metadata:
name: my-portal-ingress
namespace: traefik-hub
annotations:
hub.traefik.io/api-portal: my-portal@default # Reference the APIPortal
spec:
routes:
- match: Host(`portal.example.com`)
kind: Rule
services:
- name: apiportal
port: 9903

Policy 3: Secure all API traffic from malicious and unauthorized access

With Traefik Hub, you can ensure secure API access using protocols such as Oauth2, OpenID Connect (OIDC), API keys, and JSON Web Tokens (JWTs). Additionally, Traefik integrates with identity providers such as Keycloak and Okta. Traefik also integrates with any other IdP that supports the OIDC protocol to handle user identities and authorize access to the APIs and API portals.

To protect APIs from DDoS attacks or excessive requests from a single client, you can implement rate limits by defining an APIRateLimit resource. Traefik allows you to do this for all APIs or specific user groups. The following declarative config defines a rate limit of 100 requests per minute.

apiVersion: hub.traefik.io/v1alpha1
kind: APIRateLimit
metadata:
name: my-rate-limit
namespace: apps
spec:
# Rate limit configuration, this config allows 100 requests/minute.
limit: 100 # 100 requests
period: 1m # One minute
groups:
- support
apiSelector:
matchLabels:
module: crm

Using Traefik’s Distributed Rate Limit (which is based on the Token Bucket algorithm), you can limit requests over time across your entire cluster rather than just an individual proxy.

In addition, Traefik Proxy v3 includes the Coraza Web Application Firewall (WAF) integrated as a plugin. Coraza is an open-source OWASP project and a high-performance WAF that supports Modsecurity's seclang language and OWASP core rule sets. Enabling this involves two simple steps:

- First, updating Traefik’s static configuration that loads the plugin as follows:

experimental:
plugins:
coraza:
moduleName: github.com/jcchavezs/coraza-http-wasm-traefik
version: v0.2.2

- Then, updating the WAF CRD as follows:

---
apiVersion: traefik.io/v1alpha1
kind: Middleware
metadata:
name: coraza-waf-block-admin-path
namespace: apps
spec:
plugin:
coraza:
directives:
- SecRuleEngine On
- SecDebugLog /dev/stdout
- SecDebugLogLevel 9
- SecRule REQUEST_URI "@streq /admin" "id:101,phase:1,log,deny,status:403"

Policy 4: Provide precise API change impact analysis to minimize service failure and breaking changes

Traefik Hub helps you understand the impact of API configuration changes by performing static checks on manifest files. It includes a Static Analyzer tool that allows you to check your Traefik Hub manifest files for consistency and quality. The Static Analyzer can lint manifest files and generate differential reports. It can be used as a CLI tool or as part of a CI/CD pipeline. The linter can detect issues such as:

Childless resources
Duplicate resources and resource references
Unknown operation sets
Orphan resources
Invalid resource references
Invalid regular expressions
Duplicate releases of a given API
Invalid resource definitions
Invalid selector definitions

The following is an example of the linting error message displayed on the PR that introduces a change.

The Static Analyzer tool can also run a diff to generate change reports. For example, a report like the following makes it clear that the rate limit was changed. It shows the user group and APIs affected by the change. If that was not the developer’s intention, the developer can take remedial action.

To aid API evolution, Traefik Hub also supports several API versioning schemes. Teams can define and use an API version based on host, URI path, HTTP method, query parameters, media/content type headers, custom headers, client IP, auth user (basic/forward auth), JWT claims, and more. Traefik even allows teams to mix different versioning schemes based on logical expressions.

Policy 5: Provide proactive API monitoring and comprehensive, granular observability to reduce time to recovery

Traefik Hub provides metrics and tracing information using the OpenTelemetry (OTel) format, to help teams monitor and gain insights into the traffic flowing through their services and APIs. Traefik Hub has the most comprehensive OTel support in the industry, with over 20 metrics and 15 labels. Additionally, it supports vendor-specific metric systems such as Prometheus, Datadog, InfluxDB, and StatsD.

For instance, to set up the OTel metrics, first get the configuration values for the Traefik Hub Helm release:

helm get values traefik-hub -n traefik | tail -n +2 > values.yaml

Then, modify and apply the configuration values in values.yaml.

metrics:
# Disable Prometheus (enabled by default)
prometheus: null
# Enable providing OTel metrics
otlp:
enabled: true
http:
enabled: true
endpoint: http://myotlpcollector:4318/v1/metrics
# Enable providing OTel traces
tracing:
enabled: true
http:
enabled: true
endpoint: http://myotlpcollector:4318/v1/traces

By integrating with monitoring systems, you can configure alerts and notifications for critical metrics and performance indicators. Traefik can also be connected to pre-built Grafana dashboards to visualize a wide range of API metrics. This allows you to correlate deployment events with incident management, enhancing your ability to monitor and respond to issues effectively and improve MTTR. For more details on Traefik Hub’s integration with Grafana, see this webinar.

Additionally, Traefik provides a built-in dashboard that offers a real-time view of the current status of routes, services, middleware, and other components.

GitOps Implementation Example

The first policy we highlighted at the beginning of this article was about providing a developer-friendly, traceable, and easy-to-rollback approach to API deployment. We also mentioned in Standard 1.2 that GitOps was an implementation of this approach. In the Traefik Hub GitOps Tutorial project in GitHub, we provide a hands-on tutorial to demonstrate the power of GitOps for API configuration deployment and change management. It also demonstrates Traefik Hub’s integration with API monitoring and observability visualization tools. The tutorial uses the following tools:

Aspect	Tool
API Management	Traefik Hub
Software platform	Kubernetes cluster, running locally in kind or k3d
GitOps Deployment Tool	FluxCD
Git repository	GitHub
Metrics visualization	Grafana
API monitoring and alerting	Prometheus

To work on this project, request a Traefik Hub trial here. Then follow the instructions on the README page, clone the repository, and set up kind and FluxCD. In the tutorial, FluxCD watches your fork of the GitHub repository for changes. When a change to the master branch is detected, it deploys the latest version of the configuration file to the cluster.

Summary

In the part 1, we introduced five essential policies for effective runtime API governance:

A developer-friendly API deployment process
Comprehensive and correct API documentation available to users
Secure both ingress and egress API traffic,
Clear API change impact analysis
Proactive API monitoring and deep observability.

By establishing standards based on these policies, organizations can enforce runtime API governance more effectively. The primary objective of improving runtime API governance is to improve software delivery performance (as measured by the DORA metrics - DR, LTC, CFR, and MTTR). It also aims to enhance the API developer experience for both API producers and API consumers.

To successfully implement these runtime governance policies, it's crucial to leverage a modern API management platform, such as Traefik Hub, which emphasizes dynamic change management and runtime API governance at its core. As a Kubernetes native API management solution, Traefik Hub is optimized for end-to-end API delivery automation which improves operational efficiency. To learn more, get a personalized demo of Traefik Hub today.

In This Article