Drone pipeline cannot access the drone docker container volume

Drone Support
1

I am using Rancher secrets, which injects secrets as files into a volume at “/run/secrets” in a Docker container. I have a Spring Boot application which then picks up these secrets from that volume and loads these secure values into my Spring environment context at runtime.

The problem I am having is that when I use Drone I cannot run my integration tests as the application cannot access this volume so cannot load the secrets that are needed for their integrations and therefore all fail. This is due to the fact that this volume is not mounted and available for the pipeline, however there is a limitation where I can only mount a volume from the host and not the drone container volume.

I have been advised that I should rather be using Drone Enterprise to load these secrets so that they are available for my pipeline. However I feel the issue with this is that I would then not be testing the application as it would be used once deployed.

I totally understand using drone secrets/enterpise for storing sensitive info for the CI process, ie Rancher credentials for deploying etc, however my issue is more about supplying the configuration to the application so it can function as it would normally in a production instance.

Does anyone have any other suggestions on how I could go about suppling these sensitive application property files to my application in the drone pipeline.

2

I had edited my github comment, but wanted to make sure you saw it here too. Have you considered storing your secrets in the drone secret store, and then writing to /run/secrets before executing your unit tests?

I just tried the below configuration:

pipeline:
  build:
    secrets: [ SOME_SECRET ]
    image: golang
    commands:
      - echo -n $SOME_SECRET > /run/secrets
      - cat /run/secrets
      - go test

And got the following output:

+ echo -n $SOME_SECRET > /run/secrets
+ cat /run/secrets
pa$$word
+ go test
? _/drone/src/github.com/foo/bar	[no test files]

This would seem to achieve your goal of providing secrets to /run/secrets. It does not use the built-in Rancher secrets, but based on your described use case, it seems like it doesn’t matter how the secrets are written to /run/secrets as long as your unit tests can read them.

3

Ah thanks @bradrydzewski, once again you are a king, that sounds like a good plan, will give it go and update after confirming it works!

4

Worked like a charm @bradrydzewski, thank you! Just in case anyone finds themselves in this scenario I just had a tiny tweak to Brads solution to account for rancher secrets naming the files the same name as the key, so the example would be:

pipeline:
  build:
    secrets: [ SOME_SECRET ]
    image: golang
    commands:
      - echo -n $SOME_SECRET > /run/secrets/some_secret
      - go test

So in the above, the rancher key name would be “some secret”