Add cache-backed CherryPy session store to rest_cherrypy for shared salt-api sessions#69245
Open
ggiesen wants to merge 2 commits into
Open
Add cache-backed CherryPy session store to rest_cherrypy for shared salt-api sessions#69245ggiesen wants to merge 2 commits into
ggiesen wants to merge 2 commits into
Conversation
The X-Auth-Token doubles as the CherryPy session id, and the auth gate checks the CherryPy session in addition to the Salt token. With CherryPy's default in-RAM session store the session lives only on the worker that handled /login, so a client whose later requests reach a different worker gets a 401 even though the Salt token is valid and already shared via the master token cache. This breaks salt-api behind a load balancer and on multi-member master clusters unless sticky sessions are configured. Add a SaltCacheSession backend (opt-in via "session_store: cache") that stores sessions in the master's configured salt.cache instead, so any worker can resolve them. The driver follows the "cache" setting (localfs by default), so a master cluster with a shared cachedir needs nothing extra; deployments without shared storage can point cache at redis or etcd3. Route the /events and /websocket out-of-band token lookup through a backend-agnostic helper, since they previously assumed the RAM session's internal dict. Adds unit tests for the backend lifecycle, cross-instance resolution, expiry, cleanup, the lookup helper, and the config wiring.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Adds a
session_store: cacheoption to therest_cherrypynetapi. When set, CherryPy sessions are stored in the master's configuredsalt.cacheinstead of CherryPy's default per-workerRamSession, so salt-api sessions are shared across multiple salt-api workers and master-cluster members.The driver follows the
cachesetting (localfsby default), so a master cluster with a sharedcachedirneeds nothing extra; deployments without shared storage can pointcacheat a networked driver such asredisoretcd3. The default remainsRamSession, so existing deployments are unaffected.What issues does this PR fix or reference?
References #68999, #38139
Previous Behavior
The X-Auth-Token doubles as the CherryPy session id, and the auth gate checks the CherryPy session in addition to the Salt token. With the default in-RAM session store the session lives only on the worker that handled
/login, so a client whose later requests reach a different worker is rejected with a401, even though the Salt token is valid and already shared via the master token cache. This breaks salt-api behind a load balancer and on multi-member master clusters unless sticky sessions are configured.New Behavior
With
session_store: cache, the session is written to Salt's shared cache, so any worker can resolve it and authentication succeeds regardless of which worker handles the request.The
/eventsand/websocketout-of-band token lookup (which previously read CherryPy's RAM session dict directly) now goes through a backend-agnostic helper, so those endpoints work with either backend.This was validated against a running master with multiple salt-api workers sharing a
cachedir: a token issued by one worker authenticates against another only withsession_store: cache; the defaultRamSessionrejects it with a401. New unit tests cover the backend lifecycle, cross-instance resolution, expiry, cleanup, the lookup helper (both backends), and the config wiring.Merge requirements satisfied?
[NOTICE] Bug fixes or features added to Salt require tests.
Commits signed with GPG?
No