Copy ssl cert/key/cafile and configure permissions on startup

[thenewguy]

If the cert/key/cafiles are passed into the docker container as volumes with 0400 permissions owned by the root user in the host system then rabbitmq segfaults.

This is unexpected.

The entrypoint script should copy these files and apply the correct permissions that rabbitmq expects.

Currently I have to work around this by setting the permissions to 0777 on the host machine. This is dangerous =/

[yosifkit]

It just needs to be readable by the rabbitmq user in the container, which happens to be user id 999. On the other hand, with #60 you will be able to specify which non-root user id and/or group id to run it as and just make sure that that user or group has access to the certificates.

[thenewguy]

@yosifkit That isn't so simple when the certificates are passed into the container as a volume. Since the permissions are set on the host system without any knowledge of the container. I think it would be simpler to handle this in the entrypoint script wouldn't it?

[oryband]

might be related to #66 ?

[oryband]

@yosifkit your statement isn't true. see #66

[tianon]

Sorry for the delay here -- I'm honestly not sure how we can even help here. If RabbitMQ can't read the files passed to it, our entrypoint script likely won't be able to either. It isn't run with any higher privileges than RabbitMQ itself is.

It's also possible the refactoring in #94 might've helped here. Can anyone verify that this is still an issue, and perhaps provide a very short set of commands to run to easily replicate it if so?

[EdeMeijer]

I'm having the same (or a similar) problem. I'm using a SAN certificate, which means I'm using a single certificate for multiple (sub) domains that resolve to the same IP address. Hence, the certificate I'm using is not exclusively for RabbitMQ, lives on the host filesystem and is owned by root. Having it being owned by anything other than root wouldn't make sense in this scenario I think.

I mounted the directory with the certs as a read-only volume to the RabbitMQ container. In the entrypoint, after the exec gosu rabbitmq "$BASH_SOURCE" "$@" command, the rest of the container is run as the rabbitmq user (999) and the mounted files cannot be read anymore, although before that command, they can.

I understand why RabbitMQ is run as a non-root user, but maybe it would be an idea to make a copy of the certificates before decreasing the privileges in the entrypoint script. Copying them to a container volume and making them readable by the rabbitmq user should fix the problem I think.

Thoughts about this scenario?

[michaelklishin]

RabbitMQ itself assumes that certificate management happens at deployment/provisioning time and that the certificates are readable by the node (sorry if this insults someone's intelligence). So what @EdeMeijer suggests makes sense. I'm not an expert on how certificate/key pairs are managed in Docker images, however.

[michaelklishin]

@EdeMeijer I suggest that you file a new issues since you have a specific use case and solution proposal ;)

[EdeMeijer]

I went with a different approach that worked for me and arguably is cleaner than copying around sensitive data into containers.

• I created a certs user + group on the host (without login permissions etc)
• I created a dedicated rabbitmq user on the host and added it to the certs group
• I chowned everything in my host certificate directory to certs:certs
• I chmoded everything in my host certificate directory with g+rx so that the certs group member can access and read, but not modify, the certificates.
• I added user: '[rabbitmq uid]:[certs gid] to my docker-compose.yml file for the rabbitmq service

Because the container now starts with a uid other than 0, it doesn't gosu to the internal rabbitmq user with uid 999 but sticks to what I configured on the host. It can now properly access the certificates and SSL works without problems.

The drawback here of course is that this solution requires some more configuration on the host machine, which I like to keep to a minimum in a containerized environment.

Probably a better solution, since I'm using Docker Swarm, is to use the 'secrets' feature, but I'll have to look into that.

[tianon]

Given that OP's issue appears to be around permissions (and is resolved), I'm going to close. Hopefully the discussion here serves as a useful reference for folks having the same issue in the future. 👍