Ability to restrict access to pipeline artifacts?

[ninjadroo]

I'm curious if there is a way to restrict access to who can view/download pipeline artifacts.  We are using deployment variables and parallel steps within a pipeline.  We have found that it is not possible to utilize the deployment variables across all parallel steps and must instead write the variables to a file which is used by subsequent steps.

This unfortunately now exposes the protected keys/tokens to all users running the pipeline as they can download the artifact with the data inside.

Is there an access privilege I'm missing that can prevent this or a different method of using deployment variables with a pipeline that uses parallel steps?

[Theodora Boudale]

Hi @ninjadroo and welcome to the community.

I'm afraid that there is no way to restrict access to artifacts at the moment.

We have a feature request for restricting the manual download of artifacts: https://jira.atlassian.com/browse/BCLOUD-17277

Please keep in mind though that artifacts are files available during a pipelines build. Even if this feature request is implemented, it would still be possible for someone with write access to the repo to edit the bitbucket-pipelines.yml file and add in the script a cat command that shows the contents of an artifact file in the Pipelines build log.

We recently released a feature called stages that allows for multi-step deployments:

• https://support.atlassian.com/bitbucket-cloud/docs/stages/

With this feature, you can use a deployment environment in a stage that consists of multiple steps. Then, the deployment variables of this environment will be available to all steps of the stage.

This may be a good alternative to using artifacts. Please keep in mind though that the feature is still in beta and it doesn't support parallel steps yet. You can view the full list of limitations at the end of the documentation page I shared, and I could create a feature request for supporting parallel steps in a stage if you'd be interested in that.

Kind regards,
Theodora

[ninjadroo]

Thank you very much for the information!  It is unfortunate that the functionality isn't there as we attempt to lock down and secure our repository and pipelines.  However, stages supporting parallel steps sounds like the more promising fix for us.  

Are parallel steps on the roadmap? Or is the functionality just not technically feasible?

[Theodora Boudale]

Hi @ninjadroo,

You are very welcome and I understand your concerns. The suggestion I can make regarding security would be to use deployment variables instead of artifacts with the stages feature, if you're willing to work without parallelization for now and if the stages' limitations are not a problem for you.

With the Premium plan, you can make use of deployment permissions. For each environment in the deployment environment settings, there is an option "Only allow admins to deploy to this environment". Enabling this setting ensures that no one other than admins can run deployments and any deployment variables cannot be accessed by someone who is not an admin. Please keep in mind that a deployment by a non-admin will then be automatically paused and can only be resumed manually by an administrator.

If you would like to try this out and if you need any assistance adjusting your bitbucket-pipelines.yml file, you can post the structure of your yml file here so I can take a look and give you suggestions. Alternatively, you can also create a ticket (which will be visible only to you and Atlassian) with the support team to ask for assistance, this way you can get assistance without posting any details here publicly. You can create a ticket via https://support.atlassian.com/contact/#/, in "What can we help you with?" select "Technical issues and bugs" and then Bitbucket Cloud as product.

Parallel steps in a stage are not on the roadmap yet, I have created a feature request about it here: https://jira.atlassian.com/browse/BCLOUD-22214

You can add your vote and feedback to that feature request to further express your interest. You can also add yourself as a watcher if you'd like to get notified via email on updates.

If you have any other questions, please feel free to let me know!

Kind regards,
Theodora

[Bitwise DEVS]

Even if this feature request is implemented, it would still be possible for someone with write access to the repo to edit the bitbucket-pipelines.yml file and add in the script a cat command that shows the contents of an artifact file in the Pipelines build log.

@Theodora Boudale But this is more of a operational issue, if the team have code reviews any changes to `bitbucket-pipelines.yml` can be monitored.  We are also looking for this feature and planning to request it as well until we saw this post.


It seems the feature request above has been forgotten. Any chance that the Bitbucket Team still consider adding such feature? Thanks.

[Theodora Boudale]

Hi,

Thank you for your feedback. I'm afraid that this is not on the roadmap at the moment. When there is an update, it is going to be posted in the feature request.

Kind regards,
Theodora

[Bitwise DEVS]

Hi @Theodora Boudale may we know the big difference of Stage compare to Anchor? Until now we cannot find a proper solution to avoid downloading of artifact in the UI which will expose sensitive keys stored as repository variable that was converted to a file in one of our step that uses anchor.


Thanks!

[Theodora Boudale]

Hi @Bitwise DEVS,

An anchor allows you to define a step and then reference this step in multiple different pipelines. E.g. you may have a pipeline for develop branch, one for main branch, another custom pipeline, that all include the exact same step. In this case, you can use an anchor to define the step and then reference it in the multiple pipelines that use it. It is meant to minimize duplication.

A stage on the other hand is used to group steps of the same pipeline. The steps can share the same deployment (defined on the stage level) and access the same deployment variables. Without a stage, two steps of the same pipeline can't use the same deployment environment.

Artifacts download from the UI cannot be restricted. If you need to store repository variables in a file during the build, you can do it in every step that needs this file, instead of defining that file as an artifact.

Kind regards,
Theodora