Atlassian public docker hub images updated massively

Question

Hello,

in our environment, we use Confluence, Jira, and Bitbucket on Kubernetes. We noticed that the pod containing the Jira image (version 9.4.14) no longer starts. In the logs we observed the following:

INFO:root:Generating /opt/atlassian/jira/conf/server.xml from template server.xml.j2 │
WARNING:root:Permission problem writing '/opt/atlassian/jira/conf/server.xml'; skipping │
INFO:root:Generating /opt/atlassian/jira/atlassian-jira/WEB-INF/classes/seraph-config.xml from template seraph-config.xml.j2 │
WARNING:root:Permission problem writing '/opt/atlassian/jira/atlassian-jira/WEB-INF/classes/seraph-config.xml'; skipping │
INFO:root:/var/atlassian/application-data/jira/dbconfig.xml exists; skipping. │
INFO:root:Running Jira with command '/opt/atlassian/jira/bin/start-jira.sh', arguments ['/opt/atlassian/jira/bin/start-jira.sh', '-fg'] │
Traceback (most recent call last): │
File "/entrypoint.py", line 31, in <module> │
exec_app([f'{JIRA_INSTALL_DIR}/bin/start-jira.sh', '-fg'], JIRA_HOME, │
File "/entrypoint_helpers.py", line 168, in exec_app │
os.execv(cmd, args) │
PermissionError: [Errno 13] Permission denied

We noticed that the permissions on the "/opt/atlassian/jira" folder has changed (from rwxr-xr-x jira root to r-xr-x--- jira root). After our investigation we found that the version 9.4.14 (and many others) of the Jira image, released in December, was updated three days ago by "rtcentraluploader". We can also confirm that Confluence and Bitbucket have the same permission issue (in /opt/atlassian/confluence and /opt/atlassian/bitbucket).

Did anyone have the same problem?

Thanks.

Yevhen_5guu4k · Answer

@Haquiel Jusino make sure you set https://github.com/atlassian/data-center-helm-charts/blob/main/src/main/charts/jira/values.yaml#L753 and https://github.com/atlassian/data-center-helm-charts/blob/main/src/main/charts/jira/values.yaml#L789 to true. This way, configmaps will be created and mounted as files to the container.

Haquiel Jusino · Answer

Hello,

I am currently running into a similar issue. Here are my logs for the issue:

INFO:root:Generating /etc/container_id from template container_id.j2
INFO:root:Generating /opt/atlassian/jira/conf/server.xml from template server.xml.j2
WARNING:root:Permission problem writing '/opt/atlassian/jira/conf/server.xml'; skipping
INFO:root:Generating /opt/atlassian/jira/atlassian-jira/WEB-INF/classes/seraph-config.xml from template seraph-config.xml.j2
WARNING:root:Permission problem writing '/opt/atlassian/jira/atlassian-jira/WEB-INF/classes/seraph-config.xml'; skipping
INFO:root:Generating /var/atlassian/application-data/jira/dbconfig.xml from template dbconfig.xml.j2
INFO:root:Generating /var/atlassian/application-data/jira/cluster.properties from template cluster.properties.j2
WARNING:root:Unsetting environment var ATL_JDBC_PASSWORD
INFO:root:Running Jira with command '/opt/atlassian/jira/bin/start-jira.sh', arguments ['/opt/atlassian/jira/bin/start-jira.sh', '-fg']
executing as current user

and for reference, here is the securityContext:

securityContextEnabled: true
securityContext:
fsGroup: 2001
containerSecurityContext:
runAsUser: 2001

Yevhen_5guu4k · Answer

I see. Access to others have been revoked on purpose, following recent DC CVEs. Is it an option for your to make nfs dirs writable for respective container users and run containers with the default securityContext?

Also, it'd be great if you can share your existing securityContext. I think it's runAsGroup that makes things break. Will it work for you to keep runAsUser: <your-nfs-user> but drop runAsGroup or set it to 0? This way, a user will belong to a root group and root group has rx permissions for the install dir, and at the same time this user is allowed to read and write to your nfs partition.