I’ve got an issue running Drone as a single machine instance, trying to store secrets in Vault and access them during builds with the Vault plugin. They can be retrieved successfully on the CLI, but not during builds.
Some of those variable settings are redundant but at this point I’m not sure
what is and isn’t necessary Have also tried switching a lot between
referring to the Vault address as its domain name and its internal address, but
no luck either way.
Storing a key ‘mykey’ at kv/test.
A successful Drone CLI request:
VAULT_ADDR=hxxps://drone-vault.mydomain.com DRONE_SECRET_ENDPOINT=hxxp://127.0.0.1:10281 DRONE_SECRET_SECRET=4d4xxx ./drone plugins secret get --repo=me/testrepo kv/test mykey
I seem to be having similar issues. My config looks similar, but I have a drone server and a separate agent configured to point at the vault plugin.
If I run the drone plugin secret get command like you do, I can get the secret.
When running a build with a very similar config to yours, I get no secrets.
I started the agent with DRONE_LOGS_TRACE=true, and I get this output when the build runs:
{"kind":"secret","level":"trace","msg":"secret: encrypted: no matching secret","name":"test123","time":"2019-06-22T22:35:48Z"}
{"kind":"secret","level":"trace","msg":"secret: external: cannot get secret","name":"test123","time":"2019-06-22T22:35:48Z"}
The plugin container offers no useful logs.
Also not sure how to proceed debugging further, but strangely hopeful since I found somebody else with the same symptoms.
That is very helpful, thank you. In my case it is a certificate issue talking to the vault plugin container through an ingress using internally signed certs.
That makes sense. I think we have slightly different mental models of vault secrets. I would consider the path secret/docker a single secret with multiple key/value pairs inside it. Each key in the secret can be mapped to a single drone secret. Thanks for clarifying.
path and name were chosen as generic attribute names to support multiple providers (vault, aws secret manager, kubernetes, etc). I recognize that key would be more appropriate than name for vault, which is why we do plan to accept key [1] as an alias to name in a future release. Some of the code is already in place.