So that said the only way to secure drone CI is to completely restrict access to master branch including read permissions and/or restrict branch pushing to github entirely.
Restricting developers from being able to push their branches to github is unfeasible - many work from different machines and need to store their branches remotely.
I am not suggesting preventing them from pushing to a remote. I am suggesting using the fork workflow, where a developer forks the repository, pushes to their remote fork, and then opens a pull request to get their changes merged.
Alternatively you can extend secrets and put additional logic and restrictions in place. We have a starter project for creating extensions at GitHub - drone/boilr-secret: boilr template for creating Drone secret extensions
changes to master are restricted
I did not realize it was possible to restrict pushing to specific branches, but I see this capability was added in Aug 2018. The way we designed secrets assumes any developer with push access can push to any branch, which was a true statement in 2014 when we created Drone, and was true for many years after.
However, seeing you can now restrict who can push to a branch, it makes sense to give the option to limit secrets by branch. This would need to be teed up as a new feature request.
My suggestion would be to have the option to set the build target location and the build triggers at the server side and have the ability to restrict access to the drone server for essential persons only.
Regarding restricting access to the drone server one possible idea is look at repo/organization users and who has admin/owner rights then allow login/access to the drone server if a github user has admin/owner level permissions.
Should I open a feature request to discuss security around builds and their targets?
I prefer to keep the pipeline configuration in the yaml. In this case secrets are already configured in the database, so I think it makes sense to add an option to limit a secret to a specific branch and align with github restricted branch feature.
If you want to move settings outside of the yaml for security purposes, the recommended approach is to create an extensions.
Restricting secrets to certain branches would be a good fix here.
For our own use case here we only want master branch deployed to production SSH hosts so a simple server side option would restrict the use of certain secrets to specific branches would work.
But then how do you restrict access to the server to stop someone from changing that setting on the secret? Everyone with a github user at the organization the drone server is authed against can access and modify the server via the web portal.
But then how do you restrict access to the server to stop someone from changing that setting on the secret?
I think it would be interesting to add a flag to lock and unlock the repository from editing. By default a repository would be unlocked. When locked, only admin users could edit.
I think this would solve the problem, however, I do not want to rush a design. Any features we add to core are subject to long term support, so I want to make sure anything we add is worth supporting for years to come.
Understood.
For the time being we will have to remain with Jenkins until security is given more consideration for Drone CI.
It’s a shame too as Drone CI looks like a great platform especially its ‘out of box experience’.
I will check back in with this product sometime next year.
You have options to use Drone today and lock down your environment without having to use a fork workflow as Brad suggested. Some options include:
In the past there was no option to restrict pushing to branches in github, which made limiting secrets by branch ineffective security theater. It is great to learn that github supports restricted branches and we should definitely revise the way we do secrets to take advantage. None of our competitors (Travis, Circle, etc) seem to restrict secrets by branch at the moment, so this is a good opportunity to demonstrate that Drone continues to lead when it comes to security.