Drone 0.8: Using secrets in steps not supporting reading from env vars

Drone Support
1

Hi,

We are migrating from Drone 0.4 to 0.8.

In 0.4 we were able to use something like this:

deploy:
  some-deploy-step:
    image: custom-deploy-plugin
    password: $$PASSWORD_STORED_AS_DRONE_SECRET

Just as an example here, let’s say that custom-deploy-plugin expects a password attribute which we are populating using Drone secret (stored in .drone.sec in Drone 0.4).

I understand that in Drone 0.8 secrets are inserted into plugins differently. They are exposed to the plugin as an environment variables which are then read by plugins.

But what if the plugin doesn’t understand environment variables? Let’s say that our custom-deploy-plugin still expects password attribute?

I was trying things like this, but no luck:

some-deploy-step:
  image: custom-deploy-plugin
  password: ${PASSWORD_STORED_AS_DRONE_SECRET}
  secrets: [PASSWORD_STORED_AS_DRONE_SECRET]

Is there a way how to make this work on Drone 0.8?

2

One small addition. I am aware that in Drone 0.8 plugins attributes are converted to env vars in format PLUGIN_<ATTRIBUTE NAME>. So maybe this would work:

some-deploy-step:
  image: custom-deploy-plugin
  secrets:
    - target: PLUGIN_PASSWORD
    - source: PASSWORD_STORED_AS_DRONE_SECRET

However, we still have situations where our plugin attributes can be arbitrary Dict like this:

some-deploy-step:
  image: custom-deploy-plugin
  custom_params:
    param1: something
    param2: something
    param3: $$PASSWORD_STORED_AS_DRONE_SECRET

Any way of exposing the secret as the param3 as in the example above? :slight_smile:

Thanks

3

There is no way to interpolate passwords (this was removed and is not coming back). You need to think about secrets a little differently when you build plugins for 0.6+. Secrets are passed to the plugins as named environment variables. So you need to code your plugin to look for the named environment variable.

If you want to provide password as a secret, you would not set both the secret and the password field. You should only be setting the secret:

some-deploy-step:
  image: custom-deploy-plugin
- password: ${PASSWORD}
  secrets: [PASSWORD]

and then you would update your plugin to look for the PASSWORD environment variable and the yaml attribute which will also be passed as an environment variable, but prefixed with PLUGIN_. For example your plugin might do something like this:

var password = process.env.PASSWORD || process.env.PLUGIN_PASSWORD
4

I describe a pattern for handling this use case here:
http://discuss.harness.io/t/how-can-i-pass-secrets-as-build-args-to-plugins-docker-drone-0-8/824/2

Note that we use this pattern with the docker plugin, where we need to provide the plugin with an arbitrary dictionary of parameters for build-args, which in some cases may need to be sourced from secrets or the environment.

So you might instead do something like this:

some-deploy-step:
  image: custom-deploy-plugin
  custom_params:
    param1: something
    param2: something
-   param3: $$PASSWORD_STORED_AS_DRONE_SECRET
+ custom_params_from_env: [ PASSWORD_STORED_AS_DRONE_SECRET ]

or this

some-deploy-step:
  image: custom-deploy-plugin
  custom_params:
    param1: something
    param2: something
-   param3: $$PASSWORD_STORED_AS_DRONE_SECRET
+ custom_params_from_env: 
      param3: PASSWORD_STORED_AS_DRONE_SECRET
5

Thanks for the quick and comprehensive answer @bradrydzewski.

I was afraid this was the case. However the explanation makes perfect sense. I guess we will need to make changes to our plugins to support the pattern you describe (the “custom_params_from_env” thing).

Thanks :+1: