How to use the same wildcard TLS certificate in multiple IngressRoutes in different namespaces?

Traefik Traefik v2 (latest)
,
1

I have one wildcard TLS certificate, and in order to use it in different namespaces, I have created multiple Secrets containing the same TLS certificate. I have multiple IngressRoutes in different namespaces for hosts such as traefik.mydomain.com, linkerd.mydomain.com. I am being flooded by following warnings:

Skipping addition of certificate for domain(s) \"*.mydomain.com,mydomain.com\", to EntryPoint default, as it already exists for this Entrypoint."

First of all, creating multiple Secrets with the same content feels wrong, so I was wondering if there was a way to avoid it, e.g. by allowing to select the namespace of the Secret in this way:

tls:
    secretName: my-wildcard-cert
    namespace: some-common-namespace

However, the CRD way seems kind of broken currently, so should I use file configuration instead for setting the certificates?

2

This inquiry of mine—and the subsequent discussion about how Traefik selects which certificate to use—sounds pertinent.

3

@seh I read that thread before posting, but as it doesn't really answer my question, and because handling TLS certificates correctly is an important topic, I would really want a clarification from Traefik team or someone with knowledge on the matter.

I understand that Traefik 2.0 is in beta and everything, but before final release, there really should be clear examples on how to handle something as crucial as configuring TLS certificates.

Having file-based configuration, CRD-based configuration, and certificate stores, it's getting very confusing what is actually the correct/recommended/good way to configure certificates.

4

I agree with you. I find the interaction of network protocol, TLS configuration, host matching, and CRD options to be confusing. I've had to study the code to figure out what implies what, and what mandates what.

5

Hello @Kitanotori,

Secrets are namespaced for isolation, and to allow RBAC control over who has access to what secrets.

Core Kubernetes objects only allow access to secrets that exist in the same namespace as the object itself: Pods, Volumes, etc.

Allowing users to reference secrets in other namespaces can lead to secret fishing, and have security implications.

The fact that you are using the same content (your certificate) across multiple isolated namespaces may suggest some design improvements to your architecture.

In keeping with the patterning and spirit of the kubernetes ecosystem, it is unlikely that cross-namespace secret mounting will be implemented.

6

I understand your point regarding sharing secrets between namespaces. But let me give you an example. I have Linkerd in namespace "linkerd", Traefik in namespace "traefik", and application services in their own namespace. I want to expose Linkerd dashboard from linkerd.mydomain.com, Traefik dashboard from traefik.mydomain.com, and the application from mydomain.com. I want to use same TLS certificate, because I don't see a reason why it would make sense to use separate certificates. I was able to achieve this with File configuration but not with CRD configuration.

1 Like