WIP: Run activemq container as non root

[alxgomz]

This PR is a proposal to address https://issues.apache.org/jira/browse/AMQ-9588

It's trying to keep the same behavior of the container and essentially:

• Leverage properties lookup where possible so configuration can be done using env vars rather than sed (unfortunatelly properties lookup do not work for the anonymousAccessAllowed param of simpleAuthenticationPluginso I left it on by default to mimic to previous behavior)
• Allow building images with non default credentials
• Switch build process to multistage build to allow more robust installation/configuration of the activemq distrib
• Fix web console auth for ActiveMQ 5.x
• Create a non privileged user to run to service
• Update doc

[mattrpav]

1. Leaving JMX enabled, but optionally exposing the port is a simple approach to remove a lot of scaffolding.

2. Why is JAAS not the default just like the dist?

[alxgomz]

Hi @mattrpav thanks for taking the time to review.

1. Toggling JMX on and off is actually the very lightweight part of this PR. To be honest I have introduced it because I wanted to keep a similar behaviour to what pre-existed. But I would personally remove it completely given, a) JMX is such a pain in most docker environments and really not well suited to NAT networks in general and b) the authentication as it is set right now simply doesn't work: even if user and password are set one can still login anonymously as soon as the createConnector param is set t io true (btw, the doc seems to mention the jmx authenticated access should be set up using java OPTS and with the ManagementContext turned off but I could not get it to work). And c) I remember reading theere's a jolokia endpoint available somewhere that would deliver just the same data in a more friendly fashion. But I decided I would not make this kind more disruptive approach.

2. The reason I did not used JaaS to configure web user s because I'm working with ActiveMQ 5.18 which do not seem to have the appropriate classes available and throws this error when trying to do use it:

ERROR | Failed to load: class path resource [activemq.xml], reason: Failed to load type: org.eclipse.jetty.jaas.JAASLoginService. Reason: java.lang.Cl
assNotFoundException: org.eclipse.jetty.jaas.JAASLoginService; nested exception is java.lang.ClassNotFoundException: org.eclipse.jetty.jaas.JAASLoginS
ervice                                                                                                                                                
org.springframework.beans.factory.BeanDefinitionStoreException: Failed to load type: org.eclipse.jetty.jaas.JAASLoginService. Reason: java.lang.ClassN
otFoundException: org.eclipse.jetty.jaas.JAASLoginService; nested exception is java.lang.ClassNotFoundException: org.eclipse.jetty.jaas.JAASLoginServi
ce

Taking a look at the 5.x distribution I saw the default user was using jetty-realm properties file which was only available in 5.x dists so I chose to rely on the presence of this file to decide wether I would set the default web user

[alxgomz]

@mattrpav as you renamed this PR title I was wondering whether you were expecting more work from me or are yo planning to take over from here?

[jbonofre]

I'm sorry, but I don't understand the overall purpose. What's exactly the problem statement ?

[alxgomz]

I'm sorry, but I don't understand the overall purpose. What's exactly the problem statement ?

Sorry if that's not clear. What I'm trying to do here is to produce an image which will:

• run as non root user by default
• have a more robust configuration stage (mainly using a true xml parser rather than sed-ing in xml)
• leverage java system properties where possible instead of modifying files on the fly with the entrypoint

That's mainly to conform to 2 container best practices: to not run as root and to not run container with a read-only fs

[jbonofre]

I'm sorry, but I don't understand the overall purpose. What's exactly the problem statement ?

Sorry if that's not clear. What I'm trying to do here is to produce an image which will:

• run as non root user by default
• have a more robust configuration stage (mainly using a true xml parser rather than sed-ing in xml)
• leverage java system properties where possible instead of modifying files on the fly with the entrypoint

That's mainly to conform to 2 container best practices: to not run as root and to not run container with a read-only fs

Ok, it's clearer for me now. As I see more than "just" non root privileges, it wasn't obvious to me.

Let me do a new review/pass (fyi, I'm the original author of the Docker image build).

[mattrpav]

I'm wondering if there is a better approach where we can have a simple generic config by default, and a config flag to replace ${activemq.conf} location. This would allow user to provide a volume with any set of configuration files the wish.

[jbonofre]

@mattrpav yeah. I'm not a big fan deviating from the default amq config.

[alxgomz]

I'm wondering if there is a better approach where we can have a simple generic config by default, and a config flag to replace ${activemq.conf} location. This would allow user to provide a volume with any set of configuration files the wish.

That's definitely a good approach for advanced config where having env vars or doing on-the-fly modification of config files will never really be enough. However for the most simple cases where one may just want to set credentials having to create a volume (which may vary greatly whether you're running just docker or kubernetes or or something else) and having to scaffold it with he right version of the config, may look a bit too much

[alxgomz]

Hi gentlemen,

Reaching out to know whether you came to a conclusion on that PR? Should I change the current behaviour and make the image reject anonymous request by default? Or do you prefer to simply discard the PR and come up with something of your own?

[jbonofre]

@alxgomz I'm doing a new pass (I'm preparing the next ActiveMQ releases).

[alxgomz]

Hi @jbonofre, Any progress on this or should I consider it declined?