Key-auth annotations to K8s service behaving inaccurately

[ashishkumar256]

Is there an existing issue for this?

• [X] I have searched the existing issues

Current Behavior

Below both curl request works -

=> curl <PROXY_IP>/factorial/4 -H apikey:first_complex_key < HTTP/1.1 200 OK < Content-Type: application/json < Content-Length: 17 < Connection: keep-alive < Server: Werkzeug/2.2.3 Python/3.7.10 < Date: Sat, 20 Apr 2024 08:58:44 GMT {"factorial":24}

=> curl <PROXY_IP>/factorial/4 -H apikey:second_complex_key < HTTP/1.1 200 OK < Content-Type: application/json < Content-Length: 17 < Connection: keep-alive < Server: Werkzeug/2.2.3 Python/3.7.10 < Date: Sat, 20 Apr 2024 08:58:44 GMT {"factorial":24}

Expected Behavior

apikey:second_complex_key must be authenticate /factorial only when second-key-auth is annotated with service demo-flask.

  annotations:
    konghq.com/plugins: "first-key-auth"
    # konghq.com/plugins: "first-key-auth, second-key-auth"

But annotating first-key-auth to service demo-flask, it enabled both api keys first_complex_key & second_complex_key working.

Steps To Reproduce

Followed Link: https://docs.konghq.com/kubernetes-ingress-controller/latest/get-started/key-authentication/

---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: demo-flask-int
  namespace: app
spec:
  ingressClassName: kong
  rules:
  - http:
      paths:
      - path: /factorial
        pathType: Prefix
        backend:
          service:
            name: demo-flask
            port:
              number: 5000

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-flask
  namespace: app
  labels:
   app: demo-flask
spec:
  replicas: 1
  selector:
    matchLabels:
      app: demo-flask
  template:
    metadata:
      labels:
        app: demo-flask
    spec:
      containers:
      - name: demo-flask
        image:  ashishkumar256/python-flask:health-check
        imagePullPolicy: Always
        ports:
        - containerPort: 5000
          protocol: TCP
          name: http

---
apiVersion: v1
kind: Service
metadata:
  name: demo-flask
  namespace: app
  labels:
    app: demo-flask
    app.kubernetes.io/component: apm
  annotations:
    konghq.com/plugins: "first-key-auth"
    # konghq.com/plugins: "first-key-auth, second-key-auth"
spec:
  type: ClusterIP
  ports:
    - port: 5000
      protocol: TCP
      targetPort: 5000
  selector:
    app: demo-flask

---
apiVersion: v1
kind: Secret
metadata:
  name: first-token
  labels:
      konghq.com/credential: key-auth
stringData:
  key: first_complex_key

---
apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
  name: first-consumer
  annotations:
    kubernetes.io/ingress.class: kong
username: first-consumer
credentials:
- first-token

---
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: first-key-auth
plugin: key-auth
config:
  key_names:
  - apikey

---
apiVersion: v1
kind: Secret
metadata:
  name: second-token
  labels:
      konghq.com/credential: key-auth
stringData:
  key: second_complex_key

---
apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
  name: second-consumer
  annotations:
    kubernetes.io/ingress.class: kong
username: second-consumer
credentials:
- second-token

---
apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
  name: second-key-auth
plugin: key-auth
config:
  key_names:
  - apikey

Kong Ingress Controller version

v3.1.3

Kubernetes version

Client Version: v1.28.2
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.29.3+k3s1

Anything else?

No response

[ashishkumar256]

I am requesting to look into this issue; it has been pending for 2 weeks. 

[randmonkey]

@ashishkumar256 As I confirmed with Kong gateway team, the key-auth plugin does not support only allowing part of the credentials but reject the others. The plugin does not support configuring consumers. So your "expected behavior" cannot be resolved in KIC currently. What is your requirement to configure the key-auth plugin to support only part of your configured credentials? We can think about some workarounds if you have any further requirement behind this.