[0.8] Secret usage with custom plugins

We recently forked the Docker plugin to add some extra labels that are useful for us when tracking code changes across our Ci/CD pipeline. When changing one of our builds to use the new image, authentication is failing when it was previously working with plugins/docker. I’ve added our new image to the Secret as allowed but we’re still seeing the authentication failure.

Is there anything else I need to do to allow Secrets to be passed into custom plugin images?

I’ve configured our publish step like this:

  image: our-custom-image
  secrets: [docker_username, docker_password]
  registry: quay.io
  repo: quay.io/our-project
  - latest

I’ve verified that the username/password that I’m using is valid and we have other projects using plugin/docker with the same credentials.

maybe try adding debug: true to gather the full error message and error details [1]? I would need detailed error logs to advise further.


I actually had a problem like this, and giving my secrets a custom name fixed it

        - source: google_token
          target: token

so just replace it with what you target it to.

1 Like


+ /usr/local/bin/dockerd -g /var/lib/docker
time="2017-10-30T15:36:52Z" level=warning msg="the \"-g / --graph\" flag is deprecated. Please use \"--data-root\" instead"
time="2017-10-30T15:36:52.789894493Z" level=warning msg="could not change group /var/run/docker.sock to docker: group docker not found" 
time="2017-10-30T15:36:52.792888816Z" level=info msg="libcontainerd: new containerd process, pid: 18" 
Error starting daemon: error initializing graphdriver: operation not permitted
time="2017-10-30T15:37:08Z" level=fatal msg="Error authenticating: exit status 1" 

Are those the full logs for that step?

Is there anything else I need to do to allow Secrets to be passed into custom plugin images?

If your credentials were not passed to the plugin, you would see the following message at the top of your logs.

+ /usr/local/bin/dockerd -g /var/lib/docker
Registry credentials not provided. Guest mode enabled.

Also what is your full yaml file? Are you running your custom docker plugin in privileged mode so that the docker daemon can start? Or did you add your custom plugin to the server whitelist (below) so that it automatically starts in privileged mode?


@bradrydzewski unfortunately, yes.

I was was unaware of the plugin whitelist so I’ll give that a shot. Is that a server or agent environment variable?

@bradrydzewski that did the trick! Thanks a ton!

Thank you so much. I tried everything possible for hours and didn’t think to try this. You’re a savior.

I tried this w/my custom image (DRONE_ESCALATE=registry.mycompany.com:5000/myorg/myimage,plugins/drone,plugins/ecr) and I am still seeing an error that indicate myorg/myimage runs in non-privileged mode: containerd: write /proc/29/oom_score_adj: permission denied

To calrify, myrepo/myimage is plugins/docker with my self signed CA.

I would verify that you are correctly passing DRONE_ESCALATE to the drone server. You can verify the value is being properly set with docker inspect.

I then recommend checking to see if the image defined in your yaml, and the image passed to DRONE_ESCALATE, work with our matching logic: https://github.com/cncd/pipeline/blob/master/pipeline/frontend/yaml/compiler/image_test.go#L113

To calrify, myrepo/myimage is plugins/docker with my self signed CA.

You can alternatively define a global volume that mounts your self-signed CA into the build containers. This might be a better option, as it would allow you to use the default images.

You might also be able to set insecure: true in the yaml to disable tls verification. This is not ideal, but may be an option if you are running behind the firewall.

great suggestion, thank you.