Maven fabric8 plugin fails to run docker container in pipeline

Issue #15505 resolved
Moritz Becker
created an issue

I am running a maven build that uses io.fabric8:docker-maven-plugin:0.23.0 to spawn docker containers for integration testing during mvn install. This works fine locally, but when executed with Bitbucket Pipelines, I get the following error:

[INFO] DOCKER> Pulling from library/postgres
[INFO] DOCKER> Digest: sha256:d6150452877361e26d0fd178d278af8f80d59c75cbb5c2413cfb4fdb5ed4f750
[INFO] DOCKER> Status: Downloaded newer image for postgres:10-alpine
[INFO] DOCKER> Pulled postgres:10-alpine in 2 seconds 
[ERROR] DOCKER> Error occurred during container startup, shutting down...
[ERROR] DOCKER> I/O Error [Unable to create container for [postgres:10-alpine] : authorization denied by plugin pipelines: Command not supported. (Forbidden: 403)]

So it seems that docker itself is working since the image is fetched successfully but when it comes to actually starting a container, the pipelines plugin forbids the operation. On the contrary, a literal docker run -d postgres:10 inside my pipeline step works.

Official response

Comments (17)

  1. Matt Ryall staff

    Thanks for raising this, @Moritz Becker.

    This error message indicated that starting the Docker container was forbidden by our Docker authorization plugin that prevents a small number of commands that are not safe to allow in our shared infrastructure. As described in our documentation:

    Pipelines prevents the execution of Docker swarm-related commands, docker run --privileged, and mapping volumes with a source outside $BITBUCKET_CLONE_DIR for security reasons on our shared build infrastructure.

    If I had to guess based on your description, I suspect that the Maven plugin is trying to start Postgres and map a volume outside the build directory for storing databases, probably under the typical /var/lib/psql location. You'll need to reconfigure it to use a location underneath $BITBUCKET_CLONE_DIR. (If it isn't this problem, then it could be starting the container with --privileged or using a swarm command.)

    Can you please take a look into this, and let us know what you find?

  2. Moritz Becker reporter

    Hi, thank you for your response.

    The mvn plugin is not explicitely mapping any volumes to host directories. It only performs the implicit mappings from VOLUME declarations in the Dockerfile which are mapped to /var/lib/docker/volumes/ on the host side.

    I have attached the outputs of docker inspect on my local machine for a container created by the plugin and for a container created by running docker run -d -p 5435:5432 postgres:10-alpine. The latter command embodies the same semantics as my plugin configuration does. When you compare the two outputs you can see that the resulting container has the same configuration (modulo different IDs and stuff).

    Moreover, if your theory was right then my docker run -d postgres:10 command issued inside the pipeline would also have to fail due to the implicit volume mapping.

    I found out that the plugin accesses the docker daemon via the Docker Engine API - not sure if this is relevant.

  3. Kenny MacLeod staff
    • changed status to open

    Re-opening this ticket. We have a known problem with the integration of the fabric8 docker maven plugin and the docker daemon in pipelines. This is most likely due to differences in expectations between docker API versions.

    The only current workaround is to avoid using the fabric8 maven plugin, and either use a different docker plugin or invoke docker commands directly using the maven exec plugin.

  4. Anton Smirnov

    @Moritz Becker

    I'm having similar issue with another library (testcontainers). So in fabric plugin you had this issue in 0.23 and it's gone in 0.25.2, right? Can you figure out related issues/commits?

    Are they:

  5. Nathan Burrell staff

    @Anton Smirnov sorry the issue with testcontainers isnt the exact same one as this (I was just guessing it was at first as we have seen it happen with alot of docker clients) the issue with testcontainers is in how it is configuring mysql by default, you just need to update the default config for where the mysql-conf file is mounted from (hostPath) as described in

  6. Log in to comment