How should Bitbucket Pipelines handle secrets and cloud credentials?

In Bitbucket Pipelines, mark every sensitive value as a secured variable, scope it to the narrowest level that works, and use OpenID Connect for cloud deploys so no long-lived cloud key is stored at all. Secured variables are hidden in logs and cannot be read back, only replaced or deleted.

What kinds of variables exist?

Atlassian's documentation describes variables at several levels, and the level decides who can see and change them.

• Workspace variables are available to all repository builds in the workspace and need workspace administrator access to manage. Atlassian suggests them for shared credentials used across repositories.
• Repository variables are available to users with write access and managed by repository administrators. They suit repository-specific settings such as API endpoints.
• Deployment variables belong to an environment and override repository and workspace settings. They suit different credentials for staging and production.

The practical rule: the wider the scope, the more builds can read the value. A workspace-level production key can be read by every repository build that runs in that workspace. Put production credentials in deployment variables, so only deployment steps for that environment receive them.

What does "secured" actually give you?

A variable marked secured (the padlock) gets three protections according to Atlassian: its value is hidden in build logs, matching values are masked automatically, and URL-encoded variants are detected. A secured variable cannot be edited. You replace or delete it.

Masking is a convenience, not a guarantee. If your script writes the value to a file, an artifact or a different encoding, nothing promises it will be masked. Do not print secrets, and do not save them in artifacts.

Atlassian also notes that variables defined at runtime or secured variables are excluded from YAML templating, so you cannot inject a secured value into pipeline configuration text. That is a useful limit, not an inconvenience.

Why use OpenID Connect?

Atlassian's AWS guide shows the alternative to stored keys. You configure Bitbucket Pipelines as a web identity provider in AWS, create an IAM role, and enable OIDC on the step. Bitbucket then provides a token in a step variable, which the build exchanges for short-lived AWS credentials for the role.

Constructed example: a team stores an AWS access key as a repository variable. A contractor with write access adds a step that sends environment variables to a test server. Because the key is long-lived, the contractor now holds a working credential. With OIDC, the role trusts only the identity claims you configure, and the credentials expire. Removing the contractor's access ends their reach, and there is no key to rotate.

You still need to restrict the IAM role. A role that any pipeline in the workspace can assume is only slightly better than a stored key. Scope the trust condition to the repository and, where you can, to the deployment environment.

What to do

1. List every variable in the workspace, each repository and each deployment environment.
2. Mark anything sensitive as secured. Replace non-secured copies that hold secrets.
3. Move production credentials to deployment variables.
4. Limit who has write access to repositories that deploy, since write access is enough to use repository variables in a build.
5. Replace stored cloud keys with OIDC and a narrowly scoped role.
6. Remove workspace-level secrets that only one repository needs.
7. Never echo variables, and never store them in artifacts.
8. Rotate any value that may have appeared in a log, a ticket or a pull request.

Add a check on the repository itself: Safeguard secrets scanning and policy gates can flag committed credentials before they reach the default branch, which closes the gap that pipeline variables cannot.

Quick check

Sources

• Variables and secrets, Bitbucket Cloud, Atlassian Support, fetched 18 October 2026
• Deploy on AWS using Bitbucket Pipelines OpenID Connect, Atlassian Support, fetched 18 October 2026

Last reviewed: 18 October 2026.