Why does BinderHub Helm chart force the use of kube-lego?

[sc250024]

Greetings,

I'm curious why the ingress.yaml template was only written for the usage of kube-lego ? The below ingress.yaml template is taken from version binderhub-0.1.0-230bbde of the BinderHub Helm chart:

{{- if .Values.ingress.enabled -}}
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: binderhub
  {{- if or (and .Values.ingress.https.enabled (eq .Values.ingress.https.type "kube-lego")) .Values.ingress.annotations }}
  annotations:
    {{- if eq .Values.ingress.https.type  "kube-lego" }}
    kubernetes.io/tls-acme: "true"
    {{ end -}}
    {{- range $key, $value := .Values.ingress.annotations }}
    {{ $key }}: {{ $value | quote }}
    {{- end }}
  {{- end }}
spec:
  rules:
    {{- range $host := .Values.ingress.hosts }}
    - host: {{ $host }}
      http:
        paths:
          - path: /
            backend:
              serviceName: binder
              servicePort: 8585
    {{- end }}
{{- if and .Values.ingress.https.enabled (eq .Values.ingress.https.type "kube-lego") }}
  tls:
    - secretName: kubelego-tls-binder-{{ .Release.Name }}
      hosts:
        {{- range $host := .Values.ingress.hosts }}
        - {{ $host }}
        {{- end }}
{{- end }}
{{- end -}}

I understand the desire to have things "just work" out of the box, but this seems inconvenient for anyone who either uses their own TLS certificate, or is using cert-manager (like we are) with a cluster-wide wildcard certificate. The kube-lego project will not be maintained in the near future, and mentions cert-manager as a replacement; the README.md for the kube-lego project even mentions this:

kube-lego is in maintenance mode only. There is no plan to support any new features. The latest Kubernetes release that kube-lego officially supports is 1.8. The officially endorsed successor is cert-manager.

Any reasons for a very opinionated ingress template?

[sc250024]

Opened a PR above to solve this issue.

[minrk]

BinderHub doesn't force the use of kube-lego, but it provides shortcuts to more easily enable https with letsencrypt by setting a single flag, rather than requiring lots of custom configuration.

[sc250024]

@minrk That's almost the case. The entire template doesn't force kube-lego, but the TLS section does:

{{- if and .Values.ingress.https.enabled (eq .Values.ingress.https.type "kube-lego") }}
  tls:
    - secretName: kubelego-tls-binder-{{ .Release.Name }}
      hosts:
        {{- range $host := .Values.ingress.hosts }}
        - {{ $host }}
        {{- end }}
{{- end }}

The way I read it, TLS is only activated if .Values.ingress.https.enabled is true, and if the .Values.ingress.https.type is kube-lego. Even if those are faked (i.e. you're not using kube-lego, but want TLS from your own certificate, so you set .Values.ingress.https.type to kube-lego anyway) you can't control the secretName. My latest commit in #677 should solve that.