šŸ¤ Permit.io AI Access Control is Launching Live in Product Hunt šŸ¤
Permit logo
Home/Blog/

No-code permissions with Kong and Permit.io

Kong is a popular API gateway, but managing access to its APIs and services is hard - especially when required advanced permissions models like RBAC/ABAC/ReBAC
No-code permissions with Kong and Permit.io
Shaul Kremer

Shaul Kremer

|
  • Share:

Introduction

Kong is one of the most popular API gateways out there; but managing access to API and services behind it can be quite a bit of work especially as the application evolves requiring more and more advanced permissions models (RBAC, ABAC, ReBAC, ā€¦)Ā 
Enter Permit - a full stack permissions service, that can empower you to never have to build permissions again.
With a recent update - Permit can now seamlessly integrate with Kong Gateway. And you can add permissions to your API within minutes without having to write a single line of code (unless you want to ;-) ).

If you have Kong Gateway properly configured to relay requests from your users to your backend, you can easily use Permit.io to authorize requests as they go in, with a real time administration layer that has a nice user interface for everybody in your organization but is policy-as-code behind the scenes.

What is Authorization?

Authorization means answering the question:

CanĀ some_user doĀ some_action onĀ some_resource?

The simplest way to implement permissions (that is, other than dummy permissions such as ā€œallow everyone who is authenticatedā€) is called Role-Based Access Control, or RBAC. In RBAC, each user is assigned one or more roles, and roles can have permissions to performĀ actions on classes of resources. For example, in a policy, we say that:

  • RoleĀ admin canĀ read,Ā write andĀ delete onĀ repository
  • RoleĀ power_userĀ canĀ read andĀ write onĀ repository
  • RoleĀ viewerĀ canĀ read onĀ repository

And then we define the following facts:

  • UserĀ annie@example.com has role admin
  • UserĀ bill@example.com has role power_user
  • User carol@example.com has role viewer

Not shown is that users may have more than one role, in which case they get the sum of their rolesā€™ permissions.

Then, letā€™s say bill wants to write to a repo, weā€™ll ask the question:

  • CanĀ bill@example.comĀ performĀ writeĀ on repository?

SinceĀ bill@example.comĀ has the roleĀ power_userĀ which canĀ write onĀ repository, the answer is yes, this is allowed.

Though not shown in this tutorial, Permit.io also supports ABAC.

How This Applies to Kong-Based Applications

Youā€™re probably wondering how this applies to HTTP requests, which is what Kong sees. To integrate Permit.io, which works with resources and actions, with Kong, which works with HTTP requests built from paths and methods, we use the methods as actions and translate request paths into resource names. These are the defaults (which obviously you can customize):

Path regex

Resulting resource

Example path

Example resource

/([^/]+).*

[capture group 1]

/repository

repository

/v\d+/([^/]+).*

[capture group 1]

/v2/repository

repository

/

ā€œindexā€

/

index

For example, using the default translation table, consider the following request:

POST /v2/repository

Authorization: Bearer [bearer token for annie@example.com]

This will be translated into:

Can annie@example.com do post on repository?

How to Integrate Permit.io with your Kong-Based Application

Since Permit.io uses OPA internally, you can use the standard Kong OPA plugin.

This guide assumes that you already have Kong configured, and your authentication is done through Kong.

First, youā€™ll need to set up your Policy Decision Point, or PDP, next to your Kong Gateway. In the Permit.io architecture, the PDP is a small container that makes authorization decisions. You configure it through Permit.ioā€™s cloud service, but once running itā€™s completely independent (so it keeps running even if disconnected from the Internet) and can make decisions extremely quickly, on the order of 1-5 ms.

To run the PDP, you can use the following command:

docker run \
ā Ā Ā -p 7766:7000 \
ā Ā Ā --env PDP_API_KEY=your_api_key \
ā   --env PDP_KONG_INTEGRATION=true \
ā   permitio/pdp-v2:latest

To get your API key, go to theĀ Permit.io administration interface and click ā€œCopy SDK secret keyā€ in the user menu:

image2.png

Once running, you can configure your runtime instance to authorize requests through the PDP. In your Kong Route configuration, add a plugin:

image3.png

In the plugin configuration, set the following values:

  • ā€œConfig.include Consumer In Opa Inputā€ should be checked
  • ā€œConfig.Opa Hostā€ = The PDPā€™s IP address
  • ā€œConfig.Opa Pathā€ = ā€œ/kongā€
  • ā€œConfig.Opa Portā€ = 7766
  • ā€œConfig.Opa Protocolā€ = ā€œhttpā€
image1.png

Obviously if you changed any of these values in the PDP configuration, theyā€™ll need to be changed to match in Kongā€™s configuration as well.

If you need to customize the resource translation table, you can use the following format (shown here is the default table):

[
	["/v\\d+/([^/]+).*", 0],
	["/([^/]+).*", 0],
	["/", "index"]
]

Entries are processed in order. In each entry, the first value is a regular expression to match, while the second is the resource name. For the resource name, a string is used as is, while an integer refers to a capture group in the regular expression.

To override the default table, simply mount the tableā€™s json file atĀ /config/kong_routes.json. The docker run command would be:

docker run \
  -p 7766:7000 \
  --env PDP_API_KEY=your_api_key \
  --env PDP_KONG_INTEGRATION=true \
  -v /path/to/your/kong_routes.json:/config/kong_routes.json \
  permitio/pdp-v2:latest

You should now see your http requests being authorized in the PDPā€™s log, and in the decision logs in Permit.ioā€™s cloud interface. For any denied requests, Kong will return 403s.

Summary

As you see, Permit.io makes it easy to add permissions to Kong-based applications. You can easily configure Kong Gateway to use Permitā€™s powerful permission engine to decide whether requests are allowed, and empower non technical people in your organization to manage permissions themselves.

Written by

Shaul Kremer

Shaul Kremer

Chief Architect at Permit.io. Shaul has been coding since the age of 8 and is a total computer nerd who always enjoys writing Assembly code. 8200 (IDF Intelligence) alumnus, and previously Chief Architect & first employee at Claroty, a cybersecurity unicorn.

Test in minutes, go to prod in days.

Get Started Now

Join our Community

2301 Members

Get support from our experts, Learn from fellow devs

Join Permit's Slack