Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Suggestion] - Allow setting TLS host(s) #350

Closed
1 task done
pathob opened this issue Nov 23, 2021 · 7 comments
Closed
1 task done

[Suggestion] - Allow setting TLS host(s) #350

pathob opened this issue Nov 23, 2021 · 7 comments
Labels

Comments

@pathob
Copy link
Contributor

pathob commented Nov 23, 2021

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

  • I agree to follow this project's Code of Conduct
@nanux nanux added the enhancement New feature or request label Jan 9, 2022
@nanux
Copy link
Member

nanux commented Jan 11, 2022

@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
Copy link
Contributor Author

pathob commented Jan 11, 2022

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!

@nanux
Copy link
Member

nanux commented Jan 11, 2022

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?

@pathob
Copy link
Contributor Author

pathob commented Jan 11, 2022

I will get back to you soon, thanks

@errcode1202
Copy link
Collaborator

Hey @pathob,

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

@bianchi2
Copy link
Collaborator

@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
Copy link
Collaborator

bianchi2 commented Dec 5, 2023

Closing due to no response. Feel free to reopen.

@bianchi2 bianchi2 closed this as completed Dec 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants