Giters

atlassian / data-center-helm-charts

Helm charts for Atlassian's Data Center products

Home Page:https://atlassian.github.io/data-center-helm-charts/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Suggestion] - Flag to remove setup ingress in Confluence helm chart

madhosoi opened this issue · comments

commented

Suggestion

Hi,
We cannot find the goal of split the ingress of Confluence in 2 different ingresses, but to move the setup process (/setup & /bootstrap) to an internal URL, and mitigate the risks of exposing the setup software externally.
But, the current configuration does not work like it, as the helm chart is sharing the same variable in the 2 ingresses.
Our suggestion is to remove that ingress and add a new variable to add it only in case the deployment responsible confirm it via a new variable. Also, could you add some ingress configuration in the software to block that traffic?
We are doing something like this:
A new annotation in the ingress:
rewrite ^/setup /not_found break; rewrite ^/server-info.action /not_found break;
And change the service port of the setup ingress to 81, where none is listening.
Thanks!

Product

Confluence

Code of Conduct

  • I agree to follow this project's Code of Conduct
commented

hi @madhosoi removing setup ingress will not make Confluence unavailable and the main ingress will still match the setup path. Setup ingress just increases timeouts as it may take long to setup database (and that's the reason it has been added to the chart). If you do not want to expose Confluence during the setup process there are a couple of ways to achieve it:

  • via security groups (allow access only from a predefined IP range for a setup period) or
  • skip creating ingresses on the first deployment (define ingress.host and keep ingress.create to false). Once deployed, you can do port-forward and setup Confluence on localhost. After that, run helm upgrade again with ingress.create set to true.

As to annotations, you can pass any custom annotations to the ingress in your values.yaml.

commented

Hi @bianchi2 , thanks for the quick answer.
Our main question here is: what is the point of that setup ingress, if the deployment variables of them are the same? Why not only have one? We want to solve the latest CVE in as many layer as possible. We put in place different measures, but the automation of the deployment is complex as we must add some annotations and remove the setup ingress for clarity.
Thanks again for the support.

commented

Hi @bianchi2 again, 😅
Just realised you edited the content.
I have now a clear answer of my last question.

Thanks!