Way of allow/disallow specific route of a service by consumer

Hello Kong community,

We use Kong api-gw community edition and it works very well.
Recently we face a problematic, and I will be curious of what is the preferred way to answer it.

We have an API already deployed in production and already exposed to exernal. Let’s call it “totoapi”.

We have different consumers for this API. For the moment every path/subpath of this API are exposed regardless of the consumer.

But in the future we want to add endpoints/paths which should be only accessible from one specific consumer.

To sum up :

api.corp.com/totoapi

  • consumer1 should access to /totoapi/*
  • consumer2 should access to /totoapi/* and not access /totoapi/endpointspecific1

what would be the preferred way to do it?

I was thinking of multiple way to do it, creating multiple routes sections in the same service listing all the path, or maybe adding a specific plugin at the consumer level ?

Any hints appreciated.

Depends on how you want to do it and how many consumer you have.

One way to do it is to create two route objects under the same service, enable authentication (let’s say key-auth) on the service and then enable ACL plugin on second route to deny access from consumer2.

1st route: /totoapi/*
2nd route: /totoapi/endpointspecific1

Ok thanks you ; something like this work :

services:
- name: api
  url: http://127.0.0.1:5000/
  plugins:
   - name: key-auth
  routes:
  - name: api-routes-1
    paths:
    - /api/
    strip_path: false
    plugins:
     - name: acl
       config:
         allow:
         - group1
         - group2
  - name: api-routes2
    paths:
    - /api/b/
    strip_path: false
    plugins:
     - name: acl
       config:
         deny:
         - group2

consumers:
- username: myuser
  keyauth_credentials:
  - key: mykey
- username: myuser2
  keyauth_credentials:
  - key: mykey2

acls:
- consumer: myuser
  group: group1
- consumer: myuser2
  group: group2

This looks relatively clear.

Well it’s not exactly working the way I wanted actually.

The problem with the snippet I pasted is if I added another group/consumer which is not explicitly denied in the deny stanza of the endpoint specific it will be allowed.

Imagine I had many consumers group and the configuration can be completely unreadable and error prone…

ACL can be used to deny or to allow certain groups.

If you have more groups you want to deny, it is probably easier to use allow list.