You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unlike evaluators' runtime cache, the caching of API key Secrets is virtually unlimited (or limited by the amount of resources available to the process only.) This is not ideal. Instead, Authorino should:
provide a way to limit the number of API keys that is cached for a given AuthConfig API key evaluator; and/or
provide a way to not cache in-memory API keys at all, by
a. supporting external cache storage, or
b. implementing Kubernetes Secret lookup at request-time.
2a is consistent with the overall plan for caching in Authorino started mainly with #239 and #247. On the other hand, it violates the practice/principle of keeping these secrets internal in the cluster.
2b might be tricky as the API key cannot be used for lookup; rather it is the value stored inside the secret. Perhaps Authorino API keys could evolve to App ID/App secret for this?
The text was updated successfully, but these errors were encountered:
Unlike evaluators' runtime cache, the caching of API key Secrets is virtually unlimited (or limited by the amount of resources available to the process only.) This is not ideal. Instead, Authorino should:
a. supporting external cache storage, or
b. implementing Kubernetes Secret lookup at request-time.
2a is consistent with the overall plan for caching in Authorino started mainly with #239 and #247. On the other hand, it violates the practice/principle of keeping these secrets internal in the cluster.
2b might be tricky as the API key cannot be used for lookup; rather it is the value stored inside the secret. Perhaps Authorino API keys could evolve to App ID/App secret for this?
The text was updated successfully, but these errors were encountered: