An Unexpired ServiceAccount Token Can Refer to a Pod That Is Gone

The binding identifies an object instance

An external AI-platform service may accept a Kubernetes ServiceAccount token as a credential. To assess the offered integration, distinguish the signed reference from the object it refers to. The reference travels with the token; the object's continued existence is a separate fact.

This explanation uses the archived Kubernetes v1.34 documentation and the v1.34.0 implementation. In that implementation, the Kubernetes-specific claims include the namespace, ServiceAccount name and UID, and, for a Pod binding, the Pod name and UID. The validator checks public time claims, retrieves the ServiceAccount and compares its UID, then retrieves the bound Pod and compares that UID. A failed Pod lookup or UID mismatch prevents authentication.

The UID comparison matters when a familiar name returns. Reusing a name cannot establish continuity with the original object instance. The token's signature does not change when an object disappears, and its embedded reference does not rewrite itself to name a replacement.

References: [K2][K4]

Offline validation leaves current object state unanswered

Kubernetes v1.34 describes offline validation using a compliant JWT validator and the API server's OpenID Discovery information. It also states that this path does not verify whether embedded bound claims remain current. For clients needing that assurance, the documentation identifies TokenReview.

Suppose a supplier demonstrates acceptance of an appropriately issued, signed, audience-matched and unexpired token. If the demonstration covers only those offline checks, it has established no observation of the referenced Pod. Reading a Pod UID from verified signed content establishes which UID was recorded; it does not establish that an object with that UID remains.

The useful distinction is the evidence supplied by each validation contract. Offline acceptance can be consistent with its stated checks while leaving the buyer's requirement for current bound-object assurance unmet.

References: [K1][K4]

BOUND-UID: 45 minutes remain, but the original Pod does not

BOUND-UID is a fictional comparison involving one symbolic Pod-bound token. Its exp corresponds to 13:00. At 12:15, the issuer, signature, intended audience, public time claims and all unrelated authentication conditions are stipulated to be suitable. These times use the same fictional day and clock; they are readable shorthand, not an encoded JWT.

The token refers to Pod worker-a in namespace train, with UID A. By 12:10 that original Pod no longer exists. At 12:15, the object lookup used for the comparison reports it absent. The premise is actual object absence, rather than an object merely marked for deletion, so the conclusion does not depend on a pending-deletion timing boundary.

The remaining clock interval is 13:00 minus 12:15: 45 minutes. That calculation supplies time remaining before exp. It supplies no evidence that UID A exists.

A validator limited to the stipulated offline checks can still accept the token on those checks. The Kubernetes bound-object validation path rejects the absent Pod reference. These conclusions differ because one comparison includes an object-state condition that the other never evaluates.

The example predicts the consequences of its premises under the cited validation behavior. It supplies no actual token, endpoint response or performed access test.

References: [K2][K4]

The same Pod name cannot restore UID A

Now consider the alternative in which train/worker-a exists at 12:15, but it is a replacement with UID B. The token is unchanged and still names UID A. The lookup finds a Pod, yet the UID comparison fails: B is not A.

Finding a current object by name therefore does not complete the identity check. Nor does observing that the replacement uses the same ServiceAccount establish that it is the Pod instance bound to this token.

For an integration proposal, a claim such as the worker still exists needs this distinction made explicit. A name-based inventory can describe the replacement without substantiating the original binding. Neither the replacement's existence nor the 45 remaining minutes repairs the mismatch.

References: [K2]

TokenReview adds authentication evidence with an audience context

The TokenReview API attempts to authenticate a token to a known user. Its API model identifies the presented token as a bearer token and distinguishes the authentication result, associated user information, compatible audiences and an error when the token could not be checked.

Audience context remains essential for an external service. In the API model, omitting requested audiences defaults to the Kubernetes API server's audience. A client specifying audiences needs a compatible audience returned in the result. A generic authenticated result cannot be read as acceptance for every external recipient.

For the buyer, the practical consequence is to ask which result the integration actually relies on: local JWT checks alone, or Kubernetes authentication that includes the applicable bound-object checks. If an earlier review is reused, its observation time matters. An earlier positive result cannot prove that UID A remains after the stipulated disappearance. A review error likewise supplies no positive evidence that the Pod exists.

The API result concerns authentication. Permission to read a particular model artifact or invoke an inference operation remains an application decision. An authenticated identity also does not by itself prove that the Pod is healthy or identify which process presented the bearer credential. Those conclusions require evidence beyond the bound-object check.

References: [K1][K3][K4][K5]

Pod-bound Node metadata has a narrower meaning

A Pod-bound token can also contain Node name and UID metadata. Kubernetes v1.34 explicitly says that the API server does not verify the referenced Node's existence when authenticating a Pod-bound token. The v1.34.0 validator extracts those Node claims in its Pod-bound branch; Node-bound token validation has a separate branch.

Consequently, a supplier cannot use the mere presence of Node fields, or a positive Pod-bound authentication result, as evidence of a current Node-existence check. The object to which the token is bound determines the relevant promise.

References: [K1][K2]

Make the offered assurance match the integration requirement

For BOUND-UID, the decisive question is whether the external service needs acceptance under the stated offline token checks or evidence that the original binding still holds. If it needs the latter, a demonstration ending with signature, audience and expiry leaves the required object-state condition unanswered. A demonstration that locates only train/worker-a also leaves the UID condition unanswered.

Ask the appointed platform owner to explain the integration's handling of the absent-UID-A and replacement-UID-B alternatives, together with the audience and observation time of any review it relies on. The explanation also needs to identify what happens when the review cannot be completed; an unavailable answer cannot substantiate a fresh check. This evaluates the proposed assurance without prescribing a token-creation, revocation or configuration procedure.

The related JWT article covers recipient, time and permission under its named OAuth access-token profile; that profile is not imposed on this Kubernetes token. The Secret article follows delivery into application use. The RBAC article explains permission grants and binding scope. Those are useful adjacent decisions, while this comparison concerns the continued validity of a specific Pod binding.

References: [K1][K2][K3]

Scope a separate equipment installation and handoff

If the wider AI-platform project includes receiving, rack integration, onsite installation or IT cabling, Leviathan's Complete Physical Infrastructure Deployment service provides a route to discuss those physical stages and their handoff records.

Use the related service and project inquiry with a nonconfidential equipment outline, site, required physical stages and receiving team. Kubernetes identity verification and application authorization remain with the appointed platform and security owners.

References: [L1]