glsec

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:

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