# 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.

## Related pages

* [Workload Federation and Non-Human Identities](/architecture-api-crypto-and-identity/index-2/workload-federation-and-non-human-identities.md)
* [Runner Isolation and Trust Boundaries](/devsecops-cicd-and-supply-chain/index-1/runner-isolation-and-trust-boundaries.md)

## Suggested reference links

* [GitHub OIDC](https://docs.github.com/en/actions/concepts/security/openid-connect)
* [GitHub cloud-provider OIDC hardening](https://docs.github.com/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-cloud-providers)
* [GitLab OIDC to Google Cloud](https://docs.gitlab.com/ci/cloud_services/google_cloud/)

***

*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/architecture-api-crypto-and-identity/index-2/github-gitlab-oidc-and-cloud-trust-patterns.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.