[Suggestion] - Allow setting TLS host(s) about data-center-helm-charts

[nanux]

Thank you for the explanation. If you have a working example, would you mind raising a PR with the proof of concept and describe how to test the setup?

[nanux]

@pathob, can you please expand on the use case? Do you want to define a fully qualified domain name for the instance host and wildcard for TLS hosts? E.g. ingress.host: jira.staging.example.com and ingress.tlsHost: *.staging.example.com?

In our setup we are usually using ingress configuration that is described here:
https://atlassian.github.io/data-center-helm-charts/examples/ingress/INGRESS_NGINX/#ingress-resource-configuration

We have a wildcard certificate for the domain and then we have an Issuer that will create a TLS certificate for the instance domain name when it is installed. Would this setup work for you?

I just would like to understand whether we need to extend the helm chart to cater for a new use case and if so, understand the use case in more detail. Thank you very much.

[pathob]

Hi @nanux

Do you want to define a fully qualified domain name for the instance host and wildcard for TLS hosts? E.g. ingress.host: jira.staging.example.com and ingress.tlsHost: *.staging.example.com?

Yes, exactly

In our setup we are usually using ingress configuration that is described here: https://atlassian.github.io/data-center-helm-charts/examples/ingress/INGRESS_NGINX/#ingress-resource-configuration

We have a wildcard certificate for the domain and then we have an Issuer that will create a TLS certificate for the instance domain name when it is installed. Would this setup work for you?

I'm not sure whether I fully understand. Yes, we're also using the ingress configuration you mentioned. And we are also working with an issuer (ClusterIssuer) that can issue TLS certificates for the instance domain name (e.g. jira.staging.example.com). The problem is, that we cannot make the cert-manager issue or re-use existing wildcard-certificates in pre-production environments. And we would like to be able to use wildcard-certificates here, because:

1. that helps to prevents from running into the "Certificates per Registered Domain" limit by Letsencrypt
2. issuing a new TLS certificate for the instance domain name can take a moment and makes deployments very slow when many instances are involved.

To give more details: in our setup, developers can create a new test environment dynamically based on a PR and involving quite a large number of services, e.g.

• developer 1: jira.pr42.example.com, confluence.pr42.example.com, keycloak.pr42.example.com, jenkins.pr42.example.com, ...
• developer 2: jira.pr43.example.com, confluence.pr43.example.com, keycloak.pr43.example.com, jenkins.pr43.example.com, ...
• etc.

Being able to set ingress.tlsHost: *.pr42.example.com would allow us to work with the same wildcard certificate in all instances (cert-manager automatically takes care of that). I also tried to solve that with cert-manager "Ingress shims" but that doesn't seem to be possible.

I hope this explanation is more clear now.

Thank you!

[pathob]

I will get back to you soon, thanks

[errcode1202]

Hey @pathob,

Just wondering if you've had time to look into this yet? If not I might close this issue for now.

[bianchi2]

@pathob I can see what you are trying to achieve here. I was just wondering if wildcard works for you in rules[0].host. Obviously not, otherwise you'd never raise this issue. The change should be pretty straightforward:

spec:
{{ if and (.Values.ingress.tlsSecretName) (.Values.ingress.tlsHost) }}
  tls:
    - hosts:
        - {{ .Values.ingress.tlsHost }}
      secretName: {{ .Values.ingress.tlsSecretName }}
{{ end }}

and in values have ingress.tlsHost or even better a list of hosts (then the syntax in ingress template will be different).

[bianchi2]

Closing due to no response. Feel free to reopen.