Are secured variables really secure?

[남성식]

I know that tje value of these variable are hidden on the pipeline‘s output.

But I could see those values with this trick below:

- step:

    script:

      - echo $VAR >> var.txt

    artifacts:

      - var.txt

You can see the value on var.txt file.

I want to use workspace variable for saving workspace access token, to reference it on a pipeline for accessing API, but because of this vulnerability I hesitate.

[Theodora Boudale · Accepted solution]

Hi @남성식 and welcome to the community!

If you make a variable secured, its value will be masked in the build log. Pipelines masks all occurrences of a secure variable's value in your log files (the variable name will show instead), regardless of how that output was generated.

However, both workspace and repository variables can be retrieved by any user that has write access to the repo where the build is running.

You could use deployment variables instead and if your workspace is on the Premium plan, you can restrict deployments to admins only. This way, only users with admin access could use the script from your post to retrieve the deployment's variable value; users with write access only won't be able to do that.

You can check the following links for more details about deployment variables and deployment permissions:

• https://support.atlassian.com/bitbucket-cloud/docs/variables-and-secrets/#Deployment-variables
• https://bitbucket.org/blog/deployment-permissions-now-available-in-bitbucket-pipelines

Kind regards,
Theodora

[남성식]

Great answer. Thx!

Because my team has several projects and these have all different permissions.

If they have workspace token, it violates our access permission rule.

Then should I share the workspace token with all project leaders and let them save it as deploy variable for all repositories?

I hope that we have project-level variable but I know it's now there.

Would you please let me know what's the best way to handle it?

[남성식]

Moreover, the application password of a project owner, which is saved as a repo-variable, could be seen by other developers. Then the other people can acquire his access right. It is also dangerous situation, isn't it? Is this the reason why we should prefer using access tokens than using app-password?

[남성식]

One more question!

With access token, people can access API without leaving information who they are, I think. Because of access token we could make CI run without any personal information, but it's more dangerous than personal password, isn't it?

[Patrik S]

Hello @남성식 ,

Secure variables are exposed as environment variables in each pipeline step, so essentially anyone who can edit your pipelines can access the variable. Saving the variable to an artifact is only one way of accessing them, it's really hard to stop users from exporting the variables if they have to write access to the pipeline. As mentioned earlier by @Theodora Boudale , a way of restricting access to variables is by defining them in a deployment environment, so you can limit just admins to be able to change the script code and export those variables. 

Another option to increase security is when creating your workspace access tokens, use the principle of least privilege, and select only the scopes that are strictly necessary for the API endpoints you are calling. This should limit the operations of the APIs that can be executed with the access token.

As for whether to use app passwords or access tokens, this really depends on your see case. As you mentioned, app passwords are attached to a user account and have the same access as the account where they were created, but are limited to the scopes that were selected during its creation. On the other hand, workspace/project/repository access tokens don't represent a particular user and are generally used for tasks such as scripting and CI/CD tools. 

Thank you, @남성식 !

Patrik S