Does anyone have experience with Rancher GKE clusters ingres rancher-users #general

Title

helpful-beard-54962

03/25/2023, 1:22 AM

Does anyone have experience with Rancher GKE clusters ingress? I installed the nginx-ingress, works, but doesn't use SSL, only port 80. I added certificates, I tried everything in the documentation

refined-analyst-8898

03/25/2023, 1:30 AM

Not in GKE specifically, no. Do you think the problem is unique to GKE?

helpful-beard-54962

03/25/2023, 1:31 AM

I don't know if it's only on GKE. Problem: Nginx-ingress always forwards to port 80, it works. 443 returns 404 NOT Found. All the necessary configs that work on another AWS cluster are there

refined-analyst-8898

03/25/2023, 1:35 AM

Oh, interesting. So what's the value of

spec.tls.*.hosts

on the Ingress resource? There's an opportunity for a mismatch there if it's not the same value of

host

on the HTTP counterpart in

spec.rules.*.host

The load balancer will only route the request properly if the DNS name matches

host

helpful-beard-54962

03/25/2023, 1:37 AM

The DNS routes correctly on port 80. tls is a wildcard that seems to be pe applied successfully. Browser shows valid certificate

refined-analyst-8898

03/25/2023, 1:38 AM

Your server certificate has a wildcard DNS SAN, right?

helpful-beard-54962

03/25/2023, 1:39 AM

Yes. The Certificate is correctly validates as wildcard. I tested it on a different cluster and it works

refined-analyst-8898

03/25/2023, 1:40 AM

Here is a functioning Ingress example.

apiVersion: <http://networking.k8s.io/v1|networking.k8s.io/v1>
kind: Ingress
metadata:
  annotations:
    <http://cert-manager.io/issuer|cert-manager.io/issuer>: rancher
    <http://cert-manager.io/issuer-kind|cert-manager.io/issuer-kind>: Issuer
    <http://field.cattle.io/publicEndpoints|field.cattle.io/publicEndpoints>: '[{"addresses":["192.168.5.15"],"port":443,"protocol":"HTTPS","serviceName":"cattle-system:rancher","ingressName":"cattle-system:rancher","hostname":"<http://rancher.example.com|rancher.example.com>","allNodes":false}]'
    <http://meta.helm.sh/release-name|meta.helm.sh/release-name>: rancher
    <http://meta.helm.sh/release-namespace|meta.helm.sh/release-namespace>: cattle-system
    <http://nginx.ingress.kubernetes.io/proxy-connect-timeout|nginx.ingress.kubernetes.io/proxy-connect-timeout>: "30"
    <http://nginx.ingress.kubernetes.io/proxy-read-timeout|nginx.ingress.kubernetes.io/proxy-read-timeout>: "1800"
    <http://nginx.ingress.kubernetes.io/proxy-send-timeout|nginx.ingress.kubernetes.io/proxy-send-timeout>: "1800"
  creationTimestamp: "2023-03-23T00:13:53Z"
  generation: 1
  labels:
    app: rancher
    <http://app.kubernetes.io/managed-by|app.kubernetes.io/managed-by>: Helm
    chart: rancher-2.7.1
    heritage: Helm
    release: rancher
  name: rancher
  namespace: cattle-system
  resourceVersion: "2223"
  uid: 1f78f424-c9a3-4bae-9379-75d193409d35
spec:
  ingressClassName: traefik
  rules:
  - host: <http://rancher.example.com|rancher.example.com>
    http:
      paths:
      - backend:
          service:
            name: rancher
            port:
              number: 80
        pathType: ImplementationSpecific
  tls:
  - hosts:
    - <http://rancher.example.com|rancher.example.com>
    secretName: tls-rancher-ingress
status:
  loadBalancer:
    ingress:
    - ip: 192.168.5.15

I was pointing out the necessary symmetry between the two occurrences of

<http://rancher.example.com|rancher.example.com>

spec.rules

and

spec.tls

helpful-beard-54962

03/25/2023, 1:43 AM

Yes, this is identical to my config

tls:
  - hosts:
    - '*.<http://example.com|example.com>'

This is the only difference

refined-analyst-8898

03/25/2023, 1:44 AM

That is the problem. It should not be a wildcard in this spot, but the expected DNS name instead.

The web client/user agent is the audience for the wildcard DNS SAN, not this load balancer.

helpful-beard-54962

03/25/2023, 1:45 AM

ok, updating now ...

wow. worked. Testing some more

so even if the certificate is a wildcard, the host must be the full path, correct?

refined-analyst-8898

03/25/2023, 1:48 AM

Yes, you must program Nginx to match some DNS name with a cluster service. I believe Nginx can handle a wildcard scenario, but I'm not certain how to express that in an Ingress resource.

This resource suggests there is some support for wildcard hosts since K8s 1.18. https://docs.nginx.com/nginx-ingress-controller/configuration/ingress-resources/basic-configuration/#new-features-available[…]bernetes-118-and-above

There's certainly support for wildcard hosts in K8s Ingress, but they don't give an example of a wildcard TLS host pattern. https://kubernetes.io/docs/concepts/services-networking/ingress/#hostname-wildcards

helpful-beard-54962

03/25/2023, 1:57 AM

great. seems to be working now. Thanks!

refined-analyst-8898

03/25/2023, 2:00 AM

You're welcome! This post does give an example of wildcard TLS host. Maybe it was a stray keystroke error preventing the match? https://docs.digitalocean.com/tutorials/set-up-nginx-ingress-controller-to-use-wildcard-certificates/#step-5-set-up-nginx-t[…]-wildcard-certificates

helpful-beard-54962

03/25/2023, 2:09 AM

No, so what happens is the moment I add * to the host in TLS it automatically reverts back to HTTP. If add the host as exact match, then it works with SSL

3 Views

#general Join Slack