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
Point number 1 above helps with avoiding the strict constraint on the name and implications such as in some case not being able to use the same Kubernetes Secret resource that stores the API key for other purposes or for different AuthConfigs (with different API key secret values).
And, by supporting multiple valid key names (point number 2 above), that Authorino would try in order when reading the secret value of the API key (stopping when the first valid key name is found within the Kubernetes Secret), this change would also make it easier to implement key rotation, which otherwise could only be done by creating a new Kubernetes Secret.
The text was updated successfully, but these errors were encountered:
API Key values currently need to be stored in a key necessarily named as
api_key
within the Kubernetes Secret resource. It would be nice:E.g.:
So a Kubernetes as such could be defined:
Point number 1 above helps with avoiding the strict constraint on the name and implications such as in some case not being able to use the same Kubernetes Secret resource that stores the API key for other purposes or for different AuthConfigs (with different API key secret values).
And, by supporting multiple valid key names (point number 2 above), that Authorino would try in order when reading the secret value of the API key (stopping when the first valid key name is found within the Kubernetes Secret), this change would also make it easier to implement key rotation, which otherwise could only be done by creating a new Kubernetes Secret.
The text was updated successfully, but these errors were encountered: