Support configurable token audiences in TokenReview authentication

[gbenhaim]

Problem

The Results API server performs TokenReview without specifying the Audiences field:

tr, err := r.authn.TokenReviews().Create(ctx, &authnv1.TokenReview{
    Spec: authnv1.TokenReviewSpec{
        Token: t,
    },
}, metav1.CreateOptions{})

When Audiences is omitted, the Kubernetes API server validates the token against its own default audience (typically https://kubernetes.default.svc). This means projected service account tokens with a custom audience are always rejected, even though they are perfectly valid and can be verified via TokenReview with the correct audience.

Use Case

Callers such as UI reverse proxies need to forward requests to the Results API on behalf of authenticated users. To follow the principle of least privilege, these callers should use a dedicated projected token with a restricted audience (e.g. audience: "tekton-results") rather than reusing a token that is also accepted by the Kubernetes API server for direct operations. This limits the blast radius if the backend is compromised — the scoped token cannot be used to impersonate users against the Kube API.

Today this is not possible because the Results API always validates tokens against the API server's default audience.

Proposed Solution

Add a new configuration option (e.g. AUTH_TOKEN_AUDIENCES) that accepts a comma-separated list of token audiences. When set, the RBAC checker would include these audiences in the TokenReview request:

tr, err := r.authn.TokenReviews().Create(ctx, &authnv1.TokenReview{
    Spec: authnv1.TokenReviewSpec{
        Token:     t,
        Audiences: r.audiences, // populated from AUTH_TOKEN_AUDIENCES config
    },
}, metav1.CreateOptions{})

This is fully backward-compatible: when AUTH_TOKEN_AUDIENCES is empty (the default), the existing behavior is preserved.

References

• Kubernetes TokenReview API - Audiences field
• Projected service account tokens with audiences

---

This issue was created by Gal's Cursor.