Scope the role, not just the trust policy

Long-lived credentials in a pipeline are a liability that grows quietly. The rotation nobody owns, the key that appears in a log, the contractor who left with a copy. OIDC removes the class of problem instead of managing it.

What changes

The workflow asks its host for a short-lived token and exchanges it for a role. Nothing durable is stored:

permissions:
  id-token: write
  contents: read

Credentials expire in minutes. The audit trail names the workflow rather than a shared key. There is no secret to rotate.

Scope the trust properly

The condition on the token's subject claim is the whole security boundary, so make it specific. Trust the immutable form as well as the readable one — the numeric IDs survive a repository rename, and the readable string does not:

repo:my-org/my-repo:*
repo:my-org@79019803/my-repo@1330095362:*

A rename with only the readable form in the policy breaks every deploy, and the error says nothing about renames.

Scope the role, not just the trust

Trust decides who can assume it. The policy decides what they get. A deploy role that can manage one stack, write to one bucket prefix, and touch IAM only for roles matching its own name is a much smaller blast radius than one with broad access and a tight trust policy. Do both.