data-center-helm-charts
data-center-helm-charts copied to clipboard
[Suggestion] - Allow setting TLS host(s)
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, 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.
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
andingress.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:
- that helps to prevents from running into the "Certificates per Registered Domain" limit by Letsencrypt
- 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!
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?
I will get back to you soon, thanks
Hey @pathob,
Just wondering if you've had time to look into this yet? If not I might close this issue for now.
@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).
Closing due to no response. Feel free to reopen.