Failing to run dind in a Kubernetes pipeline

I’m currently testing out “drone-runner-kube” (v1.0.0-beta.3) and have certain images that I would like to always run privileged, regardless of whether a repository is marked as trusted. I’ve set the following environment variable in the deployment:

          value: "docker:dind"

A snippet of my pipeline is (following the Drone doc examples):

- name: build
  image: docker:dind
  - docker build -t build .
  - name: dockersock
    path: /var/run

- name: docker
  image: docker:dind
  - name: dockersock
    path: /var/run

- name: dockersock
  temp: {}

When the service starts, the following logs are output:

mount: permission denied (are you root?)
Could not mount /sys/kernel/security.
AppArmor detection and --privileged mode might break.
mount: permission denied (are you root?)

Now if I include “privileged: true” and mark the repository as trusted, this works fine. So I suspect there is an issue or bug with the DRONE_RUNNER_PRIVILEGED_IMAGES values being parsed. Is anyone able to confirm whether this is a bug, or spot any glaring issues with what I’ve mentioned above?

The DRONE_RUNNER_PRIVILEGED_IMAGES parameter is only used for privileged plugin images (plugins/docker, etc) for security reasons. A plugin is defined as a pipeline step that does not have any user-defined commands, command or entrypoint. You can see the logic here:

We should probably rename this variable to DRONE_RUNNER_PRIVILEGED_PLUGINS to more accurately describe its behavior.

I see, thanks for the clarification. I came across the above code but missed that it only applied to the official plugin images.

Would there be scope to extend this and allow users for self-hosted installs specify their own privileged images (still retaining the check for no custom commands or entrypoint), or alternatively allow this functionality via a different env var?

In my use case I have a multi tenanted environment and don’t intend to be marking any user repositories as trusted.

There are a number of self-hosted installations that are public facing (e.g. open source repositories) and we use the same code at so we need to be cautious. I agree that adding a new variable is the best approach. Here is my recommendation:

  1. rename the existing variable to DRONE_PRIVILEGED_PLUGINS and retain the same logic we have in place today. This removes any confusion.
  2. map the old variable name to the new variable name for compatibility here.
  3. create a new variable named DRONE_PRIVILEGED_IMAGES that toggles the privileged flag without any restrictions
1 Like

I will take care of 1 and 2. any chance you could send a pr for 3?

Sure I’ll try pick it up this week, thanks!

Created a PR here with a bit more discovery: