Secret Change, Back to Interpolation

This is a brief write-up to let everyone using drone:0.5 that we are planning some breaking changes

In 0.4 secrets were passed to the build through the yaml, similar to docker-compose:

    image: plugins/docker
    password: ${DOCKER_PASSWORD}

In 0.5 secrets were passed directly to the container as environment variables:

docker run -e DOCKER_USERNAME=... -DOCKER_PASSWORD=... plugins/docker

The goal with this change was to provide additional control of where secrets were exposed. For example, we could instruct drone to only expose Docker secrets to the Docker plugin.

These changes were very well intentioned, however, it turned out to be very user unfriendly. It became clear that since drone was a superset of docker-compose, users expected the ${variable} syntax to work for secrets. There were also many, many, many support cases were individuals couldn’t figure out the correct matching logic for white-listing which secrets would be exposed to which containers.

It became apparent that we needed to reconsider this change before cutting an 0.5 release. It was discussed over the past weeks, and finally today I decided to re-enable interpolation of secrets. This change is effective immediately in the latest image and CLI tools.

The documentation has been updated to reflect this change.

Please note that right now we are supporting both ${variable} syntax and passing secrets as environment variables. This means your existing repositories and configurations will work just fine for the time being. Passing secrets is, however, considered deprecated and will be removed in the coming weeks. Please consider changing your configurations to use ${variable} syntax sooner rather than later.

1 Like

I played around with this a little bit and noticed the following.


    image: alpine:3.4
      - echo "Hello World"
      - "echo \"Not Concealed: ${NOT_CONCEALED}\""
      - "echo \"Concealed: ${IS_CONCEALED}\""
      - "echo \"Interpolation of Secret: ${INTER_VAR}\""
      - "echo \"Interpolation of Secret: $INTER_VAR\""
      - env | grep INTER

My logs are

{"proc":"build","pos":0,"out":"+ echo \"Hello World\""},
{"proc":"build","pos":1,"out":"Hello World"},
{"proc":"build","pos":2,"out":"+ echo \"Not Concealed: MYSUPERSECRETsecret\""},
{"proc":"build","pos":3,"out":"Not Concealed: MYSUPERSECRETsecret"},
{"proc":"build","pos":4,"out":"+ echo \"Concealed: *****\""},
{"proc":"build","pos":5,"out":"Concealed: *****"},
{"proc":"build","pos":6,"out":"+ echo \"Interpolation of Secret: \""},
{"proc":"build","pos":7,"out":"Interpolation of Secret: "},
{"proc":"build","pos":8,"out":"+ echo \"Interpolation of Secret: $INTER_VAR\""},
{"proc":"build","pos":9,"out":"Interpolation of Secret: MYSUPERSECRETsecret"},
{"proc":"build","pos":10,"out":"+ env | grep INTER"},

So it seems drone is only expanding ${INTER_VAR} from drone secrets even though it’s valid to use that syntax to expand shell variables as well. Not sure what the expectation should be here but seems to be a conflict.

the goal is to behave similar to docker compose, which requires you to “escape” when you don’t want docker-compose to perform the substitution. This escaping is done by using $$ notation

You can use a $$ (double-dollar sign) when your configuration needs a literal dollar sign. This also prevents Compose from interpolating a value, so a $$ allows you to refer to environment variables that you don’t want processed by Compose.

This is something we’ll need to support going forward, for sure.