Uploaded image for project: 'Bitbucket Cloud'
  1. Bitbucket Cloud
  2. BCLOUD-18394

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

    XMLWordPrintable

Details

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

    Description

      This issue has arisen as a result of the following original request:
      BCLOUD-13676

      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 ===

      #!python
      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.

      Attachments

        Activity

          People

            Unassigned Unassigned
            bcb0c1cd1fcb Ashvin Narayanan
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: