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

**URL:** <https://drone.discourse.group/t/drone-0-8-using-secrets-in-steps-not-supporting-reading-from-env-vars/8895>\
**Category:** Drone Support\
**Created:** [April 16, 2018, 5:30pm UTC](https://drone.discourse.group/t/drone-0-8-using-secrets-in-steps-not-supporting-reading-from-env-vars/8895 "2018-04-16T17:30:47Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![jakubka](https://avatars.discourse-cdn.com/v4/letter/j/48db29/32.png) [@jakubka](https://drone.discourse.group/u/jakubka)\
**Post date:** [April 16, 2018, 5:30pm UTC](https://drone.discourse.group/t/drone-0-8-using-secrets-in-steps-not-supporting-reading-from-env-vars/8895/1 "2018-04-16T17:30:47Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![jakubka](https://avatars.discourse-cdn.com/v4/letter/j/48db29/32.png) [@jakubka](https://drone.discourse.group/u/jakubka)\
**Post date:** [April 16, 2018, 5:34pm UTC](https://drone.discourse.group/t/drone-0-8-using-secrets-in-steps-not-supporting-reading-from-env-vars/8895/2 "2018-04-16T17:34:46Z")

</div>

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? 🙂

Thanks

---

<div class="post-metadata">

**Author:** ![bradrydzewski](https://yyz1.discourse-cdn.com/flex003/user_avatar/drone.discourse.group/bradrydzewski/32/3513_2.png) [@bradrydzewski](https://drone.discourse.group/u/bradrydzewski)\
**Post date:** [April 16, 2018, 5:40pm UTC](https://drone.discourse.group/t/drone-0-8-using-secrets-in-steps-not-supporting-reading-from-env-vars/8895/3 "2018-04-16T17:40:49Z")

</div>

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:

```diff
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:

```auto
var password = process.env.PASSWORD || process.env.PLUGIN_PASSWORD

```

---

<div class="post-metadata">

**Author:** ![bradrydzewski](https://yyz1.discourse-cdn.com/flex003/user_avatar/drone.discourse.group/bradrydzewski/32/3513_2.png) [@bradrydzewski](https://drone.discourse.group/u/bradrydzewski)\
**Post date:** [April 16, 2018, 5:47pm UTC](https://drone.discourse.group/t/drone-0-8-using-secrets-in-steps-not-supporting-reading-from-env-vars/8895/4 "2018-04-16T17:47:36Z")

</div>

> [@On another topic](https://drone.discourse.group/t/2102/2):
>
> However, we still have situations where our plugin attributes can be arbitrary Dict like this:

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](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:

```diff
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

```diff
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

```

---

<div class="post-metadata">

**Author:** ![jakubka](https://avatars.discourse-cdn.com/v4/letter/j/48db29/32.png) [@jakubka](https://drone.discourse.group/u/jakubka)\
**Post date:** [April 16, 2018, 7:19pm UTC](https://drone.discourse.group/t/drone-0-8-using-secrets-in-steps-not-supporting-reading-from-env-vars/8895/5 "2018-04-16T19:19:22Z")

</div>

Thanks for the quick and comprehensive answer @bradrydzewski.

> [@On another topic](https://drone.discourse.group/t/2102/3):
>
> There is no way to interpolate passwords

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 👍