Middlewares

Tweaking the Request

Overview

Attached to the routers, pieces of middleware are a mean of tweaking the requests before they are sent to your service (or before the answer from the services are sent to the clients).

There are many different available middlewares in Traefik, some can modify the request, the headers, some are in charge of redirections, some add authentication, and so on.

Pieces of middleware can be combined in chains to fit every scenario.

Configuration Example

  1. # As a Docker Label
  2. whoami:
  3. # A container that exposes an API to show its IP address
  4. image: containous/whoami
  5. labels:
  6. # Create a middleware named `foo-add-prefix`
  7. - "traefik.http.middlewares.foo-add-prefix.addprefix.prefix=/foo"
  8. # Apply the middleware named `foo-add-prefix` to the router named `router1`
  9. - "[email protected]"
  1. # As a Kubernetes Traefik IngressRoute
  2. apiVersion: apiextensions.k8s.io/v1beta1
  3. kind: CustomResourceDefinition
  4. metadata:
  5. name: middlewares.traefik.containo.us
  6. spec:
  7. group: traefik.containo.us
  8. version: v1alpha1
  9. names:
  10. kind: Middleware
  11. plural: middlewares
  12. singular: middleware
  13. scope: Namespaced
  14. ---
  15. apiVersion: traefik.containo.us/v1alpha1
  16. kind: Middleware
  17. metadata:
  18. name: stripprefix
  19. spec:
  20. stripPrefix:
  21. prefixes:
  22. - /stripit
  23. ---
  24. apiVersion: traefik.containo.us/v1alpha1
  25. kind: IngressRoute
  26. metadata:
  27. name: ingressroute
  28. spec:
  29. # more fields...
  30. routes:
  31. # more fields...
  32. middlewares:
  33. - name: stripprefix
  1. "labels": {
  2. "traefik.http.middlewares.foo-add-prefix.addprefix.prefix": "/foo",
  3. "traefik.http.routers.router1.middlewares": "[email protected]"
  4. }
  1. # As a Rancher Label
  2. labels:
  3. # Create a middleware named `foo-add-prefix`
  4. - "traefik.http.middlewares.foo-add-prefix.addprefix.prefix=/foo"
  5. # Apply the middleware named `foo-add-prefix` to the router named `router1`
  6. - "[email protected]"
  1. # As TOML Configuration File
  2. [http.routers]
  3. [http.routers.router1]
  4. service = "myService"
  5. middlewares = ["foo-add-prefix"]
  6. rule = "Host(`example.com`)"
  7. [http.middlewares]
  8. [http.middlewares.foo-add-prefix.addPrefix]
  9. prefix = "/foo"
  10. [http.services]
  11. [http.services.service1]
  12. [http.services.service1.loadBalancer]
  13. [[http.services.service1.loadBalancer.servers]]
  14. url = "http://127.0.0.1:80"
  1. # As YAML Configuration File
  2. http:
  3. routers:
  4. router1:
  5. service: myService
  6. middlewares:
  7. - "foo-add-prefix"
  8. rule: "Host(`example.com`)"
  9. middlewares:
  10. foo-add-prefix:
  11. addPrefix:
  12. prefix: "/foo"
  13. services:
  14. service1:
  15. loadBalancer:
  16. servers:
  17. - url: "http://127.0.0.1:80"

Provider Namespace

When you declare a middleware, it lives in its provider namespace.For example, if you declare a middleware using a Docker label, under the hoods, it will reside in the docker provider namespace.

If you use multiple providers and wish to reference a middleware declared in another provider(aka referencing a cross-provider middleware),then you'll have to append to the middleware name, the @ separator, followed by the provider name.

  1. <resource-name>@<provider-name>

Kubernetes Namespace

As Kubernetes also has its own notion of namespace, one should not confuse the "provider namespace"

with the "kubernetes namespace" of a resource when in the context of a cross-provider usage.In this case, since the definition of the middleware is not in kubernetes,specifying a "kubernetes namespace" when referring to the resource does not make any sense,and therefore this specification would be ignored even if present.

Referencing a Middleware from Another Provider

Declaring the add-foo-prefix in the file provider.

  1. [http.middlewares]
  2. [http.middlewares.add-foo-prefix.addPrefix]
  3. prefix = "/foo"
  1. http:
  2. middlewares:
  3. add-foo-prefix:
  4. addPrefix:
  5. prefix: "/foo"

Using the add-foo-prefix middleware from other providers:

  1. your-container: #
  2. image: your-docker-image
  3. labels:
  4. # Attach [email protected] middleware (declared in file)
  5. - "[email protected]e"
  1. apiVersion: traefik.containo.us/v1alpha1
  2. kind: IngressRoute
  3. metadata:
  4. name: ingressroutestripprefix
  5. spec:
  6. entryPoints:
  7. - web
  8. routes:
  9. - match: Host(`bar.com`)
  10. kind: Rule
  11. services:
  12. - name: whoami
  13. port: 80
  14. middlewares:
  15. - name: [email protected]
  16. # namespace: bar
  17. # A namespace specification such as above is ignored
  18. # when the cross-provider syntax is used.

Available Middlewares

MiddlewarePurposeArea
AddPrefixAdd a Path PrefixPath Modifier
BasicAuthBasic auth mechanismSecurity, Authentication
BufferingBuffers the request/responseRequest Lifecycle
ChainCombine multiple pieces of middlewareMiddleware tool
CircuitBreakerStop calling unhealthy servicesRequest Lifecycle
CompressCompress the responseContent Modifier
DigestAuthAdds Digest AuthenticationSecurity, Authentication
ErrorsDefine custom error pagesRequest Lifecycle
ForwardAuthAuthentication delegationSecurity, Authentication
HeadersAdd / Update headersSecurity
IPWhiteListLimit the allowed client IPsSecurity, Request lifecycle
InFlightReqLimit the number of simultaneous connectionsSecurity, Request lifecycle
PassTLSClientCertAdding Client Certificates in a HeaderSecurity
RateLimitLimit the call frequencySecurity, Request lifecycle
RedirectSchemeRedirect easily the client elsewhereRequest lifecycle
RedirectRegexRedirect the client elsewhereRequest lifecycle
ReplacePathChange the path of the requestPath Modifier
ReplacePathRegexChange the path of the requestPath Modifier
RetryAutomatically retry the request in case of errorsRequest lifecycle
StripPrefixChange the path of the requestPath Modifier
StripPrefixRegexChange the path of the requestPath Modifier