🔐 GitHub, GitLab, and Cloud Trust Patterns

Intro: OIDC is not automatically safe. It becomes safe when the trust conditions are narrow, the audience and subject claims are constrained, and the resulting cloud role cannot quietly turn build access into production control.

What this page includes

how GitHub Actions and GitLab map to cloud trust

what to restrict in subject, audience, branch, and environment claims

how to separate build from deploy authority

sample design patterns and anti-patterns

What good OIDC trust looks like

Bind trust to predictable claims

For both GitHub and GitLab, restrict cloud trust by:

repository or project;
branch or tag pattern;
environment;
workflow or pipeline identity where available;
audience expected by the cloud side.

Split authority by stage

A common strong pattern is:

build identity: can read dependencies and push a candidate artifact;
deploy identity: can promote only from approved branches or environments;
release evidence identity: can write attestations and evidence but not deploy.

GitHub Actions notes

Current GitHub guidance emphasizes OIDC because workflows can exchange short-lived tokens directly from the cloud provider instead of storing long-lived cloud secrets. The id-token: write permission only permits token minting; it does not itself grant cloud access. The real risk sits in the cloud trust policy and the role permissions.

GitLab notes

Current GitLab guidance for cloud services similarly pushes ID tokens and workload identity federation rather than long-lived service-account keys. Treat GitLab project, branch, ref type, and environment as security-bearing claims.

Review questions

Could a pull request workflow ever reach a production cloud role?
Could a reusable workflow or shared runner mint a token outside the intended repo or project?
Does the role have more permissions than the stage needs?
Would a malicious image push or manifest change be blocked elsewhere if the token were abused?

Anti-patterns

a single federated role reused for every branch and environment;
wildcard trust on subjects;
deploy roles that can also read high-value secrets and mutate IAM;
shared runners trusted the same way as hardened dedicated runners.