The enforcement in this model does not sit in the Jenkins plugin. Registering Jenkins as an IAM OIDC identity provider is a one-time job per AWS account, and AWS fetches and caches the JWKS thumbprint from the discovery URL at that moment [13]. After that, everything deciding which pipeline can reach which account lives in each role's trust policy. Hence the author's rule: pin `sub` to a concrete job path and `aud` to the exact identifier the plugin issues, with `StringEquals` rather than `StringLike` anywhere near production [14]. His published example pins `sub` to `repo:my-org/infra:ref:refs/heads/main` and `aud` to `sts.amazonaws.com` [15].
Sort the four documented failure modes by what an operator actually notices [17]. Two of them turn pipelines red, including the case that gives no error at registration time: AWS has to reach Jenkins over valid public HTTPS to fetch the discovery and JWKS documents, so an internal-only instance or a self-signed cert fails token validation quietly and only surfaces when a job first tries to assume a role [12]. Red pipelines get diagnosed, eventually. The other two, a trust policy wildcarded across the org and a single shared role covering both lint and deploy jobs, produce successful builds with more authority than the job needs [8][11][18]. Nothing in Jenkins complains, and unlike a static key there is no rotation ticket that periodically drags the grant back into view [1].
That is the part of the migration worth pricing. A static access key is indifferent to where Jenkins lives; it keeps working from anywhere until someone revokes it by hand [4]. A trust policy keyed to an issuer hostname is not indifferent at all: a new load balancer, a new domain, or a rebuilt box with a fresh cert changes the discovery URL and the JWKS endpoint, and the policies pinned to the old issuer stop matching [10]. You are trading an unbounded credential lifetime for a hard dependency on Jenkins keeping its public HTTPS identity stable [12]. That dependency is cheaper, but it is owned by whoever manages DNS and certs, not by whoever wrote the IAM policy.
The compensation is at rest. Jenkins holds no AWS credential in the model; it generates a signed assertion at runtime and AWS validates it against the trust policy before issuing anything [6][2]. A leaked token is short-lived and bound to a subject claim, so it expires whether or not anybody noticed [5]. A leaked key does neither [4].
One caveat on the evidence. The enumeration comes from a single migrator describing three Jenkins fleets, not a survey, and he says the mistake pattern was consistent across teams [7]. The two items you can verify against your own setup before shipping are whether the `aud` your plugin issues matches the string in the trust condition exactly [14] and whether your discovery endpoint resolves and presents a valid certificate from outside your network [12]. Neither check requires believing his sample.
