How can I prevent pull request pipelines using a self modified bitbucket-pipelines.yml file?

[sm-space]

I have a bitbucket-pipelines.yml file, with pipelines defined that trigger on either commits to the main branch or when a pull-request (PR) is created or updated. The pipelines are deploying terraform infrastructure as code using GitOps practices. The branching strategy is to have a main branch, which is our source of truth, from which developers take a branch which is then merged back into main via a PR.

The idea is that the PR needs to be reviewed by our infrastructure team before being merged but any developer is free to open branches, make code changes and create pull requests for review. 

The PR pipeline runs linters, static analysis, validation and planning steps. The main branch pipeline applies (deploys) the resources.

The problem is that any developer who can open a PR can modify the PR triggered pipeline and effectively execute arbitrary code e.g. terraform apply or destroy commands. This is because the modified PR pipeline runs before it has been reviewed by a reviewer. 

Can I prevent the PR pipeline running in this way? Ideally I only want it to use the bitbucket-pipelines.yml file from the main branch, the PR target, and not bypass the review process.

Thanks.

[Theodora Boudale]

Hi @sm-space and welcome to the community!

Pull-requests pipelines run based on the definition that exists in the bitbucket-pipelines.yml file of the source branch. I'm afraid that it is not possible to use a definition that exists in the bitbucket-pipelines.yml file of a different branch or prevent the pull-requests pipeline from running when someone edits the yml file.

We have a feature request for the ability to restrict who can edit the bitbucket-pipelines.yml file which would probably address your concern:

• https://jira.atlassian.com/browse/BCLOUD-19457

You can vote for it (by selecting the Vote for this issue link) and leave feedback if you'd be interested in that feature. You can also add yourself as a watcher (by selecting the Start watching this issue link) if you'd like to get notified via email on updates.

In the meantime, if these steps require the use of credentials (that you define as variables) to connect to another server (where you don't want destroying commands to be executed), you could make use of deployment permissions (available on the Premium plan) and deployment variables:

• https://bitbucket.org/blog/deployment-permissions-now-available-in-bitbucket-pipelines

You can configure certain or all steps of the pull-requests pipelines to be deployment steps (see here) and then make use of deployment permissions to Only allow admins to deploy to this environment. This way, if a user who is not an admin commits to a branch where the pull-requests pipeline runs, the deployment steps will be paused and they can only be resumed manually by an admin.

Someone could still edit the bitbucket-pipelines.yml file to remove the deployment definition from a step. However, if deployment variables are used for credentials to connect to a server, that step won't be able to connect because the deployment variables will be unavailable without the definition.

Please feel free to reach out if you have any questions.

Kind regards,
Theodora

[sm-space]

Thank you for the reply and suggestions, I'll certainly vote to support that issue, it being 4 years old though is very concerning!

Unfortunately there are a couple of problems with that deployment approach that I don't think make it a good solution here. For deployment to AWS we're using OpenID connect to use an AWS role rather than long lived credentials, in-keeping with security best practices, therefore we don't have secret keys. To utilise the deployment variables we would also need to break the automated continuous deployment which is not something I'd want to advocate as a best practice when implementing GitOps.

Thanks.

[Theodora Boudale]

You are very welcome. I understand that my suggestion doesn't meet your requirements, but it's the only available workaround at the moment.

Thank you for providing your feedback on that ticket. We get a large number of suggestions and feature requests and implementation is done as per our policy here.

When there is an update, it is going to be posted in the feature request.

Kind regards,
Theodora