Beyond Yanmen Pass, a string of small outposts kept watch over short stretches of trade road. Further west sat the imperial “Grand Granary,” reserved for emergency grain requisitions.

The old rule was simple: each outpost was issued a bronze key to the granary. Once cast, a key worked forever — whoever held it could open the gate. This worked fine for years, until one day a courier’s key was lifted by a thief mid-journey. The thief was in no hurry; he sat on the key for three months before using it. The granary had no idea the key had changed hands — it opened the gate just the same. Only then did the granary keeper realize the danger: once a key like that goes missing, there’s no way to reclaim it short of sending someone all the way to the frontier to physically recast it.

So they devised a new system. The frontier no longer cast keys. Instead, the Pass Commander — not the granary keeper, the commander at the pass itself — issued each outpost a fresh chit every day. The chit bore the commander’s personal seal, stated plainly “issued only to the grain-courier of the Third Outpost,” and carried a time limit: one hour after issuance, the ink would fade and the chit would go blank.

When a courier arrived at the granary with a chit, the keeper never sent a rider back to the pass to ask “is this really the commander’s seal?” Years earlier, he’d hung a rubbing of the commander’s seal pattern on the storehouse wall. He simply compared the chit’s seal against that rubbing on the spot — no need to consult the commander in person.

A matching seal wasn’t enough on its own, either. The keeper’s ledger carried an ironclad rule: even a chit bearing the commander’s genuine seal would be refused unless it read, word for word, “grain-courier of the Third Outpost.” A chit for the Fifth Outpost, seal and all, got turned away just the same.

Only once a chit passed both checks did the keeper hand over a temporary grain token — good for exactly one hour, after which it too went blank, forcing a fresh chit and a fresh token on the next visit. From then on, even if some chit or token fell into a thief’s hands, the most damage he could do was cause trouble for that single hour. Soon enough the chit and token turned to waste paper — no more lifetime key to steal.

——By now you’ve probably recognized it: that chit is a Kubernetes service account token — an OIDC-issued JWT. The seal rubbing hanging on the storehouse wall is the OIDC identity provider that AWS registered ahead of time (along with its JWKS / certificate thumbprint). The keeper’s ironclad rule that the wording must match exactly is the IAM trust policy’s condition check on sub and aud. And that one-hour grain token is the temporary STS credential obtained by calling sts:AssumeRoleWithWebIdentity.

What it is

On AWS this mechanism is called IRSA (IAM Roles for Service Accounts); ROSA/OpenShift use an equivalent pattern. The core idea is replacing long-lived static AWS access keys sitting in a pod with OIDC federation. The cluster itself acts as an OIDC issuer: kubelet automatically mounts each pod’s service account with a short-lived, auto-rotated JWT carrying key claims — iss (the issuer, i.e. the cluster’s OIDC endpoint), sub (typically system:serviceaccount:<namespace>:<service-account>), aud (audience, commonly sts.amazonaws.com), and exp (usually about an hour).

On the AWS side, the cluster is pre-registered as an IAM OIDC identity provider, along with its certificate thumbprint — so when STS verifies the JWT’s signature, it doesn’t need to call back to the cluster in real time; it just checks against the locally stored public key/thumbprint, which is fast and avoids extra trust-chain dependencies.

Why it matters

The actual access control happens in the IAM role’s trust policy, via a StringEquals condition that pins down exactly which namespace and service account’s token may assume that role — a valid signature alone isn’t enough; a claim mismatch still gets rejected. What comes back isn’t a permanent key but a temporary AccessKeyId/SecretAccessKey/SessionToken triple from AssumeRoleWithWebIdentity, typically expiring within an hour — so even if the token or the temporary credential leaks, the exposure window is tightly bounded. This is also why, nine times out of ten, an AccessDenied investigation traces back to a mismatched sub/aud condition, a misregistered OIDC provider, or a simply expired token.

Metaphor mapping

• The Grand Granary out west → Target AWS resource / IAM Role (Protected cloud storage and services requiring temporary credentials)
• The Pass Commander → Cluster OIDC Issuer (Authority signing short-lived identity tokens (JWT) with its private key)
• The daily chit → Pod ServiceAccount Token (Short-lived JWT containing iss, sub, aud, and exp claims)
• The seal on the chit → JWT digital signature (Cryptographic signature proving the token was not forged or altered)
• The seal rubbing on the storehouse wall → IAM OIDC Provider & thumbprint (Pre-registered JWKS/thumbprint cached locally in AWS for instant verification)
• “The wording must match exactly” → Trust policy StringEquals check (Condition enforcing that sub matches the specific namespace and SA)
• The chit that fades after an hour → Short token expiration (exp) (Rotated automatically by kubelet to bound the window of compromise)
• The temporary grain token → Temporary STS credentials (1-hour access credentials returned by AssumeRoleWithWebIdentity)
• The old lifetime bronze key → Long-lived static AWS access key (High-risk credentials embedded in pods, nearly impossible to safely rotate)