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]

Enabling anonymous access should not be the default

[alxgomz]

Agreed. I first tried to make it point to another env var but it did not work and I concluded the plugin attribute anonymousAccessAllowed is simply not looked up from the java system properties unlike authenticationUser attribute (e.g. username or password).
Given the default behavior of the exisitng image was already to come up with anonymous access enabled (one has to provide $ACTIVEMQ_CONNECTION_USER to disable it), I've decided to let anonymous access enabled b default as well.

I personally have no problem with setting it to false b default instead, unless there's a way to make the plugin initialization lookup a java system property for anonymousAccessAllowed?

[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).