Fix(charts+controller): SPIFFE auth follow-up — jwtAudience cleanup, credential secret skip, tag fix

[Alan-Cha]

Summary

Follow-up fixes to #473 based on E2E testing of the full SPIFFE auth stack.

Changes

1. Remove jwtAudience Helm value — always derive from keycloak.publicUrl

spiffe.operatorAuth.jwtAudience was the audience embedded in the JWT-SVID that SPIRE mints for the operator. This value must exactly equal keycloak.publicUrl/realms/<realm> — the issuer URL Keycloak's FederatedJWTClientValidator checks against. It cannot meaningfully be set to anything else.

Removed the user-facing field. The template now derives the value directly from keycloak.publicUrl and keycloak.realm, and fails at helm install time with a clear message if keycloak.publicUrl is not set. Eliminates a footgun where using the internal k8s service URL instead of the external URL causes a silent auth failure.

2. Skip credential Secret creation in federated-jwt mode

In federated-jwt mode, AuthBridge reads JWT-SVIDs from the SPIFFE workload API socket directly — it does not read the kagenti-keycloak-client-credentials-* Secret. The operator was still creating it unconditionally.

Keycloak correctly rejects client_secret grants for federated-jwt clients (HTTP 401), so the Secret is not exploitable. But it is unnecessary and adds noise in agent namespaces.

Fix: skip ensureClientCredentialsSecret() when CLIENT_AUTH_TYPE == "federated-jwt".

3. Remove spiffeHelper.image values block — revert to :latest

The spiffeHelper.image.* values block was mistakenly introduced in #473. The ghcr.io/kagenti/kagenti-extensions/spiffe-helper image is not published by the kagenti-extensions build pipeline (which only builds authbridge, authbridge-envoy, authbridge-lite, proxy-init). Pinning to a specific tag has no meaning — only :latest exists from a historical publish.

This commit removes the values block and hardcodes :latest in the template. Issue #477 tracks replacing the sidecar approach entirely with a direct go-spiffe SDK call, which would eliminate the external image dependency.

Testing

Validated on a fresh Kind cluster with both operator and agent SPIFFE auth enabled:

• Operator 2/2 containers, STATUS: deployed
• Agent clients registered with SPIFFE IDs
• Direct JWT-SVID → Keycloak token exchange: HTTP 200
• Keycloak rejects client_secret grant for federated-jwt clients: HTTP 401
• No credential Secrets created for federated-jwt agents

Related

• Follows: Feat(operator): implement SPIFFE JWT-SVID authentication for client registration #473
• Tracked in: feat: Remove all provisioned credentials in favor of SPIFFE-based Keycloak authentication rossoctl#2174
• Future work: feat: replace spiffe-helper sidecar with direct go-spiffe SDK call for operator JWT-SVID auth #477

Checklist

• All commits signed-off (DCO)
• Backward compatible

Assisted-By: Claude Code

[Alan-Cha]

Note on removing spiffeHelper.image values block:

This was mistakenly introduced in #473. The ghcr.io/kagenti/kagenti-extensions/spiffe-helper image is not published by the kagenti-extensions build pipeline — that pipeline only builds authbridge variants (authbridge, authbridge-envoy, authbridge-lite, proxy-init). Pinning to a specific tag therefore has no meaning; only :latest exists from a historical publish.

This PR removes the spiffeHelper.image values block and hardcodes :latest in the template to restore a working state. Issue #477 tracks replacing the sidecar approach entirely with a direct go-spiffe SDK call.

[mrsabath]

Review

Clean, well-scoped follow-up to #473. Verified every claim against the PR head.

This is a textbook dual-mode PR, so I focused on source/env/fallback parity across the three code paths that must agree in federated-jwt mode:

Path	File	federated-jwt behavior	Source
Controller	clientregistration_controller.go:378	skips ensureClientCredentialsSecret + patchTemplate	CLIENT_AUTH_TYPE in authbridge-config
Webhook	authbridge_webhook.go:106	skips annotation pre-population	same CM via ReadNamespaceConfig
Mutator	pod_mutator.go:857	emits SPIFFE identity, no secret mount	same CM / constant

All three read CLIENT_AUTH_TYPE from the same ConfigMap and compare against the same value — the controller uses the string literal "federated-jwt", webhook/mutator use injector.ClientAuthTypeFederatedJWT (defined as that literal in constants.go:37). No parity gap.

Other checks:

• Default/fallback parity ✓ — empty/absent CLIENT_AUTH_TYPE → controller defaults to client-secret; webhook's "" != federated-jwt → pre-populates the annotation. Consistent safe default.
• Helm fail guard ✓ — the hard fail on empty keycloak.publicUrl is inside the spiffe.operatorAuth.enabled block, so it never breaks default (non-SPIFFE) installs. keycloak.{publicUrl,realm} always exist in values.yaml, so no template nil-deref.
• No dangling refs ✓ — removed spiffe.operatorAuth.jwtAudience and spiffeHelper.image have zero remaining references in the chart.
• CI ✓ — all 16 checks pass, including E2E (32m) and DCO.

The :latest hardcode (change #3) is a documented trade-off tracked in #477, not a defect.

Verdict: APPROVE — no blocking issues. The dual-mode parity, usually where these PRs hide bugs, is correct across all three paths.

Areas reviewed: Helm, Go controller, Go webhook, Go mutator (cross-referenced)
Commits: 4, all signed-off
CI status: passing (16/16)