data-center-helm-charts icon indicating copy to clipboard operation
data-center-helm-charts copied to clipboard

[Suggestion] - Allow setting TLS host(s)

Open pathob opened this issue 3 years ago • 5 comments

Suggestion

Dear Atlassian charts team,

we would like to be able to set the TLS host(s) separately from the normal (rules) hosts to make it easier to work with wildcard certificates (issued e.g. with Letsencrypt) which is especially useful on pre-prod environments.

Example known from many other charts:

  ingress:
    enabled: true
    apiVersion: ...
    hostName: service.staging.example.com
    tls:
    - hosts:
      - *.staging.example.com
      secretName: tls-secret
    ...

Thank you Patrick

Product

Jira, Confluence, Bitbucket, Other

Code of Conduct

  • [X] I agree to follow this project's Code of Conduct

pathob avatar Nov 23 '21 07:11 pathob

@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.

nanux avatar Jan 11 '22 02:01 nanux

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 avatar Jan 11 '22 04:01 pathob

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 avatar Jan 11 '22 04:01 nanux

I will get back to you soon, thanks

pathob avatar Jan 11 '22 04:01 pathob

Hey @pathob,

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

errcode1202 avatar Apr 06 '22 03:04 errcode1202

@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 avatar Nov 16 '22 20:11 bianchi2

Closing due to no response. Feel free to reopen.

bianchi2 avatar Dec 05 '23 19:12 bianchi2