Closing major security vulnerability, re branches?

[luke_grassroot]

Hello,

Has anyone found a solution to the vulnerability that if, on a large team, you have protected your GitHub master branch a malicious dev can push a change to config.yml that forces deployment of their branch?

Secure circle.yml file

Hi, Is there any we can secure the circle.yml file ? As of now, we would like to use circleci to auto deploy our build to the production servers. However, it seems that any developper can modify the circle.yml file (via a branch), build a malicious version and release that version to production. Thanks

It was posted a while back but Circle CI seems to have just closed it without responding. This was pointed out to us recently and frankly I’m not sure we can keep using Circle CI if there isn’t a fix - pretty easy to come up with scenarios where this allows a single dev just with dev branch permissions to push code to production that gives them full control. I’ve been searching for a way to, say, protect the filter section of the job definition to say it can only be changed on master, but not finding anything.

Anybody else had any luck?

Best
Luke

[nvanheuverzwijn]

@luke_grassroot

It was posted a while back but Circle CI seems to have just closed it without responding. This was pointed out to us recently and frankly I’m not sure we can keep using Circle CI if there isn’t a fix - pretty easy to come up with scenarios where this allows a single dev just with dev branch permissions to push code to production that gives them full control. I’ve been searching for a way to, say, protect the filter section of the job definition to say it can only be changed on master, but not finding anything.

There is not solution to this from what I can tell. Right now, I just trust the users but that is dangerous if you work with third party developpers on your github repository.

[halfer]

@luke_grassroot

[CircleCI] seems to have just closed it without responding

I don’t believe this is the case. This forum is powered by Discourse, which has an auto-lock setting. Threads are closed after a fixed period (three months) to prevent necroposting. It’s fine to create a new thread and link to the old one.

[halfer]

@nvanheuverzwijn

that is dangerous if you work with third party developpers on your github repository.

True. I’ve not had to deal with this, but I wonder if the best solution is for third parties to replicate the build process in another CircleCI account, minus the deployment keys/capability.

I wonder, for companies that are particularly security-minded, they would insist on this anyway even if CircleCI did have provision for restricting changes to the config file - a clear separation of accounts would give confidence that a deployment key could not be used by a third party.

[luke_grassroot]

Ah, true re the closing period. I shouldn’t have assumed that’s the case without checking. Thanks for correcting.

Yes I’m thinking about some separation of accounts. Although then we’d possibly need to configure Circle CI to build different branches on different accounts, which I’m not sure is possible.

What we will probably need to do is switch to a tighter process of only allowing forks & PRs for every dev instead of branches and PRs within the repo (with the ‘don’t share env variables on fork builds’ on). Not entirely ideal and would really have liked the simple option of “don’t allow config changes off master”, but seems best way at present.

[halfer]

@luke_grassroot

Although then we’d possibly need to configure Circle CI to build different branches on different accounts

I expect you can set a branch protection on master for the third-party GitHub account, so they can do everything but merge to master. Then, set up Context env vars for your team, containing your deploy keys - a third party account would not have these and so any deploy operation would fail.

Or you could get the third party to work on a fork rather than non-master branches.