Problem
PR #473 added a spiffe-helper sidecar container to the operator pod for fetching JWT-SVIDs. This sidecar references ghcr.io/kagenti/kagenti-extensions/spiffe-helper, but that image is not published by the kagenti-extensions automated build pipeline (which only builds authbridge variants). The image exists at :latest from a historical publish, but there is no active pipeline maintaining versioned tags.
The current state in main uses a hardcoded :latest which is fragile and non-reproducible.
Better approach
The operator already uses the go-spiffe SDK (github.com/spiffe/go-spiffe/v2) for verifiedFetch via workloadapi.NewX509Source. The same workloadapi.Client exposes FetchJWTSVID(ctx, jwtsvid.Params) which can fetch a JWT-SVID on demand directly from the SPIRE workload API socket — no sidecar, no external image, no file on disk.
This would:
- Eliminate the external image dependency entirely
- Remove the
spiffe-helper sidecar container and associated volumes from the operator deployment
- Fetch JWT-SVIDs on demand per reconcile rather than relying on a file refreshed by a sidecar
- Reuse the existing
--verified-fetch-spiffe-socket flag (or a shared --spiffe-socket flag)
Work required
- Update
ClientRegistrationReconciler to accept a SpiffeSocket string field instead of JWTSVIDPath
- In the SPIFFE auth path, create a
workloadapi.Client and call FetchJWTSVID(ctx, jwtsvid.Params{Audience: keycloakRealmIssuerURL})
- Remove
--jwt-svid-path flag from cmd/main.go; reuse or rename --verified-fetch-spiffe-socket
- Remove the spiffe-helper sidecar,
jwt-svid emptyDir volume, spiffe-helper-config ConfigMap, and configmap-spiffe-helper.yaml template from the chart
- Remove
spiffe.operatorAuth.spiffeHelper values block
Related
Problem
PR #473 added a
spiffe-helpersidecar container to the operator pod for fetching JWT-SVIDs. This sidecar referencesghcr.io/kagenti/kagenti-extensions/spiffe-helper, but that image is not published by the kagenti-extensions automated build pipeline (which only builds authbridge variants). The image exists at:latestfrom a historical publish, but there is no active pipeline maintaining versioned tags.The current state in main uses a hardcoded
:latestwhich is fragile and non-reproducible.Better approach
The operator already uses the go-spiffe SDK (
github.com/spiffe/go-spiffe/v2) forverifiedFetchviaworkloadapi.NewX509Source. The sameworkloadapi.ClientexposesFetchJWTSVID(ctx, jwtsvid.Params)which can fetch a JWT-SVID on demand directly from the SPIRE workload API socket — no sidecar, no external image, no file on disk.This would:
spiffe-helpersidecar container and associated volumes from the operator deployment--verified-fetch-spiffe-socketflag (or a shared--spiffe-socketflag)Work required
ClientRegistrationReconcilerto accept aSpiffeSocket stringfield instead ofJWTSVIDPathworkloadapi.Clientand callFetchJWTSVID(ctx, jwtsvid.Params{Audience: keycloakRealmIssuerURL})--jwt-svid-pathflag fromcmd/main.go; reuse or rename--verified-fetch-spiffe-socketjwt-svidemptyDir volume,spiffe-helper-configConfigMap, andconfigmap-spiffe-helper.yamltemplate from the chartspiffe.operatorAuth.spiffeHelpervalues blockRelated
:latestwhile this is addressed)