AWS GitLab OIDC
You set up aws gitlab oidc by linking your GitLab server to an AWS identity provider. Then your build jobs trade short-lived job tokens for temporary cloud credentials. Teams use this flow so they do not store static keys inside project settings. Still, many teams attach broad admin roles to those build jobs to make deployments work. If a bad script runs in a pipeline, it gets full control over your cloud. How aws gitlab oidc works in a build pipeline In the past, engineers created a cloud us
AWS IAM Policies + GitLab CI Security: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up aws gitlab oidc by linking your GitLab server to an AWS identity provider. Then your build jobs trade short-lived job tokens for temporary cloud credentials. Teams use this flow so they do not store static keys inside project settings. Still, many teams attach broad admin roles to those build jobs to make deployments work. If a bad script runs in a pipeline, it gets full control over your cloud.
How aws gitlab oidc works in a build pipeline
In the past, engineers created a cloud user and copied secret keys into GitLab. Anyone who could read project settings could steal those static keys and use them anywhere. Rotating those keys took hours of manual work and often broke live build jobs.
OpenID Connect replaces those static keys with a direct trust link between the two platforms. First, you register your GitLab domain as a trusted identity provider inside your cloud account. Next, you create an AWS role with a trust rule that checks incoming job tokens. When a pipeline job starts, GitLab signs a digital token that states the project path. The token also lists the git branch, user name, and job ID for that run.
The build runner sends this signed token to the cloud security token service. The cloud service checks the signature against the public keys from your GitLab server. If the project path and branch match your trust rule, the cloud issues temporary keys. Those keys expire on their own when the build job finishes or hits its time limit.
How to scope trust rules for your pipelines
A common mistake is writing a trust rule that only checks the GitLab server name. That weak rule lets any project on the shared server assume your cloud role. You must filter the token claim by project path, branch name, or deployment tier.
Most teams split their cloud roles by stage, such as test, staging, and production. Feature branches get a role that can only run tests or check build files. Only the main branch gets permission to assume the role that updates live systems. You should also set a short session time limit so tokens expire right after the job.
Teams also scope the permissions attached to each cloud role to limit blast radius. Still, deployment jobs often need broad rights to update databases, servers, and network rules. Scoping the trust rule only controls which branch can start the session.
AWS IAM Policies + GitLab CI Security: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
What identity federation solves and what it leaves open
Using federated tokens stops secret sprawl and removes long-lived keys from your code host. You no longer have to rotate static keys when an engineer leaves the team. Cloud logs also show which pipeline job asked for a role and when it happened.
Still, this setup only checks who starts the session before the job runs. Once the pipeline holds a valid role, the cloud trusts every command inside that session. If a build job opens a database session, identity rules cannot inspect the SQL queries. A faulty migration script can still drop a table or read raw customer rows. Standard role rules also will not rewrite emails, phone numbers, or card numbers in query output.
Engineers also need direct access to fix broken systems when a deployment fails. Federated build tokens do not govern interactive human sessions on databases or cloud hosts. Without runtime controls, teams cannot approve risky commands one by one or mask sensitive fields.
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 sits inline in the protocol beside each supported service as an open-source proxy, a sidecar for your database or API. For every query or command an AI agent or engineer runs against production, hoop.dev decides to pass, mask, block, or hold it for human approval.
First, hoop.dev guardrails block banned queries before they run or hold risky ones for review, and hoop.dev data masking rewrites matched sensitive values in responses in memory. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
Why did my pipeline fail to assume the cloud role?
Most failures happen when the token subject string does not match your role trust rule. Check that the project path and git branch name match the exact text in your rule. Also check that the audience value in your job matches the identity provider setting.
Do I need a separate identity provider for every GitLab project?
No, you only set up one identity provider per GitLab domain in each cloud account. You then create separate cloud roles for each project and filter them with trust rules. Each role checks the subject claim to confirm which project sent the request.
Can a developer steal the temporary credentials from a build log?
GitLab hides known secret variables in job logs by default, but bad scripts can leak them. A script could encode the temporary keys and print them or send them outside. Set a short session duration on the cloud role to shrink that risk window.