Add extraHosts and hosts from extraRules to tls block of Ingress resource

[maxnitze]

Name and Version

bitnami/*

What is the problem this feature will solve?

Hostnames can be configured in many ways in ingress blocks in charts. here's an example from the bitnami/keycloak chart:

ingress:
  enabled: true
  hostname: keycloak.my-first-domain.com
  annotations:
    # ...
  extraHosts:
    - name: login.my-first-domain.com
    - name: keycloak.my-second-domain.com
  extraRules:
    - host: login.my-second-domain.com
      http:
        # ...

When I now enable tls

ingress:
  # ...
  tls: true
  # ...

this results in only ingress.hostname in the tls block of the Ingress resource:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: # ...
  # ...
spec:
  rules:
    # ...
  tls:
    - hosts:
        - "keycloak.my-first-domain.com"
      secretName: keycloak.my-first-domain.com-tls
  # ...

What is the feature you are proposing to solve the problem?

Would it make sense to automatically add all hostnames, also the ones from ingress.extraHosts and from ingress.extraRules, to the tls block in the Ingress resource?

If so there would be two options (afaik).

Option 1: Add all hosts to single tls entry

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: # ...
  # ...
spec:
  rules:
    # ...
  tls:
    - hosts:
        - "keycloak.my-first-domain.com"
        - "login.my-first-domain.com"
        - "keycloak.my-second-domain.com"
        - "login.my-second-domain.com"
      secretName: keycloak.my-first-domain.com-tls
  # ...

Option 2: Create one tls entry per host

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: # ...
  # ...
spec:
  rules:
    # ...
  tls:
    - hosts:
        - "keycloak.my-first-domain.com"
      secretName: keycloak.my-first-domain.com-tls
    - hosts:
        - "login.my-first-domain.com"
      secretName: login.my-first-domain.com-tls
    - hosts:
        - "keycloak.my-second-domain.com"
      secretName: keycloak.my-second-domain.com-tls
    - hosts:
        - "login.my-second-domain.com"
      secretName: login.my-second-domain.com-tls
  # ...

One more thing to think about are duplicate entries. They probably need to be filtered out, so only one entry per domain is created (even though multiple entries should not break anything, I think).

What would be the way to go?

What alternatives have you considered?

Manually adding them to the ingress.extraTls block is the way we are currently going in such cases. Here's an example:

ingress:
  enabled: true
  hostname: keycloak.my-first-domain.com
  annotations:
    # ...
  extraHosts:
    - name: login.my-first-domain.com
    - name: keycloak.my-second-domain.com
  extraRules:
    - host: login.my-second-domain.com
      http:
        # ...
  tls: true
  extraTls:
    - secretName: login.my-first-domain.com-tls
      hosts:
        - "login.my-first-domain.com"
    - secretName: keycloak.my-second-domain.com-tls
      hosts:
        - "keycloak.my-second-domain.com"
    - secretName: login.my-second-domain.com-tls
      hosts:
        - "login.my-second-domain.com"

To reduce maintenance we sometimes use templating here:

ingress:
  enabled: true
  hostname: keycloak.my-first-domain.com
  annotations:
  # ...
  extraHosts:
    - name: login.my-first-domain.com
    - name: keycloak.my-second-domain.com
  extraRules:
    - host: login.my-second-domain.com
      http:
      # ...
  tls: true
  extraTls: |-
    {{- range .Values.ingress.extraHosts }}
    - secretName: {{ tpl .name $ }}-tls
      hosts:
        - {{ tpl .name $ }}
    {{- end }}
    {{- range (include "common.tplvalues.render" (dict "value" .Values.ingress.extraRules "context" $) | fromYaml) }}
    - secretName: {{ .host }}-tls
      hosts:
        - {{ .host }}
    {{- end }}

[fmulero]

Hi @maxnitze. Thank you for bringing this issue to our attention. We appreciate your involvement!

I see this proposal interesting but I don't see right now the ratio between the implementation cost and the gain in usability. As you mentioned, users can set those domains and the secrets with the certificates in their own way using extraTls (one secret for all domains or one per each domain). If we implement the options explained we will enforce users to use one certificate for all their domains (which is not possible in all the organizations) and/or a naming convention for the secrets to allow them use one secret per domain. If we don't want to add that restriction then we will need to add a value with the mapping between the hostname and the secret, but in that case we are adding more complexity in the implementation and for the user.

To be honest I like the flexibility of the extraTls value because you have all the options there and it can be easily adapted to the user needs.

Anyway, if you want to implement any of the proposals , we will be happy to review it.

[maxnitze]

I understand your points. I also like the flexibility of extraTls and would not remove it.

I think though, that it is a bit inconsistent with it since the "main domain" is automatically added, but others aren't. Also option 1 is not possible currently. There is no option to add hosts to the default tls item.

I'll not be able to do anything this week, but I'll try to prepare a PR beginning of next week with an idea how to implement both alongside each other.

[fmulero]

Thanks a lot @maxnitze

[maxnitze]

Would have prepared a PR earlier. But since the Ingress is a standard template used in all charts, I wanted to discuss this before preparing something.

[fmulero]

That's the reason what I said that I don't see the clearly the ration between implementation cost and the gain in usability. I understand your point and I agree that current solution is not complete, we are allowing users to set extraHosts but we are not taking care of that value in the TLS config. To do it properly we should keep in mind serveral points:

• Are we auto-generating TLS certificates? Then we should add all common names to those certificates.
• The user is setting their own certificates?
  • How can we map the certificates and the hostnames?
  • Wildcard certificates are allowed?
  • Should we allow a mix? I mean some hostnames with wildcard and other with their own certficate.

[github-actions[bot]]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[github-actions[bot]]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.

[maxnitze]

Just stumbled upon this issue again and saw, that I never actually answered this sorry for that!

I see your points there. After some fiddling in our own charts, I came to the conclusion that adding this as a feature is not really easily doable. All the questions you asked should probably be added as features/feature-flags. And that's going to be a mess, I think.

Additionally, if you are providing additionalHosts, then its okay, from my perspective, that you also provide the additional TLS blocks for them.

One thing, that might stil be interesting as a feature though would be to be able to add extra hosts to the first TLS block (basically option 1). Maybe I will provide a PR for the template, when I find the time.