Share Traefik Resources Across Namespaces

Namespaced Resources

When objects are declared in the Traefik configuration, such as middlewares, TLS options and server transports, they reside within the namespace it was declared in.

An Example

If you create a Traefik middleware for authentication within the app-dev namespace which references a secret traefik-authsecret (which contains the list of usernames and passwords) within that namespace such as:

Then only applications deployed within that app-dev namespace can make use of this middleware for authentication. If you try to deploy this middleware to another namespace such as app-test and reference the same secret that will not work as secrets cannot be shared across namespaces. (You can use 3rd party applications to duplicate and replicate secrets to many namespaces, but you cannot share just that one.)

In most scenarios, this is probably the right configuration… but not always.

An Alternative Scenario

Let’s imagine a cluster that is not multi-tenant, it is not mission critical production, it’s something more casual where using basic authentication is acceptable. A small team of users each want their own ID and Password to access several applications which support basic authentication.

I use this as a poor-man’s SSO (Single Sign-On) with my Home Kubernetes cluster to allow my ID & Password to login to many applications in different namespaces such as Prometheus, Alertmanager, Longhorn Dashboard, Traefik Dashboard, etc.

Remember its not just about authentication, you can ignore the shared authentication secret example. Perhaps you want a single common set of middlewares to define standardized host headers, enable compression, define TLS options and you do not want this duplicated to every application namespace. This can be achieved just as easily.

allowCrossNamespaces

Traefik Documentation has the smallest of blurbs about this feature allowCrossNamespace as:

Optional, Default: false

If the parameter is set to true, IngressRoute are able to reference resources in namespaces other than theirs.

Very easy to skip right over this setting if you were not looking for it. This is all we need to change within the Traefik configuration to allow sharing across namespaces. Where do you define this? If you install via Helm Chart this will be defined in the additionalArguments section where you enabled the dashboard, set the logging level, etc.

Once this has been applied, we can create some simple example middlewares. Since these can now be used in any namespace, we will store them in the same namespace where Traefik is installed, the traefik namespace.

Now applications deployed to other namespaces can pick and choose which of these middlewares to reuse and they can still define middlewares unique to that application.

Let’s use Prometheus as an example. The following IngressRoute and middleware defined in namespace monitoring will make Prometheus UI available at https://k3s.example.com/prometheus.

The important part of the yaml manifest above are the four middlewares referenced:

• prometheus-stripprefix — which is unique to this application and thus defined with the IngressRoute, so we don’t need to specify a different namespace to locate it. (It’s function is just to remove the /prometheus from the URI before passing the request to the Prometheus Service which assumes it is running at the root URI. )
• The other three middlewares compress, x-forward-https-headers, traefik-basic-auth are the common middlewares we defined earlier. As these are not deployed within the monitoring namespace, we need to tell Traefik where to find these using namespace: traefik.

If you wish to store your common middlewares in a different namespace, then adjust this as needed.

It’s that simple. Now I can login and access my other applications in different namespaces without needing to re-authenticate each time. Plus I only need to change my password in just one secret. I don’t need to setup reflectors to duplicate my authentication secret.

I’m trying to get past Medium’s minimum follower requirement. If you found this article interesting or helpful then a clap and follow would be appreciated.