Bitbucket Pipeline Secrets
You set up bitbucket pipeline secrets by storing encrypted variables in your repo or workspace settings. Build steps then read these values at runtime to log in to servers and databases. Most teams start by adding static keys at the workspace level so every job can run. When those keys have broad roles, any script in a build can change live data. How bitbucket pipeline secrets work in your builds Bitbucket lets teams store variables at three levels: workspace, repo, and deployment stage. When
Bitbucket Pipelines Security + K8s Secrets Management: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up bitbucket pipeline secrets by storing encrypted variables in your repo or workspace settings. Build steps then read these values at runtime to log in to servers and databases. Most teams start by adding static keys at the workspace level so every job can run. When those keys have broad roles, any script in a build can change live data.
How bitbucket pipeline secrets work in your builds
Bitbucket lets teams store variables at three levels: workspace, repo, and deployment stage. When a developer marks a variable as secure, the platform encrypts the value at rest. Team members cannot read the plain text in the web view after saving it. During a build, the runner loads the variable into the container memory for that step.
If the variable prints to the build log, the runner masks the exact string with stars. Teams can also use OpenID Connect to trade a job token for a cloud role. This approach removes the need to store long-lived cloud keys inside the repo settings. Still, many databases and internal tools still need standard usernames, passwords, or API keys.
Workspace variables work across every repo that belongs to your team account. Repo variables stay inside one project and override workspace values with the same name. Deployment variables only load when a build step runs for a specific target stage. This hierarchy helps admins separate test keys from live production credentials.
Where static build variables leave gaps
Native secret storage solves the problem of keeping plain passwords out of source code files. It also controls which repos or stages can load a given key during a run. Yet this setup only decides how the runner logs in to a remote system. Once the build step logs in, the target database or server trusts that session.
Log masking also has limits when a script transforms or encodes a secret value. If a build script splits a key or changes its format, the log filter misses it. Any developer who can edit the build file can run arbitrary commands with those credentials. A bad script or a compromised package can read tables or drop data.
Also, native build logs only show the shell output from the runner container itself. They do not record the exact SQL queries or remote commands sent over the network. When a shared pipeline key touches a live database, audit logs only show the shared account. Security teams cannot tell which build run or commit changed a specific record.
Bitbucket Pipelines Security + K8s Secrets Management: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Scoping permissions and auditing build actions
To reduce risk, teams should give each build role the smallest set of permissions possible. A job that runs database migrations should not use a full admin account. Instead, create a dedicated database role that only alters schemas in the target table space. Keep test keys and production keys in separate deployment stages with branch checks turned on.
Branch restrictions stop feature branches from loading production variables during a test run. Only merges to the main branch should trigger steps that hold live credentials. Even with strict branch rules, teams still need visibility into what automated jobs actually do. Checking queries and commands in flight helps prevent accidental drops and leaks of sensitive fields.
For example, if a build script queries a user table, data masking can rewrite emails, phone numbers, or card numbers in the results. That way, sensitive values do not end up in build artifacts or test outputs. Pairing scoped variables with runtime command checks keeps automated runs safe and clear to audit.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
How do workspace, repo, and deployment variables differ?
Workspace variables apply to all repos in an account, while repo variables belong to one project. Deployment variables only load when a build job targets a specific stage like production. Closer scopes override broader ones if they share the exact same variable name.
Can a pull request from a fork read secure variables?
By default, builds triggered by external forks do not load secure repo or deployment variables. This rule stops untrusted contributors from editing the build script to steal your keys. Admins should keep this protection active on all public and shared projects.
Why do teams replace static keys with OpenID Connect?
Static keys stay valid until an admin rotates them by hand in both systems. OpenID Connect lets the build runner request a short token from a cloud provider for one job. Once the build step finishes, that temporary token expires right away.