Pinniped Proxy is caching TokenCredentialRequests across clusters #5912
Assignees
Labels
component/pinniped-proxy
Issue related to kubeapps integration with pinniped-proxy
kind/bug
An issue that reports a defect in an existing feature
Comments
absoludity
added
the
kind/bug
absoludity
added
the
component/pinniped-proxy
absoludity
added a commit
that referenced
this issue
Jan 25, 2023
… url. (#5913) Signed-off-by: Michael Nelson <minelson@vmware.com> <!-- Before you open the request please review the following guidelines and tips to help it be more easily integrated: - Describe the scope of your change - i.e. what the change does. - Describe any known limitations with your change. - Please run any tests or examples that can exercise your modified code. Thank you for contributing! --> ### Description of the change Fixes #5912 by including the k8s server url in the cache key. <!-- Describe the scope of your change - i.e. what the change does. --> ### Benefits <!-- What benefits will be realized by the code change? --> Fixes an issue that was causing logouts when switching clusters. ### Possible drawbacks <!-- Describe any known limitations with your change --> ### Applicable issues <!-- Enter any applicable Issues here (You can reference an issue using #) --> - fixes #5912 ### Additional information <!-- If there's anything else that's important and relevant to your pull request, mention that information here.--> Signed-off-by: Michael Nelson <minelson@vmware.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
While investigating #5755 I've found another issue which contributes to the problem, in that our pinniped-proxy service is caching a little too heavily:
I'd setup the cache to cache the
TokenCredentialRequestresources - so when a request is received, we construct theTokenCredentialRequestready to exchange for a cert with pinniped, and if an identicalTokenCredentialRequestexists in the cache, that will be returned immediately instead.What I had not noticed is that the
TokenCredentialRequestdoes not mention or have any info about which cluster, so if the OIDC token is the same, the TCR will be the same for different clusters.This leads to the user being logged out when attempting to switch clusters.
To Reproduce
Steps to reproduce the behavior:
Exactly what I had described for #5755. I'll update the steps for that separate issue once this fix is in.
Expected behavior
The cache should not be used when switching clusters so that a cert for that cluster is fetched.
The text was updated successfully, but these errors were encountered: