Traefik 3.6.0 → 3.7.0

Ingress NGINX Provider

The KubernetesIngressNGINX Provider is no longer experimental in v3.6.2 and can be enabled without the experimental.kubernetesIngressNGINX option.

Deprecated Configuration:

Experimental kubernetesIngressNGINX option (deprecated)

File (YAML)

experimental:
  kubernetesIngressNGINX: true

File (TOML)

[experimental]
    kubernetesIngressNGINX=true

CLI

--experimental.kubernetesIngressNGINX=true

Migration Steps:

1. Remove the kubernetesIngressNGINX option from the experimental section
2. Configure the provider using the kubernetesIngressNGINX Provider documentation

Encoded Characters in Request Path

Starting with v3.6.4, for security reasons, Traefik now rejects requests with a path containing a specific set of encoded characters by default.

When such a request is received, Traefik responds with a 400 Bad Request status code.

Here is the list of the encoded characters that are rejected by default, along with the corresponding configuration option to allow them:

Please check out the entrypoint encodedCharacters option documentation for more details.

Encoded Characters Configuration Default Values

Since v3.6.7, the options for encoded characters now have a true default value. This means that Traefik will not reject requests with a path containing a specific set of encoded characters by default. It is now up to the users to configure the security hardening of encoded characters.

Here is the list of the encoded characters that can be configured to false to disallow them:

Note: This check is not done against query parameters, but only against the request path as defined in RFC3986 section-3.

Please check out the entrypoint encodedCharacters option documentation for more details.

Health Check Request Path

Since v3.6.8, the configured path for the health check request is now verified to be a relative URL, and the health check will fail if it is not.

maxResponseBodySize configuration on ForwardAuth middleware

In v3.6.9, a new maxResponseBodySize option has been added to the ForwardAuth middleware configuration. The default value for this option is -1, which means there is no limit to the response body size. However, it is strongly recommended to set this option to a suitable value to avoid performance and security issues, such as DoS attacks and memory exhaustion.

Please check out the ForwardAuth middleware documentation for more details.

Kubernetes CRD Provider

To use the new maxResponseBodySize option in the ForwardAuth middleware with the Kubernetes CRD provider, you need to update your CRDs.

Apply Updated CRDs:

kubectl apply -f https://raw.githubusercontent.com/traefik/traefik/v3.6/docs/content/reference/dynamic-configuration/kubernetes-crd-definition-v1.yml

Kubernetes CRD: Chain middleware and allowCrossNamespace

In v3.6.14, the Chain middleware now honors the Kubernetes CRD provider's allowCrossNamespace option. Previously, a Chain could reference middlewares in other namespaces regardless of the allowCrossNamespace configuration.

If allowCrossNamespace is set to false (the default) and a Chain middleware references a middleware in a different namespace from its own, the whole Chain is now rejected and an error is logged.

ForwardAuth middleware: trustForwardHeader

Starting with v3.6.14, the trustForwardHeader option has been deprecated and will be removed in the next major version. Configure the trusted IPs at the EntryPoint level by using the forwardedHeaders.trustedIPs option, and set trustForwardHeader to true on this middleware.

When trustForwardHeader is not explicitly set, Traefik logs a warning as its behavior is inconsistent: some X-Forwarded-* headers (e.g. X-Forwarded-For, X-Forwarded-Proto) are removed while others (e.g. X-Forwarded-Prefix) are forwarded untouched.

To silence the warning and avoid security concerns, explicitly set trustForwardHeader to true or false in your ForwardAuth middleware configuration.

Please check out the ForwardAuth middleware documentation for more details.

In v3.6.15, a new errorRequestHeaders option has been added to the Errors middleware.

By default, the behavior is unchanged: all original request headers are forwarded to the error page service. If the error page service is in a separate trust domain, consider using errorRequestHeaders to restrict which headers are forwarded.

Please check out the Error Pages middleware documentation for more details.

Docker provider: minimum Docker Engine version

Starting with v3.6.16, the Docker provider requires Docker API version v1.40 or above (Docker Engine v19.03). Users running older (end of life) versions of Docker Engine should update their Docker Engine or use the DOCKER_API_VERSION environment variable to override the API version used by Traefik.

Ingress NGINX Provider

Starting with v3.7.0, the Ingress NGINX provider now supports the nginx.ingress.kubernetes.io/custom-headers annotation to add custom headers to the response forwarded to the client.

Therefore, in the corresponding RBACs (see KubernetesIngressNGINX provider RBACs) the configmaps right has been added.

Required RBAC Updates:

  ...
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - list
      - watch  
  ...

Kubernetes Gateway API Provider

Starting with v3.7.0, the Kubernetes Gateway API provider supports version v1.5.1 of the specification, which requires the Gateway API CRDs to be updated.

TLSRoute has graduated to the Standard channel and no longer requires the experimentalChannel option. The experimentalChannel option is now only needed for TCPRoute.

Apply Updated CRDs:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.5.1/standard-install.yaml

For the experimental channel:

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.5.1/experimental-install.yaml

Kubernetes CRD Provider

To use the new options of the retry middleware or the new ingressClassName field with the Kubernetes CRD provider, you need to update your CRDs.

Apply Updated CRDs:

kubectl apply -f https://raw.githubusercontent.com/traefik/traefik/v3.7/docs/content/reference/dynamic-configuration/kubernetes-crd-definition-v1.yml

Wildcard Host and HostSNI

Since v3.7.0, the Host and HostSNI matchers support wildcard subdomain matching (e.g., *.example.com). This allows matching any direct subdomain of a domain with a single-level wildcard prefix. For example, *.example.com matches foo.example.com but not foo.bar.example.com or example.com itself.

This feature is only available with the v3 rule syntax (the default).

TLSOptions with Wildcard Domains

Since v3.7.0, TLSOptions can now be associated with routers using wildcard Host and HostSNI matchers (e.g., Host(*.example.com)). This enables configuring different TLS options for wildcard domains.

Previously, TLSOptions selection was limited to exact Host matches, and using HostRegexp or wildcards would fall back to the default TLS options with a warning message like: No domain found in rule HostRegexp(...) the TLS option foo cannot be applied.

Note: TLSOptions for HostRegexp matchers remains unsupported. Use wildcard Host matchers as an alternative.