Traefik dashboard unaccessible

[sleighzy]

Traefik dashboard unaccessible

[sleighzy]

Hi @mariusrugan , thanks for pointing out the externalTrafficPolicy change. I've updated this repo to use Local now and it's displaying the correct client source IP as expected now.

Let me know if you have any further questions otherwise and I'll go ahead and close this issue off. Thanks once again for using the manifest files in this repository and the feedback, good to know they're helping people.

[sleighzy]

Hi @mariusrugan , thanks for that.

I've quickly spun up a deployment to retest this and can confirm the following:

To use port forwarding (kubectl port-forward --address 0.0.0.0 service/traefik 8080:admin -n kube-system) and no auth (which using that port to the admin service skips) the --api.insecure=true flag needs to be set, and then the dashboard can be accessed in your browser at http://localhost:8080/dashboard/

If the api.insecure flag isn't set then one of the secure mechanisms needs to be used, of which the basic auth middleware is one of them. This will be triggered when accessing via the http (80) or https (443) port. For example, if I quickly (for testing purposes) add 127.0.0.1 traefik.mydomain.io to my /etc/hosts file, and remove the https and redirection from the deployment I am presented with the basic auth dialog requiring me to login when I navigate to http://traefik.mydomain.io/dashboard. The same applies with my existing deployment which uses HTTPS and a proper DNS provider, the above steps were just to quickly test this out for you.

[sleighzy]

I'll dig a little deeper into the "No secret name provided" debug message shortly. I can see a similar message from other standard ingresses in my cluster (not IngressRoute from the Traefik k8s CRD). I would expect a secret name to be provided for TLS if this was using a certificate stored as a secret, v.s. using a certificate resolver like this is. I'll have a look to see if there are similar issues raised with Traefik or Kubernetes for TLS secrets vs certificate resolvers.

[mariusrugan]

tldr;
Thanks for re: and testing.
It was my fault to describe the ingressroute on https when i wanted it http.

Hi @mariusrugan , thanks for that.

I've quickly spun up a deployment to retest this and can confirm the following:

To use port forwarding (kubectl port-forward --address 0.0.0.0 service/traefik 8080:admin -n kube-system) and no auth (which using that port to the admin service skips) the --api.insecure=true flag needs to be set, and then the dashboard can be accessed in your browser at http://localhost:8080/dashboard/

yes,
also without portfw via kubectl - accessible at the IP of the nodes (i have 201 - m,202- w,203 - w)
el.g.
http://192.168.1.20{1,2,3}:8080/dashboard/#/

 kubectl describe service traefik -n kube-system
 
Name:                     traefik
Namespace:                kube-system
Labels:                   <none>
Annotations:              <none>
Selector:                 app=traefik
Type:                     LoadBalancer

IP:                       10.43.192.118
LoadBalancer Ingress:     192.168.1.202

Port:                     web  80/TCP
TargetPort:               8080/TCP
NodePort:                 web  30992/TCP
Endpoints:                10.42.1.15:8080

Port:                     websecure  443/TCP
TargetPort:               8443/TCP
NodePort:                 websecure  32020/TCP
Endpoints:                10.42.1.15:8443

Port:                     admin  8080/TCP
TargetPort:               9080/TCP
NodePort:                 admin  32562/TCP
Endpoints:                10.42.1.15:9080
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

which i think is because externalTrafficPolicy: Cluster and LoadBalancer type
to which i can add quoting https://blog.getambassador.io/externaltrafficpolicy-local-on-kubernetes-e66e498212f9

When a node routes traffic to a pod on another node, the source IP address of that traffic becomes that of the node, and not the client.
By setting ExternalTrafficPolicy=local, nodes only route traffic to pods that are on the same node, which then preserves client IP. It’s important to recognize that ExternalTrafficPolicy is not a way to preserve source IP; it’s a change in networking policy that happens to preserve source IP.

I am employing HAProxy (since i have several other machines in the network which receive https traffic from the internet AND i'd like to have a single point of offloading ALL https from cloudflare - i like to stay behind them as a traffic scrubber/firewall) - i can share the haproxy config if interested.

---

If the api.insecure flag isn't set then one of the secure mechanisms needs to be used, of which the basic auth middleware is one of them. This will be triggered when accessing via the http (80) or https (443) port. For example, if I quickly (for testing purposes) add 127.0.0.1 traefik.mydomain.io to my /etc/hosts file, and remove the https and redirection from the deployment I am presented with the basic auth dialog requiring me to login when I navigate to http://traefik.mydomain.io/dashboard. The same applies with my existing deployment which uses HTTPS and a proper DNS provider, the above steps were just to quickly test this out for you.

yes, thanks for pointing out to revisit the " https / redirection "
The ingress route was described via websecure + tls provider

---
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: traefik-dashboard
  namespace: kube-system
spec:
  entryPoints:
    - web
  routes:
  - match: Host(`traefik.mydomain.io`) && (PathPrefix(`/api`) || PathPrefix(`/dashboard`))
    kind: Rule
    services:
    - name: api@internal
      kind: TraefikService
    middlewares:
      - name: traefik-basic-auth 

[sleighzy]

It tells you, that you did not set a secret name on your TLS Section of the IngressRoute. That's all. :)

I attempted to set a secretName with a new IngressRoute but ended up with the below error message being spammed to to the logs. Also tested with a new whoami-v2 domain name to see if it would generate a certificate and store in that secret but didn't appear to.

Error configuring TLS: secret default/whoami-v2 does not exist

Looks like the secretName entry would be used with something like creating and storing a certificate with Cert-Manager, but not when using the inbuilt automated LetsEncrypt cert generation.

(from Traefik - not from whoami - as it was present before deploying whoami)

I include an IngressRoute with tls enabled for the Traefik dashboard, so possibly the message came from that prior to you deploying whoami if you had already installed that Traefik Dashboard ingress route?

[mariusrugan]

no questions, thanks again!

wrt to

I include an IngressRoute with tls enabled for the Traefik dashboard, so possibly the message came from that prior to you deploying whoami if you had already installed that Traefik Dashboard ingress route?

yes, prior to deploying whoami.
the explanation

It tells you, that you did not set a secret name on your TLS Section of the IngressRoute. That's all. :)
coming from
traefik/traefik#6179