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:

1. to be able to customise the name of this key within the secret; perhaps
2. making possible to provide multiple name options.

E.g.:

apiVersion: authorino.kuadrant.io/v1beta1
kind: AuthConfig
metadata:
  name: my-api-protection
spec:
  hosts: [...]
  identity:
  - name: friends
    apiKey:
      selector:
        matchLabels:
          group: friends
      keySelectors:
      - first-api-key-value
      - second-api-key-value
    credentials:
      in: authorization_header
      keySelector: APIKEY

So a Kubernetes as such could be defined:

apiVersion: v1
kind: Secret
metadata:
  name: api-key-1
  labels:
    authorino.kuadrant.io/managed-by: authorino
    group: friends
stringData:
  first-api-key-value: secret
  second-api-key-value: other-secret
type: Opaque

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.