Question about signing .drone.yaml


#1

So, we’ve been trying out Drone (v0.8.9) for the past few months, and are at a point where we need to figure out how to lock down .drone.yaml changes to only specific users. I know that the Drone CLI has some ability to sign pipelines, but we need to make sure that not just anyone can generate a signature.

Ideally, we want anyone in our organization to be able to view Drone build results, but only a select few to be able to generate signatures. Is this possible?

Also, FWIW, the combination of a “protected” Drone repo and a signed pipeline wasn’t working for me in 1.0.0-rc.1—the build would remain “pending” until I manually approved it through the CLI. Is this still the case? Has this been fixed? We’re still waiting on the 1.0 source code before we can actually deploy it, but yeah.


#2

ideally, we want anyone in our organization to be able to view Drone build results, but only a select few to be able to generate signatures. Is this possible?

Only users with push access to the repository can overwrite the signature file, approve or decline blocked builds. You can use github protected branches to further lock down your repository.

Alternatively, instead of signing the yaml file, you can create a config plugin and implement your own logic to verify the contents of the yaml.

the combination of a “protected” Drone repo and a signed pipeline wasn’t working for me in 1.0.0-rc.1—the build would remain “pending” until I manually approved it through the CLI. Is this still the case? Has this been fixed

I am not aware of any issues with protected mode. I just tested protected mode with a valid yaml signature file and the build was enqueued and executed, and was not blocked by the system.

The most common root cause for invalid signature is when you try to manually add the yaml signature to your file and, in the process, invalidate the signature. For this reason I recommend using the --save feature when signing your yaml.

drone sign drone/hello-world --save

It is also possible you could run into issues related to CRLF if you are running on a windows machine. I have not tested this, but you can set your git CRLF preference to ensure posix line feed compliance.


#3

Yeah, when I ran into the above issue I was using drone sign with the --save flag, but I’ll give it another shot when we can move to a 1.x release.

So if my GitHub account were to be compromised, wouldn’t it then be possible for an attacker to alter this pipeline to cause Drone to build and push a release to our artifact store, even if the pipeline was previously defined such that it would only build and push a release if a tag was made on a protected release branch? I’m hoping for an extra layer of security: just because I trust people to push code to an unprotected branch doesn’t mean I trust them not to tamper with the release process.

I understand we have a lot more control with config plugins in 1.x, but I can’t work with that yet—need to be able to audit the source and build it ourselves.


#4

Protected mode is not really meant to solve this problem. We created protected mode specifically to solve the problem that public, Open Source projects need to expose secrets to pull requests (for example, to send a Slack notification when the pipeline completes) but want to ensure a malicious user cannot issue a pull request that exposes the secret. Signing the yaml helps mitigate this attack vector.

I think enabling 2FA should help prevent someone from hijacking your GitHub account, or perhaps consider GitHub Enterprise to enforce additional layers of security including limiting access behind a firewall.

I understand we have a lot more control with config plugins in 1.x, but I can’t work with that yet—need to be able to audit the source and build it ourselves.

This will probably be your best option based on the kind of vectors you are looking to protect against. Here are some links that provide additional information:


#5

Specifically I think you could have a configuration plugin that 1) fetches the yaml 2) checks to see if the yaml changed and who changed it and 3) errors if changed by an unauthorized user

Or you could create a plugin that fetches the yaml from a separate repository, which strictly limits who can modify the file. You could almost use the plugin starter project out of the box for this.


#6

This is awesome! I have an idea for a config plugin that checks a .drone.yaml's hash against a Notary server…

Not to sound like a broken record, but is this something I can use today in any open-source versions of Drone? I very much appreciate all your hard work! Drone is an excellent piece of software, and I’d really rather not use anything else… just need to be able to build it from source to comply with our company’s security policies.


#7

these features are only part of Drone 1.0 and the source code has not been released yet. The source will be released in conjunction with 1.0-final, although I do not have an exact date I can provide at this time. In the meantime, all the code for plugins is open source [1][2][3] which could allow you to get a head start on development, pending full source code release.

[1] https://github.com/drone/drone-go/tree/master/plugin/config
[2] https://github.com/drone/drone-config-plugin-starter
[3] https://github.com/drone/drone-cli/tree/master/drone/plugins/config (command for locally testing a config plugin)