Confirm haproxy supports ingress spec.tls[].secretName? about kubernetes-ingress HOT 9 CLOSED

I feel like I'm taking crazy pills. I've tried all sorts of variations, ending up with this:

kind: Ingress
apiVersion: extensions/v1beta1
metadata:
  name: foo-ingress
spec:
  tls:
  - hosts:
    - foo.domain
    secretName: foo-tls
  rules:
  - host: foo.domain
    http:
      paths:
        - path: /
          backend:
            serviceName: foo-service
            servicePort: 80

But when I curl foo.domain:443, all I get is: default backend - 404

I'm not trying to be too annoying here, but could someone please point me to the line of code in the repo that even looks for the secretName key inside the spec and tries to read it? Because I can't find that code.

from kubernetes-ingress.

Hi,

Yes it does. Did you get any issue?

from kubernetes-ingress.

(Using the default service file from github)

The logs for the pod say:

2019/07/13 21:18:08 main.go:84: Default ssl certificate: default/tls-secret

If I have a secret with that name, it will return it as the ssl cert, if I delete it, it won't respond to https, however, what I want to be able to do is specify a different secretName inside the actual ingress config as my original example shows. When I configure my ingress this way, it still doesn't support https via my valid certificate.

Also, when I grepped the source code in this repository, I found no location that would match a secretName as part of an Ingress config.

from kubernetes-ingress.

It uses extensions/v1beta1 afaict. Worked for me then.

from kubernetes-ingress.

Also, on a slightly unrelated note, during my attempts to test the above stuff, I caused my cert-manager ClusterIssuer to re-issue a tls cert stored in a new secret name, which worked fine, except for the part where cert-manager created a temporary fake ca cert while waiting for the real one to exist and when I tested my https ingress haproxy promptly loaded the fake one.. and then cached it forever. Nothing I tried worked to get the real cert to show up until I deleted the haproxy-controller pod at which point it promptly started serving me the real cert instead of the fake one.

Correct me if I'm wrong, but literally only deleting the haproxy pod should never cause it to return a different cert, right?

I don't think this particular issue is all that related to the secretName part, but it was very frustrating and I wanted to tell someone.

from kubernetes-ingress.

I'm having the same issue. I've tried setting a per-ingress certificate both using the .spec.tls[].secretName and the .metadata.annotations["haproxy.org/ssl-certificate"] properties -- both to no avail. HAProxy still only serves the default TLS certificate.

Within the container, there's only /etc/haproxy/certs/cert.pem, which contains the default certificate supplied via --default-ssl-certificate.

To me, it looks like the Ingress Controller does not respect any certificates other than its default cert AT ALL -- which I simply cannot believe to be by design.

Here's the ingress resource (redacted in parts):

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    # set out of mere desperation:
    haproxy.org/ssl-certificate: REDACTED/production-app-tls-acme
    kubernetes.io/ingress.class: haproxy
    kubernetes.io/tls-acme: "true"
  name: production-app
  namespace: REDACTED
spec:
  rules:
  - host: HOSTNAME_A
    http:
      paths:
      - backend:
          serviceName: production-app
          servicePort: 80
        path: /
  - host: HOSTNAME_B
    http:
      paths:
      - backend:
          serviceName: production-app
          servicePort: 80
        path: /
  tls:
  - hosts:
    - HOSTNAME_A
    - HOSTNAME_B
    secretName: production-app-tls-acme
status:
  loadBalancer:
    ingress:
    - hostname: XXX.eu-central-1.elb.amazonaws.com

from kubernetes-ingress.

Hi @rmzg, @martin-helmich

you can expect fix for this in next few days.
I'll notify you when this will be ready

from kubernetes-ingress.

new version v1.2.0 is released that fixes the behavior.
please note that if you define secret in ingress object,
you do not need to define default certificate in order to use https

from kubernetes-ingress.

format that controller expects is something like this:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: app
 namespace: default
 annotations:
   ingress.class: haproxy
spec:
 tls:
  - hosts:
	- foo.bar
	secretName: default/tls-secret
 rules:
 - host: foo.bar
   http:
	 paths:
              ......

regarding secret format, it is same as for default secret
https://github.com/haproxytech/kubernetes-ingress/tree/master/documentation#tls-secret

from kubernetes-ingress.