Rules / GL009
GL009 Overly broad OIDC id_tokens audience
Severity: warn
Minimum GitLab version: 15.7 (id_tokens: was introduced in 15.7)
OWASP: CICD-SEC-5 – Insufficient PBAC
What glsec checks
glsec flags id_tokens: entries whose aud: value is a GitLab instance URL — a host whose first DNS label is gitlab (gitlab.com, gitlab.example.com). Such an audience is accepted by any service configured with that GitLab instance as an OIDC issuer, rather than being scoped to a specific cloud service.
A service that merely lives on a gitlab.* domain — e.g. https://vault.gitlab.net (a Vault server) or https://registry.gitlab.com — is a legitimate, scoped audience and is not flagged.
Trigger example
deploy-aws:
id_tokens:
AWS_OIDC_TOKEN:
aud: "https://gitlab.example.com" # instance root — too broad
script:
- ./deploy.sh
Safe alternative
Use the specific audience required by each cloud provider:
deploy-aws:
id_tokens:
AWS_OIDC_TOKEN:
aud: "https://sts.amazonaws.com" # AWS STS
script:
- ./deploy.sh
deploy-gcp:
id_tokens:
GCP_TOKEN:
aud: "https://iam.googleapis.com/projects/123/locations/global/workloadIdentityPools/my-pool/providers/my-provider"
script:
- ./deploy.sh
deploy-vault:
id_tokens:
VAULT_TOKEN:
aud: "https://vault.example.com"
script:
- ./deploy.sh
Why this matters
When aud: is the GitLab instance root URL:
- Any cloud service that trusts that GitLab instance as an OIDC issuer will accept the token
- If an attacker obtains the token from one job, they can reuse it against other services that share the same audience
- A compromised or misconfigured job in any project on the same instance could obtain tokens accepted by your cloud provider
Service-specific audiences (e.g. https://sts.amazonaws.com) limit the token's usefulness to exactly one service, dramatically reducing the blast radius of a token leak.
GitLab documentation
Connect to cloud services using OpenID Connect
Documentation for glsec 1.23.0. Source of this page · Rule implementation