[junfeiliu531]

Description

Fixes #2791: secretless access to OpenAI using OpenAI Workload Identity Federation. A new OpenAICredentials BackendSecurityPolicy type has the controller obtain a subject token (SPIFFE JWT-SVID or OIDC), exchange it for a short-lived OpenAI access token, and rotate it before it expires. The data plane injects the token into requests to OpenAI.

OpenAI Workload Identity Federation reference: https://developers.openai.com/api/reference/workload-identity-federation

API (api/v1beta1)

spec:
  type: OpenAICredentials
  openAICredentials:
    organization: org-...   # optional, sent as OpenAI-Organization
    project: proj_...       # optional, sent as OpenAI-Project
    workloadIdentityFederationConfig:
      identityProviderID: idp_...   # required, OpenAI Workload Identity Provider ID
      serviceAccountID: user-...    # required, OpenAI service account ID
      subjectToken:                 # exactly one source
        spiffeJWTSVID:
          audience: <JWT-SVID aud claim, as configured for the identity provider>
          socketPath: unix:///run/spire/sockets/agent.sock   # optional
        # oidcExchangeToken:
        #   oidc: { ... }           # BackendSecurityPolicyOIDC, as in AWS/Azure/GCP

• workloadIdentityFederationConfig (OpenAIWorkloadIdentityFederationConfig) mirrors gcpCredentials.workloadIdentityFederationConfig. It holds the parameters of OpenAI's token exchange request: identityProviderID and serviceAccountID are sent as identity_provider_id and service_account_id.
• subjectToken (OpenAISubjectToken) groups the subject token sources; new sources are added there. OpenAI only accepts JWT subject tokens, so the subject token is always sent as urn:ietf:params:oauth:token-type:jwt, and an oidcExchangeToken provider must return a JWT.
• oidcExchangeToken reuses BackendSecurityPolicyOIDC, so the OIDC option has the same name and shape as in AWSCredentials, AzureCredentials and GCPCredentials.
• spiffeJWTSVID is named after what is fetched, leaving room for other SPIFFE sources later. Its API doc notes that the SPIFFE identity belongs to the controller, not the policy (unlike oidcExchangeToken, where the policy supplies its own credentials). Every such policy authenticates as the controller and can obtain tokens for any OpenAI service account mapped to the controller's SPIFFE ID, so only trusted cluster admins should create them.
• No tokenURL field: the controller always exchanges at https://auth.openai.com/oauth/token, so a policy cannot make the controller send subject tokens to an arbitrary URL.
• No audience or scope parameters: OpenAI's exchange does not accept them; permissions come from the service account mapping configured in OpenAI.
• CEL rules: exactly one source in subjectToken; socketPath must be unix:// or tcp://; openAICredentials is mutually exclusive with the other credential fields.
• v1beta1 only, following the CredentialOverride precedent.

Controller (internal/controller)

• tokenprovider.NewSPIFFETokenProvider: a TokenProvider backed by the SPIFFE Workload API (go-spiffe/v2). It fetches a JWT-SVID for a fixed audience. The socket address is passed explicitly or falls back to SPIFFE_ENDPOINT_SOCKET.
• tokenprovider.NewOpenAIWorkloadIdentityTokenProvider wraps any subject TokenProvider and sends OpenAI's documented JSON request body. The expiry comes from expires_at (Unix seconds) in the response; a response without it is rejected.
• OpenAI error responses ({"error": {"message", "code"}}) are surfaced in the policy status, e.g. token exchange failed with status 401: invalid_subject_token: Invalid subject token. Other error bodies are included truncated to 512 bytes.
• AI_GATEWAY_OPENAI_PROXY_URL routes token exchange requests through a proxy, like AI_GATEWAY_STS_PROXY_URL, AI_GATEWAY_AZURE_PROXY_URL and AI_GATEWAY_GCP_AUTH_PROXY_URL. When unset, the default transport's proxy settings (HTTPS_PROXY) still apply. Documented in the controller extraEnvVars example in the Helm values.
• rotators.NewOpenAITokenRotator stores the access token under openAIAccessToken in the generated ai-eg-bsp-<name> secret, mirroring the Azure token rotator. Rotation uses the controller's configured pre-rotation window (CredentialPreRotationWindow, default 5 minutes), like the other providers.
• The BSP controller builds the subject token provider from subjectToken.spiffeJWTSVID or subjectToken.oidcExchangeToken. OIDC client secrets referenced from other namespaces go through the same ReferenceGrant check as AWS/Azure/GCP.
• The gateway translates the policy into filterapi.OpenAIAuth. credentialOverride defaults to the x-aigw-openai-access-token header.

Data plane (internal/backendauth)

• An OpenAIAuth handler sets Authorization: Bearer <token>, plus OpenAI-Organization and OpenAI-Project when configured. The same headers are set when the token comes from a credential override.

Example

• examples/basic/openai-spiffe.yaml.

Related Issues/PRs (if applicable)

Fixes #2791

Special notes for reviewers (if applicable)

• Mounting the SPIFFE Workload API socket into the controller (with SPIFFE_ENDPOINT_SOCKET pointing at it) is left to the deployment. The identity provider and service account mapping must be configured in the OpenAI organization.
• Tests: unit tests for the SPIFFE and OpenAI token providers (including the proxy and OpenAI error handling), rotator, handler and controller wiring; CEL tests for the API rules. An envtest test in tests/controller runs the BSP controller against a fake SPIFFE Workload API and a fake OpenAI token exchange endpoint. There is no kind e2e: that would require SPIRE in CI, and no other provider's token rotation has one.
• Tested manually against OpenAI on a cluster with SPIRE: the controller exchanged a real JWT-SVID for an OpenAI access token (lifetime about 1 hour), the token worked for POST /v1/chat/completions, it was rotated before expiry, and a policy with the wrong SVID audience reported OpenAI's invalid_subject_token error. The data plane path (gateway injecting the token) was not exercised on that cluster.
• Possible follow-up: a spiffeJWTSVID option next to the existing oidcExchangeToken in AWS, Azure and GCP, without deprecating anything.

🤖 Generated with Claude Code [1]

1: https://claude.com/claude-code

[netlify]

✅ Deploy Preview for theagentrouter ready!

Name	Link
🔨 Latest commit	63a7a6f
🔍 Latest deploy log	https://app.netlify.com/projects/theagentrouter/deploys/6adfe875accbb4271cfd706b
😎 Deploy Preview	https://deploy-preview-2815--theagentrouter.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[codecov]

Codecov Report

❌ Patch coverage is 93.36735% with 13 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
...ternal/controller/rotators/openai_token_rotator.go	87.93%	7 Missing ⚠️
internal/controller/backend_security_policy.go	84.61%	4 Missing ⚠️
...rovider/openai_workload_identity_token_provider.go	96.82%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[aabchoo]

Just minor comments but everything looks good to me!

[aabchoo]

/retest

[aabchoo]

We should add a note that the controller "owns" the SPIFFE identity not the backend security policies. This is different from OIDC where the policy makers / tenants sets the credentials.

[aabchoo]

/retest

[aabchoo]

Thanks for addressing my requests + for the contribution!