#28356·argo-cd

Support presenting a pre-issued OIDC token (e.g. projected ServiceAccount token) for cluster authentication

Author: SamyDjemaiCreated Jun 19, 2026Updated Sep 18, 2026
LabelsStale

Summary

Add a generic way for Argo CD to authenticate to a managed cluster by presenting a pre-issued OIDC token (a signed JWT, i.e. an ID token) — for example a projected ServiceAccount token — to a target API server that is configured to trust an external OIDC issuer (--oidc-issuer-url / structured AuthenticationConfiguration).

Today argocd-k8s-auth has aws, gcp, and azure subcommands, but each mints a cloud-provider access token. There is no built-in, provider-agnostic way to present a standard OIDC ID token that the target API server validates via the Kubernetes JWT/OIDC authenticator.

Motivation

Per the Kubernetes authentication reference, the OIDC/JWT authenticator requires the id_token (not an access token) and validates its signature (via the issuer's JWKS), iss, aud, and exp server-side. Many Kubernetes distributions and managed-cluster providers expose an endpoint that accepts exactly this: a JWT signed by a trusted external OIDC issuer.

A common, credential-free source of such a token is a projected ServiceAccount token whose audience matches the target API server's configured client ID. The kubelet rotates this token in place, so:

  • it eliminates long-lived stored cluster credentials (no static bearer token in the cluster Secret);
  • it cannot be expressed with a static bearerToken field, because the token is short-lived and rotated — it must be re-read at request time.

This enables a keyless, workload-identity-style connection from Argo CD to any OIDC-trusting Kubernetes API server, using the cluster that runs Argo CD as the trusted OIDC issuer.

Proposal

Add an oidc subcommand to argocd-k8s-auth that:

  • reads a pre-issued token from a file (--token-file, or an env var), and
  • emits it as a client-go ExecCredential (status.token), setting status.expirationTimestamp from the token's exp claim so client-go caches and re-invokes the plugin before expiry (re-reading the rotated token), per the client-go credential plugin contract.

The subcommand performs no verification itself — the target API server validates the token. Used from a cluster Secret via execProviderConfig, with a projected token volume whose audience matches the API server's OIDC client ID.

Implementation: #28354