Use a controller to sync remote jwks store to ConfigMaps

[dmitri-d]

Description

Use a controller to sync jwks store internal state to ConfigMaps. The reasons for this change are to allow for retries on failed ConfigMap udpates/deletes, and to reset changes to ConfigMaps made outside of our controller loop (e.g. inadvertent ConfigMap removal by a user, etc).

ConfigMap syncer is still being used to initialize jwks store on launch; it's value (at least atm) is limited though -- it allows us to recover from inadvertent changes to ConfigMaps used to store jwks' when the keystore isn't available in the store (e.g. after controller restart, with remote jwks source not responding).

Change Type

/kind cleanup

Changelog

NONE

Additional Notes

[Copilot]

Pull request overview

This PR moves JWKS persistence from an ad-hoc write path inside the store to dedicated controllers: one watching policy changes to drive JWKS fetches, and one syncing the JWKS cache to ConfigMaps with retries and reconciliation. This aligns persistence with controller patterns, enabling retries, self-healing on external CM changes, and clearer separation of concerns.

• Introduces a Policy controller that emits JwksSource changes to the store.
• Adds a ConfigMap controller that reconciles JWKS state into labeled ConfigMaps and handles deletes.
• Refactors JWKS cache/fetcher/store for concurrency and controller-driven updates; replaces controller-runtime logging with the internal logging package.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 11 comments.

Show a summary per file

File	Description
internal/kgateway/jwks/jwks_store.go	Refactors store to consume JwksSource events, track CM name-to-URI mapping, expose SubscribeToUpdates for CM controller, and use internal logging.
internal/kgateway/jwks/jwks_fetcher.go	Replaces bulk UpdateJwksSources with AddOrUpdateKeyset/RemoveKeyset; changes cache update semantics and subscriber notifications.
internal/kgateway/jwks/jwks_cache.go	Adds locking to cache and a GetJwks helper; changes add semantics to always write.
internal/kgateway/jwks/config_map_syncer.go	Simplifies to direct client use; defines label constants/helpers, loader, and serialization helper.
internal/kgateway/controller/start.go	Wires up new Policy and ConfigMap controllers; constructs the store with channels.
internal/kgateway/agentjwksstore/policy_controller.go	New controller emitting JwksSource changes derived from AgentgatewayPolicy.
internal/kgateway/agentjwksstore/cm_controller.go	New controller reconciling JWKS to ConfigMaps and reacting to store updates with retries.
internal/kgateway/agentjwksstore/jwks_store_controller.go	Removes old singleton-based JWKS store controller.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

You can also share your feedback on Copilot code review for a chance to win a $100 gift card. Take the survey.

[dmitri-d]

Not sure if this decoupling makes much sense; instead of using a channel, I could add a function to add events directly to the event queue and call it from JwksStore?

[lgadban]

Is there an overall design doc on this feature? No problem if not, just wondering if there's a logical entrypoint for a new reviewer

[npolshakova]

So if multiple policies or backends reference the same JWKS URI, do we skip re-creating the config map or do we create a configmap per policy?