Restrict Pipelines configuration and other files to be read from specific branches

Issue #18394 open
Ashvin Narayanan created an issue

This issue has arisen as a result of the following original request: https://bitbucket.org/site/master/issues/13676/ability-to-restrict-who-can-run-deployment

As per the original suggestion in the above request, ops configuration should only ever be read from a single branch. This would work well with branch restrictions already available within Bitbucket Pipelines.

Since the original suggestion did not get implemented, the same issues relating to security still exist. One such example can be seen by the following use-case.

=== Use-case ===

pull-requests:
    '**':
      - step:
          script:
            - sh run-tests-and-auto-merge-if-coverage-sufficient.sh
            # Since the above needs to be performed on every branch, it follows that any API keys used is accessible on every branch.
          services:
            - docker

There's nothing to stop a user from modifying the sufficiency test within run-tests-and-auto-merge-if-coverage-sufficient.sh and push the changes to the branch that they are working on. As it currently stands, Bitbucket Pipelines will recognise and make use of the updated run-tests-and-auto-merge-if-coverage-sufficient.sh.

=== End of Use-case ===

Unlike the original suggestion, it's not sufficient to only read contents of the bitbucket-pipelines.yml file from a single branch. In most setups, this yml file will reference other files (in the use-case above, run-tests-and-auto-merge-if-coverage-sufficient.sh is one such file).

Therefore, it's important to first define what an ops configuration is. To me, it's any file that is utilised within your pipelines, including of course (but not limited to) bitbucket-pipelines.yml.

While having a separate repo for your ops configuration is one solution, a more simpler one would be to simply have BitBucket Pipelines recognise a directory at the root of your code repo. Let's call this directory .pipelines (say).

bitbucket-pipelines.yml could stay at its current (expected) location to maintain backwards compatibility. All your other scripts can then go under .pipelines and the single branch that is responsible for providing the true copy can then be set.

Comments (2)

  1. aneita staff
    • changed status to open

    Thanks for the suggestion Ashwin.

    I’ll open this ticket to gauge the interest of other users in seeing the same thing.

  2. Log in to comment