HTTPS support

[joelcraenhals]

Hi,

Would you be willing to configure the docker container to support HTTPS access to Jira with a custom keystore?

Thanks,
Joël

[cptactionhank]

Sorry, there is no plan to implement this. The usual practice i see it keeping SSL termination external like using NGIN X or HAProxy as a frontend for the service.

Perhaps you can override the default Java keystore file with your own if it's really needed. You could also utilize docker cp and docker exec to copy the keystore and apply the changes. But it is out of scope of what I'm aiming for at the moment.

[jhgorse]

@cptactionhank: I had tried in the past to do ssl termination at JIRA/Confluence. It is not the intended use.

[cptactionhank]

There will unfortunately not be made features to configure keystorea and SSL front lens support in this image. The better way which is already supported is to use a proxy server as front end with ssl termination like HAproxy or NGINX.

Have a second look at https://confluence.atlassian.com/adminjiraserver071/integrating-jira-with-apache-using-ssl-802593043.html

You also can create you own image using mine as a base where you provide your own modified server.xml filer and Java keystore file.

[ghost]

Expanding what cptactionhank has said (& simplifying the linked page), I have just setup a system with SSL and used a free LetsEncrypt cert (fullchain) on an Nginx server providing a reverse proxy.

I did have to make a change to the default Docker container, but it was simply adding 'scheme="https" proxyName="jira.mydomain.com" proxyPort="443"', to the only enabled Connector section in the /opt/atlassian/jira/conf/server.xml file.
It looks to be working great.

[jhgorse]

@darren-harrison I'd be curious to see your setup without any sensitive details. Would you mind sharing it?

[ghost]

The nginx config is as follows:
server {
listen [::]:80;
server_name jira.mydomain.com;
return 301 https://$server_name$request_uri;
}

server {
listen [::]:443 ssl;
server_name jira.mydomain.com;

ssl_certificate /etc/letsencrypt/live/jira.mydomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/jira.mydomain.com/privkey.pem;

location /.well-known {
alias /somepath/Websites/atlassiancert/.well-known;
}

location / {
proxy_pass http://dockerhostname:8082/;
}

}
Then I run it with the following settings

docker run --restart=always -d --name jira -v ${DOCKER_PATH}/jira:/var/atlassian/jira --env "CATALINA_OPTS= -Xms256m -Xmx512m" -p 0.0.0.0:8082:8080 cptactionhank/atlassian-jira-software:latest

Is there anything else you are interested in?

[jhgorse]

Yes, I was having difficulty getting the system integration of all of it together. The remaining piece for a production deployment is the PostgreSQL via docker for JIRA/Atlassian stuff.

I was able to get PostgreSQL docker container up, running, configured, and accessible to localhost, but connecting it to the JIRA docker container stumped me.

[ghost]

There might be some firewall issues there. Our setup uses a MySql server on the docker host. I'm certain the Docker people would disapprove but it works great for us.
Perhaps try something like the last comment on this issue -> #12

[jhgorse]

hmm... I thought I had disabled the firewall. I will have to break out my local test env again. Cheers!

[failedguidedog]

Hi,

I've used the suggested solution by putting a SSL-terminating proxy in front of the Jira container (I'm using haproxy).
However, there were issues with some of the resources (some images and such) that were trying to get loaded using unencrypted HTTP. The only solution for this was to reconfigure the Jira's Connectors (from /opt/attlassian/jira/conf/server.xml), put it in /var/attlassian/jira/ (so I was able to edit it and change its permissions), then overwrite the original file and then restart the container.

I am aware this is not the correct solution, but I was really trying to avoid building a new docker image with only this change.

It would be awesome if this could be somehow configurable through environment variables, unfortunately I'm currently all out of time to tackle this.

Sample Connector config:

<Connector port="8080"
           maxThreads="150"
           minSpareThreads="25"
           connectionTimeout="20000"
           enableLookups="false"
           maxHttpHeaderSize="8192"
           protocol="HTTP/1.1"
           useBodyEncodingForURI="true"
           redirectPort="8443"
           acceptCount="100"
           disableUploadTimeout="true"
           proxyName="example.com"
           proxyPort="443"
           scheme="https"/>

<Connector port="8081"
           maxThreads="150"
           minSpareThreads="25"
           connectionTimeout="20000"
           enableLookups="false"
           maxHttpHeaderSize="8192"
           protocol="HTTP/1.1"
           useBodyEncodingForURI="true"
           redirectPort="8443"
           acceptCount="100"
           disableUploadTimeout="true"/>

Anyway, thank you for your efforts @cptactionhank :)

[ghost]

The boss might have something else to say on this, but in one thread around here, there was mention of the following variables. I have tried & maybe I'm not using them right but I don't think they worked for me.

docker run --restart=always -d --name jira -v ${DOCKER_PATH}/jira:/var/atlassian/jira
--env "CATALINA_OPTS= -Xms512m -Xmx2g"
--env "X_PROXY_NAME=jira.ourcompany.com"
--env "X_PROXY_PORT=443"
--env "X_PROXY_SCHEME=https"
-p 0.0.0.0:8082:8080

Indeed. Thank you for your hard work @cptactionhank !

Darren.

[failedguidedog]

@darren-harrison Thank you, I can see that these are used in the docker-entrypoint.sh to modify the server.xml in runtime. I'll check if this works in my case and report back.

[laurensvr]

@darren-harrison thanks, the environment variables solved my problem 👍

The Jira part of my docker-compose.yml file:

jira:
    container_name: jira-container
    image: cptactionhank/atlassian-jira-software:latest
    environment:
      - CATALINA_OPTS=-Xms768m -Xmx1024m
      - X_PROXY_NAME=jira.domain.net
      - X_PROXY_PORT=443
      - X_PROXY_SCHEME=https
    volumes:
      - ./jira:/var/atlassian/jira

[ain]

This feed is really fragmented and all solutions are distributed solutions (no single point of entry).

If this ticket gets resolved, there needs to be some universal documentation on how to use SSL with the containers that are running behind a proxy.

Update: reproduced on 7.4.0. Gadgets fail:

[ain]

Problem persists on 7.4.1. Still constantly timing out rendering application almost unusable :(

[cptactionhank]

Most likely you have not updated base-path, it's more of an JIRA configuration thing

[pfried]

From my experience a configurable keystore would be a solution to this problem:

Even when using a ngnx proxy (as we do), there is an issue where one atlassian instance (jira / bamboo/ confluence) does not trust another (or even itself) when using a custom certificates from a custom CA (this is true for most company networks).

[pfried]

I want to correct myself as I have now solved the issue for me. The below Dockerfile extends this repo and adds a CA certificate to the keystore of Java (it doesnt help to add a custom keystore to jira since that is only used if the tomcat is doing https on its own)

FROM cptactionhank/atlassian-jira-software:latest

USER root:root

COPY certificates /tmp/certificates

RUN $JAVA_HOME/bin/keytool -storepass changeit -import -noprompt -trustcacerts -alias ca -keystore $JAVA_HOME/jre/lib/security/cacerts -file /tmp/certificates/ca.cer

USER daemon:daemon