Bitbucket OIDC AWS Integration
You set up bitbucket oidc aws integration by linking your pipeline identity provider to an AWS role. The pipeline then trades a short token for temporary cloud credentials during each build run. Most teams start by storing static AWS keys inside repo settings. Those static keys never expire on their own and often hold broad cloud permissions. If an attacker steals a static key, they gain wide control over your cloud resources. Moving to OpenID Connect removes static keys from your build steps.
AWS IAM Policies + Bitbucket Pipelines Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up bitbucket oidc aws integration by linking your pipeline identity provider to an AWS role. The pipeline then trades a short token for temporary cloud credentials during each build run. Most teams start by storing static AWS keys inside repo settings. Those static keys never expire on their own and often hold broad cloud permissions. If an attacker steals a static key, they gain wide control over your cloud resources. Moving to OpenID Connect removes static keys from your build steps.
How bitbucket oidc aws integration works
Every pipeline run creates a signed identity token for that single job. This token holds details about your workspace, repo, and branch. Your AWS account needs an identity provider entry that trusts your repo workspace. You set this up by copying the issuer URL and audience value from your repo settings. Next, you create an IAM role inside your AWS account. This role includes a trust policy that checks the incoming pipeline token.
When a build runs, the pipeline sends its token to the AWS token service. AWS checks the signature against the public keys from your code host. AWS also checks if the repo and branch match your trust policy rules. If the check passes, AWS returns temporary keys to the build runner. Those keys expire when the job ends or when the timer runs out. Your team no longer needs to rotate long-lived keys by hand.
Scoping trust rules for build pipelines
A basic trust rule only checks the workspace identifier. That broad rule lets any repo in your workspace assume the same AWS role. A test project could then trigger changes in your main cloud account. You should lock down the trust rule using subject claims. Subject claims let you filter by specific repo identifiers or deployment stages. You can make sure only your main branch assumes the production role.
Teams should also split roles by task. A build step that pushes container images only needs registry write permissions. A step that updates database schemas needs a separate role with narrower rules. Mixing these permissions into one giant role creates unnecessary risk during a build compromise. Small, focused roles limit what a bad script can do in your cloud account.
AWS IAM Policies + Bitbucket Pipelines Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What native cloud roles leave open at runtime
Federated identity solves the problem of static keys sitting in your code host. It checks which pipeline is allowed to log in to your cloud account. Still, the cloud role stops watching once the build gets its temporary keys. If a build runner connects to a database or cluster, the role allows full network sessions. The cloud role cannot see individual SQL queries or shell commands inside that session.
A compromised build script or bad migration file can still drop tables or read secret rows. Cloud logs will show that the role assumed a session, not the exact query text. Native cloud rules also cannot mask sensitive fields like emails, phone numbers, or card numbers. If a job prints query results to the build log, raw data appears in plain text. Masking rewrites matched fields in results so sensitive strings stay out of build logs.
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
Why did my pipeline fail the AWS token check?
Token checks usually fail when the audience or workspace string has a typo. Check that the identity provider URL and audience match the exact values in your repo settings.
Can I restrict an AWS role to one specific branch?
Yes, you can add a condition to your AWS role trust policy. Filter the token subject claim so only runs from your chosen branch or stage can assume the role.
How long do temporary pipeline credentials last?
Temporary credentials last for the duration set on your AWS role session timer. You can lower this timer so keys expire right after the build job finishes.