A production deploy role's OIDC trust matches the subject `repo:acme/*:*`. What has that delegated?

## Read the string, segment by segment CI providers do not mint a random opaque subject. They pack the workload's identity into a delimited string whose segments mean specific things: the owning organisation and repository first, then the context - the branch or ref that ran, or the deployment environment the job declared. A trust condition on that string is therefore a pattern match over a hierarchy, and where you put the wildcard decides which level of the hierarchy you have stopped checking. `repo:acme/*:*` stops checking at the organisation. Everything after it - which repository, which branch, which environment - is accepted. Read aloud, the policy says: *any pipeline, in any repository, on any branch, belonging to this organisation, may assume the production deploy role.* ## Why that is worse than it sounds The instinct is that an organisation is a security boundary. It is not. It is a *namespace*. Consider who can put a new repository into it: - every engineer with repository-creation rights, which is usually everyone; - an intern on their first day, creating a sandbox; - an automation account that scaffolds repositories from a template; - a team that forked something in to evaluate it. None of those people are asking for production access. But any of them can add a pipeline that requests an identity token, and that token's subject will begin `repo:acme/`. The trust policy is satisfied. They now hold credentials for a role that was scoped, reviewed and approved for a completely different pipeline. The attacker in the interesting version of this is not an outsider. It is an authenticated, low-privilege insider - or someone who has phished one - who never had to escalate anything, because the escalation path was published as configuration. The asset at the far end is production customer data and the cloud control plane the deploy role touches. There is a second, quieter problem. A trailing `:*` also accepts contexts a repository owner may not have thought about, including the ones a provider mints for pull-request-triggered runs. Any pathway that gets a pipeline to execute in that repository becomes a pathway to the role. ## Tightening it 1. **Match the whole subject, exactly.** Name the single repository and the specific context segment. Where the provider offers both a ref form and an environment form of the subject, bind to the **environment** - it is the boundary you actually care about, and it survives branch renames. 2. **Use equality, not pattern matching.** Many cloud providers offer both a literal-equality and a wildcard-capable string condition. Choosing the pattern-capable operator and then writing a literal string is how a wildcard sneaks in later during a "small" edit. 3. **One role per environment.** Staging and production deploys should federate into different identities even when they live in the same repository, so a job that only ever needed staging cannot mutate production infrastructure. Reusing one identity because "it is the same repo" is the same defect wearing a different hat. 4. **Least privilege on the role itself.** The trust condition decides *who may assume*; the permission set decides *what they get*. Both need scoping, and they are usually owned by different people. 5. **Audit for it.** Enumerate every role with a federated principal, parse its subject condition, and flag anything containing a wildcard or lacking a subject condition entirely. Treat a missing audience condition the same way. This is a five-minute standing check that finds real findings in most estates. ## The pushback you will get, and the answer Teams widen the subject for a reason: exact matching breaks when someone renames a branch, adds a new environment, or splits a repository. The answer is not to widen; it is to bind to the environment claim rather than the ref, and to generate the role's trust condition from the same source of truth that creates the repository or environment, so adding one is a change to that definition rather than a manual edit to a policy that nobody wants to touch. The other pushback is that the wildcard is fine because the role's permissions are limited. Sometimes that is even true - but it means the containment now rests entirely on a permission set that was written for a different threat, and it will not hold the next time somebody adds a permission to unblock a deploy. ## What tightening the subject does *not* fix It does not protect you from a compromise of the legitimate pipeline itself: a malicious change merged into the right repository, on the right branch, targeting the right environment, produces a token that satisfies the condition perfectly. That is what environment approvals, change review and permission scoping are for. Subject pinning removes the free path; it does not remove the earned one.