I want to use a self-signed certificate at a Pod. Therefore, traefik must be informed about the RootCA which signed the certificate. I'm using only a root CA, no intermediate CA.
I have created the following Kubernetes resources at the namespace infra-logging:
a Secret elastic-certificate-chain with key tls.ca and a self signed certificate as value
a ServersTransport elasticsearch which references the Secret:
a Service with the annotation traefik.ingress.kubernetes.io/service.serverstransport: elasticsearch@kubernetescrd
I get the following error message: servers transport not found elasticsearch@kubernetes. Including the namespace into the annotation (i.e. using infra-logging-elasticsearch@kubernetescrd) does not help (it only changes the error message to servers transport not found infra-logging-elasticsearch@kubernetescrd).
Hi @jakubhajek,
I already tried to use the full qualified name:
but this does not work either
I assume that the same problem occurs like when I have used Middlewares: there is a subtle error in my ServersTransport configurtion and therefore the CRD is ignored silently by traefik.
Is it allowed to set only "rootCAsSecrets" or are other attributes mandatory?
here is the full example how to mount secrets with CA's to Traefik deployment
Alternatively you can use insecure mode. By enabling that feature Traefik will trust the server certificate.
I also created the entire configuration so you can test it on your side. In my example Whoami application is acting as Elasticsearch. The application expose port 443 and certificate and key that has been issued by CA added to Traefik deployment.
The deployment for Whoami application, please note the annotation serverscheme that is added to the service.
As far as I can see the example does not use ServersTransport + Secret for providing the root ca. It uses a static configuration file (referenced by a command line argument) from a Secret for configuring traefik.
Is there a reason why the Kubernetes "way of working" is not used? By using a central configuration file the flexibility and independence of namespace administrators is lost.
In the example I shared adding RootCA is done though static configuration. In order to do that, a secret that contains CA's has to be added to the Traefik Deployment. Then certificates have to be referenced in the ServerTransport
Those certificates are reachable globally.
In that case, the solution is to use ServersTransport on a service level. In that case the CA's are applied from Kubernetes secret. Traefik Services Documentation - Traefik
If I correctly understand your use case the example from my previous post should be good enough to trust self signed certificates presented by Elasticsearch.
@BernhardBerbuir I just struggeled with the same topic. Finally got it working by using the "fully qualified" reference in the services annotation. traefik.ingress.kubernetes.io/service.serverstransport: <namespace>-<ServersTransport name>@kubernetescrd
Maybe the parser is buggy and has troubles with the hypen character in your namespace identifier. Could you try to use a "hypenless" namespace instead?
IMHO the documentation related to ServersTransport with dynamic config could need a little overhauling. This took me hours.
I have reviewed my original setup: when using the "fully qualified" reference then it works fine (even in a namespace with a dash -). Additionally, my internal setup missed the label at the ServersTransport for being recognized by the correct traefik instance.
Unfortunately, neither the web nor the log file provides any information about ServersTransport (but Middleware resource configuration is quite good visualized at the web dashboard). I have had a certificate problem (the certificate only contained the host name from inside the cluster but not the external host name) and traefik did not displayed any error message about the host name mismatch.
Adding a serverName to the ServersTransport solved the problem.