Unable to link a KongPlugin JWT to a specific consumer

Hi there,
This is my first question/issue here so let me know if it misses some details.
We start to use Kong as an Ingress Controller but I have a small issue around the Kong plugin JWT

Here is what I have currently:

  • 2 separate apps on the same K8s cluster (separated by namespaces)
  • KongPlugin JWT on the Ingress for both apps
  • KongConsumer and KongCredential for each namespace
  • My routes are protected (401 when I access the route without any token)

My issue:

  • On both apps, The tokens are checked and authenticated with both consumers. It’s an issue as I want to validate the token only with the consumer corresponding to the current namespace (different signature key per namespace).

So what I tried to do is: Adding a consumerRef to my KongPlugins to specify which credentials to use when validating the token.
But it doesn’t work. The plugin is not attached to a specific consumer and no errors show up in the kong ingress controller.

Do we have limitations around this consumerRef property? Do I miss something on how to connect a plugin on a specific namespace to specific credentials?

Thank you for your help

Hello Romain.

Let see if I can help in some way.

I was able to used successfully the Kong JWT plugin on Kong Ingress Controller.

I will paste here the steps, do the steps as follow.

  1. Create the plugin [kubectl create -f plugin.yaml -n namespace]

apiVersion: configuration.konghq.com/v1
kind: KongPlugin
metadata:
name: jwt
plugin: jwt

  1. Create the Ingress [kubectl create -f ingress.yaml -n namespace]

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: linux
annotations:
kubernetes.io/ingress.class: nginx
plugins.konghq.com: jwt
spec:
tls:

  • hosts:
    • your_domain
      secretName: your_secret
      rules:
  • host: your_domain
    http:
    paths:
    • path: /
      backend:
      serviceName: linux
      servicePort: 3000
  1. Create a Consumer [kubectl create -f consumer.yaml -n namespace]

apiVersion: configuration.konghq.com/v1
kind: KongConsumer
metadata:
name: linux
username: linux-rocks

  1. Create a JWT

echo "
apiVersion: configuration.konghq.com/v1
kind: KongCredential
metadata:
name: credential-jwt
namespace: your_namespace
type: jwt
consumerRef: linux
config:
key: 9112c51cf5b34ce17f54324dd8099999
algorithm: HS256
rsa_public_key:
-----BEGIN PUBLIC KEY-----
afdafsfsdfs…afasfaf
-----END PUBLIC KEY-----
" | kubectl create -f -

All Kong resource definition can be verified as

kubectl get KongCredential | KongConsumer | KongPlugin -n namespace

Hope it helps!!

Hi @mativillagra, thanks for your answer and your time.

I have the same configuration and it works fine when you only have one KongPlugin JWT and one KongConsumer (with credentials).

What I try to do:
If I have a route A and a route B, I would like to apply a KongPlugin JWT jwta on route A and a KongPlugin JWT jwtb on route B. And I want jwta to be linked to a specific KongConsumer kca and jwtb linked to kcb.
This way I cannot access route A if I have a token signed with credentials linked to KongConsumer kcb.

Current Behaviour:

  • If I apply 2 different plugins JWT, then I don’t know how to specify that jwta should check the token signature ONLY with kca credentials and that jwtb should check the token signature ONLY with kcb credentials. So now I can access route A with a token signed with a private RS256 key corresponding to kcb credentials => Unwanted behaviour.

If I try to add a consumerRef property in the KongPlugin JWT definition then my Kong Ingress Controller indicates that consumerRef is not available for this type of Plugin.
Here is the documentation I followed: https://github.com/Kong/kubernetes-ingress-controller/blob/master/docs/custom-resources.md#kongplugin.

Kong image version: kong:0.14.1-centos

This is correct.
It is not possible in Kong to limit a JWT plugin execution based on a consumer, since it’s the plugin which determines which consumer is present.

What you’re looking for is ACL plugin in Kong:

You can associate each consumer with an ACL group, and then allow access to the consumer of a particular group based on the namespace.

Hope that helps.