Unable to start RabbitMQ docker with SSL cert / key when mounted as a volume

[prisma2user]

This appears to have been an issue that was opened in the past (#59 & #283) and was subsequently resolved / fixed (#285), however, it seems that a few years back these changes were removed in an effort to simplify the entrypoint script as most of the rabbitmq configuration was moved from Environment Variables to using a configuration file (see https://github.com/docker-library/rabbitmq/pull/467/files#diff-79738685a656fe6b25061bb14181442210b599f746faeaba408a2401de45038aL85).

The issue I have is that while I can mount a configuration file and specify the TLS configuration, the problem exists where the SSL certificates that I am attempting to use within the RabbitMQ container are defined on the host and are owned by the root user and thus when RabbitMQ starts, it is unable to access the SSL KEY file as its permissions on the host are 400 root:root.

I am not able to change the permissions of this file on the host machine as it is managed by puppet so that it can dynamically define the certificates Subject Alternative Names as the certificate is used for many different things and Puppet will automatically renew the certificate before expiration. With that in mind, I can't rely on a "copy cert into container" and would very much prefer to just mount the certificate and key files into the container with Read Only permissions (as I don't want to allow the container to modify the actual host files since Puppet would detect these changes and rever them) and then as part of the RabbitMQ entrypoint script it could copy these files somewhere else so that they can be owned and accessible to the rabbitmq user and leveraged when starting up the application.

[lukebakken]

Hello and thanks for using RabbitMQ.

I'm not convinced that you are unable to change the certificates' permissions via Puppet. Can you provide a concrete example showing why this is not possible?

Your best solution at this time is to modify the certificates' permissions, or, copy them to another place that can have the correct permissions (uid 999 / gid 999) so that you can mount them.

[prisma2user]

The issue is not that I can't change the permissions of the certificate, it is that it is not desired to change the permissions of the certificate as it is desired to maintain the host certificate permissions as being 644 root:root for the certificate and 600 root:root for the key for security purposes.

Many other applications are able to access certificates that maintain these permissions and ownership because the initial process is started with the root user who does have access to view and obtain the information in these files prior to starting the application in its more limited user / service account permissions

[lukebakken]

Thanks for the clarification. See my second solution in which you copy the files so you can set the correct owner. They can still remain 400 access permissions, of course.

[prisma2user]

Yes, I realize we could copy these files into the container, but this defeats the purpose since then I need to create my own docker image based off this one, copy my certificates into the image and then deploy / run the container. In order to do that I need to copy the host certificate and key into another directory where this new custom Dockerfile would be maintained to build this new image from.

When in an alternative view, we could just mount the certificate and key into the container and then they could be read at the time when the root user has access to these files just prior to starting rabbitmq.

No need to build custom images and copy cert and key files around on the host to maintain. If the certificates ever change a quick docker-compose down / up can have those take effect

[lukebakken]

I realize we could copy these files into the container

I'm suggesting that you copy them on the host, not the container. Then set permissions on the host and mount that path.

When in an alternative view, we could just mount the certificate and key into the container and then they could be read at the time when the root user has access to these files just prior to starting rabbitmq.

Please feel free to open a PR and / or provide code that demonstrates this solution. That would go a long way towards convincing me of adding code that would have to be maintained going forward.

@tianon @michaelklishin any thoughts about this?

[prisma2user]

I'm suggesting that you copy them on the host, not the container. Then set permissions on the host and mount that path.

I suppose I could do this, still not ideal having to maintain extra certificates on the host.

Please feel free to open a PR and / or provide code that demonstrates this solution. That would go a long way towards convincing me of adding code that would have to be maintained going forward.

If there is consensus that this would be approved to merge, I can submit a PR for this.

[lukebakken]

If there is consensus that this would be approved to merge, I can submit a PR for this

Why would we approve a PR we haven't even seen in two years? I'm closing this.

[prisma2user]

lol... Not sure why you are resurrecting this issue after 2 years when all I asked 2 years ago was for clarification if there was even a path forward for a PR given the prior conversation... So no surprise there isn't a PR if there was zero chance of it being merged.