Restrict Contexts for Bitbucket Organizations on CircleCI

Goal: Use “Restricted” Contexts for BitBucket organizations, preventing access to secrets unless approved.

Bibucket users familiar with restricted contexts are disappointed to be left without similar controls as GitHub and GitLab organizations.

Fortunately the use of Configuration Policy Management allows us to achieve similar outcome, regardless of VCS!

• Bitbucket Org is connected to CircleCI
• Contexts defined
• Should use a clear naming convention for environment or project to restrict.
• On a plan supporting CPM functionality
• ‘Branch Permissions’ & ‘Merge Checks’ in Bitbucket side checks for actor / branch based restrictions (project restrictions need no special BB config)

The idea behind this solution is that we can use information available to CPM to decide if the attempted access to a Context is valid.

• Git Branch
• Context Name
• Project ID
• Workflow jobs & filters

1. Only allow context project-a-secrets to be accessed by Project A builds.
2. Only allow context production-secrets to be accessed by main (default/production/any) branch
3. Only allow changes approved by Reagan the Release Manager to access production secrets

If you want to restrict by environment, actor, or branch we will need to shift some of that enforcement to the VCS – prevent unaproved changes from merging to a stream that designates “access ready”. In simple terms this means that an open PR or non-default branch can attempt just about anything, but will never get meaningful secrets until reviewed and approved by others.

See bitbucket merge checks for setup instructions. Using specific actors will need to be defined as ‘default reviewer’ and that requirement checked in BB settings.

The three(3) main patterns we see are to distinquish by application/project, to distinquish by environment/approval stage, or to combine both (app & environment specific contexts). Depending on the desired approach, a context is needed for each unit of isolation.

Using prod or similar in contect naming is required for environment level control.

This approach is going to leverage the same concept outlined in Restricing Contexts with CPM. The policies will compare `

To restrict access by project will compare the project ID as demonstrated in Restricing Contexts to Projects with CPM