Share Traefik Resources Across Namespaces

Traefik Ingress Controller for Kubernetes is secure, resilient, reliable and scalable. Let’s take a break from these best practices and have a little fun with Traefik.

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:

                apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: traefik-basic-auth
  namespace: app-dev
spec:
  basicAuth:
    secret: traefik-authsecret
            

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.

                additionalArguments:
  - "--api.dashboard=true"
  - "--log.level=INFO"
  - "--providers.kubernetescrd.allowCrossNamespace=true"
            

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.

                ---
# Middleware enables compression
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: compress
  namespace: traefik
spec:
  compress: {}
---
# Shared Basic Authentication
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: traefik-basic-auth
  namespace: traefik
spec:
  basicAuth:
    secret: traefik-authsecret
---
# Enable X Forwarded HTTPS Protocol
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: x-forward-https-headers
  namespace: traefik
spec:
  headers:
    customRequestHeaders:
      X-Forwarded-Proto: "https"
            

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.

                ---
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
  name: prometheus-stripprefix
  namespace: monitoring
spec:
  stripPrefix:
    forceSlash: true
    prefixes:
      - /prometheus
      
---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: prometheus-ingress-route
  namespace: monitoring
spec:
  entryPoints:
    - websecure
  routes:
    - kind: Rule
      match: Host(`k3s.example.com`) && (PathPrefix(`/prometheus`))
      middlewares:
        - name: prometheus-stripprefix
        - name: compress
          namespace: traefik
        - name: x-forward-https-headers
          namespace: traefik
        - name: traefik-basic-auth
          namespace: traefik
      services:
        - kind: Service
          name: prometheus-prometheus
          port: 9090
            

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.


Pawfives by
Pawfives by:

Only registered users can post comments. Please, login or signup.

Start blogging about your favorite technologies and get more readers

Join other developers and claim your FAUN account now!

Avatar

Richard Durso

Deployment Engineer & Infrastructure Arc, Consultant

@reefland
Deployment Engineer & Infrastructure Architect. Coral Reef Aquarist. Mixologist.
Stats
16

Influence

496

Total Hits

1

Posts