Bitbucket Pipelines Openid Connect AWS Ephemeral Credentials
You set up bitbucket pipelines openid connect aws ephemeral credentials by linking your workspace to an AWS identity provider. When a build runs, Bitbucket trades a signed token for short-lived AWS keys. Most teams used to save static AWS keys inside build settings. Static keys never expire on their own and create huge risk if leaked. Even with short-lived tokens, broad cloud roles still let build jobs run dangerous commands. How bitbucket pipelines openid connect aws ephemeral credentials wor
Ephemeral Credentials + Bitbucket Pipelines Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up bitbucket pipelines openid connect aws ephemeral credentials by linking your workspace to an AWS identity provider. When a build runs, Bitbucket trades a signed token for short-lived AWS keys. Most teams used to save static AWS keys inside build settings. Static keys never expire on their own and create huge risk if leaked. Even with short-lived tokens, broad cloud roles still let build jobs run dangerous commands.
How bitbucket pipelines openid connect aws ephemeral credentials work
This workflow removes the need to store static secrets in your build tool. First, you copy the unique identity URL and audience string from your Bitbucket workspace. Next, you add a new OpenID Connect provider inside your AWS identity settings. You paste the workspace URL and audience string to build a trust link. Then, you create an IAM role that trusts this specific identity provider. When a pipeline starts, Bitbucket makes a signed JSON Web Token for that job. The build job sends this token to the AWS Security Token Service. AWS checks the digital signature and reads the claims inside the token. If the claims match your trust policy, AWS returns temporary keys. The runner uses these keys to deploy code or update cloud resources. Once the build job finishes or the timer runs out, the keys stop working.
Locking down the AWS trust policy
A basic trust link is not enough to keep your cloud account safe. If you only check the workspace URL, any repo in that workspace can assume the role. You must add strict condition checks to the IAM role trust policy. The token from Bitbucket holds claims for the workspace, repo, and branch UUIDs. Your team should write a rule that checks the exact repo identifier. For production roles, you can also lock the policy to your main branch. This stops a test branch in a side project from touching production resources. You should also set a short session time limit on the IAM role. Most build jobs only need fifteen to thirty minutes to finish their work. Short timers reduce the window of risk if a build script gets compromised.
Where native cloud identity controls stop
Using short-lived tokens solves the problem of leaked static keys in your repos. It proves which build job is asking to log in to your cloud account. Still, cloud roles only decide who logs in and which services they can reach. Once the build runner gets a valid session, IAM steps out of the way. Many pipeline jobs need to run database migrations or maintenance scripts during a deploy. If the role allows database access, the runner gets full power over that data. Cloud identity rules cannot inspect individual SQL statements or shell commands in flight. A broken script could drop a table or read customer emails and card numbers. Native logs show that a role assumed a session, not what queries ran inside the database. Teams still lack fine-grained checks and data masking for the commands that pipelines or engineers run.
Ephemeral Credentials + Bitbucket Pipelines Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
Why did the AWS token exchange fail in my pipeline?
Token exchange failures usually happen when the audience string or repo UUID does not match. Check that your IAM trust policy matches the exact claims sent by your Bitbucket workspace.
Do I still need to rotate AWS keys when using OpenID Connect?
No, you do not need to rotate keys because no static keys exist. AWS creates fresh keys for every build run and deletes them when the session ends.
Can I use different AWS roles for staging and production branches?
Yes, you can create separate IAM roles for each deployment stage in your workflow. Lock each role trust policy to the specific branch claim or deployment environment UUID.