Using secrets w/ plugins

Drone Support
1

So for 0.5 there doesn’t appear to be a way to use secrets to variable a repo’s pipeline per environment. Let me explain w/ plugins/docker my “registry” and “repo” parameters are different for a pipeline executing two or more environment like so:

pipeline:
  publish:
    image: plugins/docker
    storage_driver: overlay
    insecure: true
    registry: ${DOCKER_REGISTRY}
    repo: ${DOCKER_REGISTRY}/foo/bar
    force_tag: true
    tags: [ latest, 2.5.1 ]

So as it is I have to hard code their values in each environment. If true this sorta sucks.

Nor does the “PLUGIN_PARAMS=” appear to work

Or am I missing something?

2

0.5 does not support ${VARIABLE} for secerts. Secrets are passed to the plugin container as environment variables, similar to docker run -e VARIABLE=...

The issue here is you are trying to use 0.4 syntax with 0.5, which is not supported

3

Yes, I read that, but how does one access these values in utilizing a plugin in one’s pipeline? The docs don’t convey probably something very obvious.

So does this

pipeline:
  publish:
    image: plugins/docker
    storage_driver: overlay
    insecure: true
    registry: ${DOCKER_REGISTRY}
    repo: ${DOCKER_REGISTRY}/foo/bar
    force_tag: true
    tags: [ latest, 2.5.1 ]

Become the creation of two secrets: registry and repo via

drone secret add --image=plugins/docker foo/bar registry "example.com:5000"
drone secret add --image=plugins/docker foo/bar repo "example.com:5000/foo/bar"

And the .drone.yml:

pipeline:
  publish:
    image: plugins/docker
    storage_driver: overlay
    insecure: true
    force_tag: true
    tags: [ latest, 2.5.1 ]

???

Because that didn’t work for me.

How does one use secrets as container environment variables in the plugin container beyond the ones ticked off by the plugin container and utilized specifically in the code of the plugin. For me the documentation is not clear.

1 Like
4

I have the same issue, but with ECR plugin, I’m not sure if docs aren’t updated but if you see:
http://plugins.drone.io/drone-plugins/drone-ecr/ it only defines variables like:

  • access_key
  • secret_key
    …

It doesn’t say anything about secrets, however at https://github.com/drone-plugins/drone-ecr/blob/master/DOCS.md it says that secrets with certain names should be created:

  • ECR_ACCESS_KEY
  • ECR_SECRET_KEY

For Docker plugin there is no a doc page like for drone-ecr, because it redirects me to plugins.drone.io

Anyway I get an unauthorized error when trying to pull/push from ECR. I will test without secrets.

If I can find the way to make it work hope I can PR some doc :slight_smile:

5

All plugin documentation has moved to a central repository. See http://plugins.drone.io/drone-plugins/drone-ecr/

Please also reference the following guide for using secrets:
http://readme.drone.io/usage/secret-guide/

6

Yeah, I could make it work, but I had to review ECR plugin wrapper script to figure out the name of the secrets I had to add.

For example, ECR plugin docs says that these parameters should be on yaml file:

  • secret_key
  • access_key
  • …

But docs doesn’t say the name of secrets if I don’t want to store secret_key or access key on yaml file, which for the case of ECR pluging they are: ECR_SECRET_KEY, ECR_ACCESS_KEY, etc. Something similar with Docker plugin, seems that secret names should be DOCKER_USERNAME, DOCKER_PASSWORD, etc.

That makes me realize that there is a convention for secrets with plugins, that secrets should be named as {PLUGIN_NAME}_{PARAMETER_NAME} maybe I’m wrong but if that convention is true I couldn’t find it in the docs :confused:. Maybe that can be added as a documentation improvement.

Thanks

7

@donkeysharp this documentation accurately describes secret usage:
http://readme.drone.io/usage/secret-guide/

But docs doesn’t say the name of secrets if I don’t want to store secret_key or access key on yaml file, which for the case of ECR pluging they are: ECR_SECRET_KEY, ECR_ACCESS_KEY, etc

This is describing an old, experimental feature that was deprecated, which is why it is no longer documented.

If you want to inject a secret key and secret token you need to use the following syntax in your yaml configuration file:

secret_key: ${ECR_SECRET_KEY}
access_key: ${ECR_ACCESS_KEY}

That makes me realize that there is a convention for secrets with plugins, that secrets should be named as {PLUGIN_NAME}_{PARAMETER_NAME}

This is also describing the old, deprecated feature.

You can name your secrets anything you want, and refer to them by name in your yaml

secret_key: ${ECR_SECRET_KEY}
-access_key: ${ECR_ACCESS_KEY}
+access_key: ${FOOBAR}
1 Like
8

Thank you @bradrydzewski, I was a bit confused about whether that was 0.4 or 0.5 related, but now it’s clear as water, thanks for the patience :slight_smile: