このページは、まだ日本語ではご利用いただけません。翻訳中です。
旧バージョンのドキュメントを参照しています。 最新のドキュメントはこちらをご参照ください。
RBAC Examples
This chapter aims to provide a step-by-step tutorial on how to set up RBAC and see it in action, with an end-to-end use case. The chosen use case demonstrates how RBAC with workspaces can be coupled to achieve a flexible organization of teams and users in complex hierarchies.
Use case
For the sake of example, let’s say a given company has a Kong Gateway cluster to be shared with two teams: teamA and teamB. While the Kong clusters are shared among these teams, they want to be able to segment their entities in such a way that management of entities in one team doesn’t disrupt operation in some other team. As shown in the Workspaces Page, such a use case is possible with workspaces. On top of workspaces, though, each team wants to enforce access control over their Workspace, which is possible with RBAC.
To sum up, workspaces and RBAC are complementary: workspaces provide segmentation of Admin API entities, while RBAC provides access control.
Note: The example responses in this guide are often excerpts of full responses, focusing on the most relevant part of the response, as the full response can be very long.
Bootstrapping the first RBAC user
The first RBAC user is called the super admin.
Kong recommends that you create a super admin user before actually enforcing RBAC and restarting Kong Gateway with RBAC enabled.
It’s possible to create the first super admin at installation time. If you chose this option, skip to Enforcing RBAC.
Kong Gateway ships with a set of default RBAC roles: super-admin
,
the admin
, and read-only
, which makes the task of creating a super admin user easy:
-
Create the RBAC user, named
super-admin
:curl -i -X POST http://localhost:8001/rbac/users \ -H 'Kong-Admin-Token:secureadmintoken' \ --data name=super-admin \ --data user_token=exampletoken
Response:
{ "user_token": "M8J5A88xKXa7FNKsMbgLMjkm6zI2anOY", "id": "da80838d-49f8-40f6-b673-6fff3e2c305b", "enabled": true, "created_at": 1531009435, "updated_at": 1531009435, "name": "super-admin" }
As the
super-admin
username coincides with an existingsuper-admin
role, it gets automatically added to thesuper-admin
role. -
Confirm using the following command:
curl -i -X GET http://localhost:8001/rbac/users/super-admin/roles
Response:
{ "roles": [ { "comment": "Full access to all endpoints, across all workspaces", "created_at": 1531009724, "updated_at": 1531009724, "name": "super-admin", "id": "b924ac91-e83f-4136-a5a4-4a7ff92594a8" } ], "user": { "created_at": 1531009435, "updated_at": 1531009724, "id": "e6897cc0-0c34-4a9c-9f0b-cc65b4f04d68", "name": "super-admin", "enabled": true, "user_token": "vajeOlkybsn0q0VD9qw9B3nHYOErgY7b8" } }
Enforcing RBAC
With the super-admin
user created, the Kong admin can now restart
Kong Gateway with RBAC enforced:
KONG_ENFORCE_RBAC=on kong restart
This is one of the possible ways of enforcing RBAC and restarting Kong. Another option is editing the Kong Gateway configuration file and restarting.
Before moving on, note that this guide uses the super admin user, but you could move on without RBAC enabled, and have the Kong admin set up the whole RBAC hierarchy.
However, we want to stress the fact that RBAC is powerful enough to allow a flexible separation of tasks. To summarize:
- Kong admin: This user has physical access to Kong infrastructure. Their task is to bootstrap the Kong cluster as well as its configuration, including initial RBAC users.
- RBAC super admin: Created by the Kong admin, has the role of managing RBAC users, roles, and permissions. While this could all be done by the Kong admin, we recommend separating the responsibility for better security.
Super admin creates the team workspaces
The super admin now sets up two teams: teamA and teamB, creating one workspace for each and one admin for each.
-
Create the workspace for
teamA
:curl -i -X POST http://localhost:8001/workspaces \ --data name=teamA \ -H 'Kong-Admin-Token:vajeOlkbsn0q0VD9qw9B3nHYOErgY7b8'
Response:
{ "name": "teamA", "created_at": 1531014100, "updated_at": 1531014100, "id": "1412f3a6-4d9b-4b9d-964e-60d8d63a9d46" }
-
Create the workspace for
teamB
:curl -i -X POST http://localhost:8001/workspaces \ --data name=teamB \ -H 'Kong-Admin-Token:vajeOlkbsn0q0VD9qw9B3nHYOErgY7b8'
Response:
{ "name": "teamB", "created_at": 1531014143, "updated_at": 1531014143, "id": "7dee8c56-c6db-4125-b87a-b508baa33c66" }
Super admin creates one admin for each team
-
Create an admin for
teamA
:curl -i -X POST http://localhost:8001/teamA/rbac/users \ --data name=adminA \ --data user_token=exampletokenA \ -H 'Kong-Admin-Token:vajeOlkbsn0q0VD9qw9B3nHYOErgY7b8'
Response:
{ "user_token": "qv1VLIpl8kHj7lC1QOKwRdCMXanqEDii", "id": "4d315ff9-8c1a-4844-9ea2-21b16204a154", "enabled": true, "created_at": 1531015165, "updated_at": 1531015165, "name": "adminA" }
-
Create an admin for
teamB
:curl -i -X POST http://localhost:8001/teamB/rbac/users \ --data name=adminB \ --data user_token=exampletokenB \ -H 'Kong-Admin-Token:vajeOlkbsn0q0VD9qw9B3nHYOErgY7b8'
Response:
{ "user_token": "IX5vHVgYqM40tLcctdmzRtHyfxB4ToYv", "id": "49641fc0-8c9d-4507-bc7a-2acac8f2903a", "enabled": true, "created_at": 1531015221, "updated_at": 1531015221, "name": "adminB" }
-
Both of the teams now have one admin and each admin can only be seen in their corresponding workspace. To verify, run:
curl -i -X GET http://localhost:8001/teamA/rbac/users \ -H 'Kong-Admin-Token:vajeOlkbsn0q0VD9qw9B3nHYOErgY7b8'
Response:
{ "total": 1, "data": [ { "created_at": 1531014784, "updated_at": 1531014784, "id": "1faaacd1-709f-4762-8c3e-79f268ec8faf", "name": "adminA", "enabled": true, "user_token": "n5bhjgv0speXp4N7rSUzUj8PGnl3F5eG" } ] }
Similarly, workspace
teamB
only shows its own admin:curl -i -X GET http://localhost:8001/teamB/rbac/users \ -H 'Kong-Admin-Token:vajeOlkbsn0q0VD9qw9B3nHYOErgY7b8'
Response:
{ "total": 1, "data": [ { "created_at": 1531014805, "updated_at": 1531014805, "id": "3a829408-c1ee-4764-8222-2d280a5de441", "name": "adminB", "enabled": true, "user_token": "C8b6kTTN10JFyU63ORjmCQwVbvK4maeq" } ] }
Super admin creates admin roles for teams
The super admin is now done creating RBAC admin users for each team. The next task is to create admin roles that will effectively grant permissions to admin users.
The admin role must have access to all of the Admin API, restricted to its workspace.
-
Set up the admin role, paying close attention to the request parameters:
curl -i -X POST http://localhost:8001/teamA/rbac/roles/ \ --data name=admin \ -H 'Kong-Admin-Token:vajeOlkbsn0q0VD9qw9B3nHYOErgY7b8'
Response:
{ "created_at": 1531016728, "updated_at": 1531016728, "id": "d40e61ab-8dad-4ef2-a48b-d11379f7b8d1", "name": "admin" }
-
Create role endpoint permissions:
curl -i -X POST http://localhost:8001/teamA/rbac/roles/admin/endpoints/ \ --data 'endpoint=*' \ --data 'workspace=teamA' \ --data 'actions=*' \ -H 'Kong-Admin-Token:vajeOlkbsn0q0VD9qw9B3nHYOErgY7b8'
Response:
{ "total": 1, "data": [ { "endpoint": "*", "created_at": 1531017322, "updated_at": 1531017322, "role_id": "d40e61ab-8dad-4ef2-a48b-d11379f7b8d1", "actions": [ "delete", "create", "update", "read" ], "negative": false, "workspace": "teamA" } ] }
-
Add the
adminA
user to the admin role in their workspace:curl -i -X POST http://localhost:8001/teamA/rbac/users/adminA/roles/ \ --data roles=admin \ -H 'Kong-Admin-Token:vajeOlkbsn0q0VD9qw9B3nHYOErgY7b8'
Response:
{ "roles": [ { "created_at": 1685551877, "updated_at": 1531014805, "id": "42809ada-650c-4575-b0a0-d464a64ffb70", "name": "admin", "ws_id": "9dc7adbb-9b64-4121-bf76-653cf5871bc2" } ], "user": { "comment": "null", "created_at": 1685552809, "updated_at": 1531014805, "enabled": true, "id": "bca4e390-fbbf-4a46-b55d-f4642efc14bb", "name": "adminA", "user_token": "$2b$09$oLyKTIDuKriPZ.SD5wYtxeMclGYNDn4udJkQG0NGx/Aq3j9j/tWsa", "user_token_ident": "0ebb5" } }
-
Team A’s admin user is now able to manage their team. To validate that, let’s try to list RBAC users in Team B using Team A’s admin user token:
curl -i -X GET http://localhost:8001/teamB/rbac/users \ -H 'Kong-Admin-Token:exampletokenA'
Notice that you can’t access the endpoint:
{ "message": "Invalid RBAC credentials" }
-
Now try listing RBAC users in Team A’s workspace:
curl -i -X GET http://localhost:8001/teamA/rbac/users \ -H 'Kong-Admin-Token:exampletokenA'
Response:
{ "total": 1, "data": [ { "created_at": 1531014784, "updated_at": 1531014784, "id": "1faaacd1-709f-4762-8c3e-79f268ec8faf", "name": "adminA", "enabled": true, "user_token": "n5bhjgv0speXp4N7rSUzUj8PGnl3F5eG" } ] }
If the same procedure is repeated for Team B, they will end up with a similar set up, with an admin role and an admin user, both restricted to the team’s workspace.
The super admin’s job is now done. Individual team admins are now able to set up their team’s users and entities!
Team admins create regular users
From this point on, team admins are able to drive the process. The next step is to create team users, such as engineers that are part of Team A or B. Let’s go ahead and do that, using Admin A’s user token.
Before regular users can be created, a role needs to be available for them. This role needs to have permissions to all of the Admin API endpoints, except RBAC and workspaces. Regular users don’t need access to these endpoints, and if they do, the admin can grant them individually.
Create the users role
-
As a team admin, create the regular
users
role:curl -i -X POST http://localhost:8001/teamA/rbac/roles/ \ --data name=users \ -H 'Kong-Admin-Token:exampletokenA'
Response:
{ "created_at": 1531020346, "updated_at": 1531020346, "id": "9846b92c-6820-4741-ac31-425b3d6abc5b", "name": "users" }
-
Create a permission for all of the Admin API, which requires a positive permission on
\*
:curl -i -X POST http://localhost:8001/teamA/rbac/roles/users/endpoints/ \ --data 'endpoint=*' \ --data 'workspace=teamA' \ --data 'actions=*' \ -H 'Kong-Admin-Token:exampletokenA'
Response:
{ "endpoint": "*", "created_at": 1531020573, "updated_at": 1531020573, "role_id": "9846b92c-6820-4741-ac31-425b3d6abc5b", "actions": [ "delete", "create", "update", "read" ], "negative": false, "workspace": "teamA" }
-
Then, filter out RBAC and workspaces with negative permissions:
Filter out RBAC endpoints:
curl -i -X POST http://localhost:8001/teamA/rbac/roles/users/endpoints/ \ --data 'endpoint=/rbac/*' \ --data 'workspace=teamA' \ --data 'actions=*' \ --data 'negative=true' \ -H 'Kong-Admin-Token:exampletokenA'
Response:
{ "endpoint": "/rbac/*", "created_at": 1531020744, "updated_at": 1531020744, "role_id": "9846b92c-6820-4741-ac31-425b3d6abc5b", "actions": [ "delete", "create", "update", "read" ], "negative": true, "workspace": "teamA" }
Filter out workspaces endpoints:
curl -i -X POST http://localhost:8001/teamA/rbac/roles/users/endpoints/ \ --data 'endpoint=/workspaces/*' \ --data 'workspace=teamA' \ --data 'actions=*' \ --data 'negative=true' \ -H 'Kong-Admin-Token:exampletokenA'
Response:
{ "endpoint": "/workspaces/*", "created_at": 1531020778, "updated_at": 1531020778, "role_id": "9846b92c-6820-4741-ac31-425b3d6abc5b", "actions": [ "delete", "create", "update", "read" ], "negative": true, "workspace": "teamA" }
Important: As explained in the Wildcards in Permissions section, the meaning of
*
is not the same as generic globbing. As such,/rbac/*
or/workspaces/*
do not match all of the RBAC and Workspaces endpoints. For example, to cover all of the RBAC API, you would have to define permissions for the following endpoints:
/rbac/*
/rbac/*/*
/rbac/*/*/*
/rbac/*/*/*/*
/rbac/*/*/*/*/*
Add members to a team
Team A just got two new members: foogineer
and bargineer
. Admin A
welcomes them to the team by creating RBAC users for them and giving them
access to Kong.
-
Create
foogineer
:curl -i -X POST http://localhost:8001/teamA/rbac/users \ --data name=foogineer \ --data user_token=exampletokenfoo \ -H 'Kong-Admin-Token:exampletokenA'
Response:
{ "created_at": 1531019797, "updated_at": 1531019797, "id": "0b4111da-2827-4767-8651-a327f7a559e9", "name": "foogineer", "enabled": true, "user_token": "dNeYvYAwvjOJdoReVJZXF8vLBXQioKkI" }
-
Add
foogineer
to theusers
role:curl -i -X POST http://localhost:8001/teamA/rbac/users/foogineer/roles \ --data roles=users \ -H 'Kong-Admin-Token:exampletokenA'
Response:
{ "roles": [ { "comment": "Default user role generated for foogineer", "created_at": 1531019797, "updated_at": 1531019797, "id": "125c4212-b882-432d-a323-9cbe38b1d0df", "name": "foogineer" }, { "created_at": 1531020346, "updated_at": 1531020346, "id": "9846b92c-6820-4741-ac31-425b3d6abc5b", "name": "users" } ], "user": { "created_at": 1531019797, "updated_at": 1531019797, "id": "0b4111da-2827-4767-8651-a327f7a559e9", "name": "foogineer", "enabled": true, "user_token": "dNeYvYAwvjOJdoReVJZXF8vLBXQioKkI" } }
-
Create
bargineer
:curl -i -X POST http://localhost:8001/teamA/rbac/users \ --data name=bargineer \ --data user_token=exampletokenbar \ -H 'Kong-Admin-Token:exampletokenA'
Response:
{ "created_at": 1531019797, "updated_at": 1531019797, "id": "e8926efa-11b4-43a3-9a28-767c05d8e9d8", "name": "bargineer", "enabled": true, "user_token": "dNeYvYAwvjOJdoReVJZXF8vLBXQioKkI" }
-
Add
bargineer
to theusers
role:curl -i -X POST http://localhost:8001/teamA/rbac/users/foogineer/roles \ --data roles=users \ -H 'Kong-Admin-Token:exampletokenA'
Response:
{ "roles": [ { "comment": "Default user role generated for bargineer", "created_at": 1531019797, "updated_at": 1531019797, "id": "125c4212-b882-432d-a323-9cbe38b1d0df", "name": "bargineer" }, { "created_at": 1531020346, "updated_at": 1531020346, "id": "9846b92c-6820-4741-ac31-425b3d6abc5b", "name": "users" } ], "user": { "created_at": 1531019797, "updated_at": 1531019797, "id": "e8926efa-11b4-43a3-9a28-767c05d8e9d8", "name": "bargineer", "enabled": true, "user_token": "dNeYvYAwvjOJdoReVJZXF8vLBXQioKkI" } }
Regular team users use their tokens
foogineer
and bargineer
have gotten their RBAC user tokens
from their Team A admin, and are now allowed to explore Kong Gateway within the
confines of their Team A workspace. Let’s validate this.
-
As
foogineer
, try listing workspaces:curl -i -X GET http://localhost:8001/teamA/workspaces/ \ -H 'Kong-Admin-Token:dNeYvYAwvjOJdoReVJZXF8vLBXQioKkI'
Response:
{ "message": "foogineer, you do not have permissions to read this resource" }
-
Enable some plugin, for example
key-auth
:curl -i -X POST http://localhost:8001/teamA/plugins \ --data name=key-auth \ -H 'Kong-Admin-Token:dNeYvYAwvjOJdoReVJZXF8vLBXQioKkI'
Response:
{ "created_at": 1531021732, "updated_at": 1531021732, "config": { "key_in_body": false, "run_on_preflight": true, "anonymous": "", "hide_credentials": false, "key_names": [ "apikey" ] }, "id": "cdc85ef0-804b-4f92-aafd-3ff58512e445", "enabled": true, "name": "key-auth" }
-
List currently enabled plugins:
curl -i -X GET http://localhost:8001/teamA/plugins \ -H 'Kong-Admin-Token:dNeYvYAwvjOJdoReVJZXF8vLBXQioKkI'
Response:
{ "total": 1, "data": [ { "created_at": 1531021732, "updated_at": 1531021732, "config": { "key_in_body": false, "run_on_preflight": true, "anonymous": "", "hide_credentials": false, "key_names": [ "apikey" ] }, "id": "cdc85ef0-804b-4f92-aafd-3ff58512e445", "name": "key-auth", "enabled": true } ] }
This ends the use case tutorial, which demonstrates the power of RBAC and workspaces with a real-world scenario.
Entity-level RBAC
In addition to endpoint permissions, RBAC in Kong Gateway supports entity-level permissions, meaning that particular entities, identified by their unique ID, can be allowed or disallowed access in a role.
RBAC is enforced with the enforce_rbac
configuration directive, or with its KONG_ENFORCE_RBAC
environment variable
counterpart. The directive is an enum, with the following possible values:
-
on
: Applies endpoint-levelaccess control -
entity
: Applies only Entity-level access control -
both
: Applies both Endpoint and Entity level access control -
off
: disables RBAC enforcement
If set to entity
or both
, Kong enforces entity-level
access control. However, as with endpoint-level access control, permissions
must be bootstrapped before enforcement is enabled.
Creating entity-level permissions
Team A just got one new, temporary, team member: qux
. Admin A, the admin of
Team A, has already created the qux
RBAC user.
Next, the admin needs to limit the access that qux
has over entities in the Team A workspace,
giving the user read access to only a couple of entities. For that, the admin needs
to use entity-level RBAC.
-
As Admin A, create a role for the temporary user
qux
:curl -i -X POST http://localhost:8001/teamA/rbac/roles \ --data name=qux-role \ -H Kong-Admin-Token:exampletokenA
Response:
{ "name": "qux-role", "created_at": 1531065975, "updated_at": 1531065975, "id": "ffe93269-7993-4308-965e-0286d0bc87b9" }
-
Grant the user read access to two entities: a service and a route. Reference each entity by its ID:
For example, using
service1
with the ID3ed24101-19a7-4a0b-a10f-2f47bcd4ff43
androute1
with the IDd25afc46-dc59-48b2-b04f-d3ebe19f6d4b
:curl -i -X POST http://localhost:8001/teamA/rbac/roles/admin/entities \ --data entity_id=3ed24101-19a7-4a0b-a10f-2f47bcd4ff43 \ --data entity_type=services \ --data actions=read \ -H 'Kong-Admin-Token:exampletokenA'
Response:
{ "created_at": 1531066684, "updated_at": 1531066684, "role_id": "ffe93269-7993-4308-965e-0286d0bc87b9", "entity_id": "3ed24101-19a7-4a0b-a10f-2f47bcd4ff43", "negative": false, "entity_type": "services", "actions": [ "read" ] }
curl -i -X POST http://localhost:8001/teamA/rbac/roles/qux-role/entities \ --data entity_id=d25afc46-dc59-48b2-b04f-d3ebe19f6d4b \ --data entity_type=routes \ --data actions=read \ -H 'Kong-Admin-Token:exampletokenA'
Response:
{ "created_at": 1531066684, "updated_at": 1531066684, "role_id": "ffe93269-7993-4308-965e-0286d0bc87b9", "entity_id": "d25afc46-dc59-48b2-b04f-d3ebe19f6d4b", "negative": false, "entity_type": "routes", "actions": [ "read" ] }
-
Add the user
qux
toqux-role
:curl -i -X POST http://localhost:8001/teamA/rbac/users/qux/roles \ --data roles=qux-role \ -H 'Kong-Admin-Token:exampletokenA'
Response:
{ "roles": [ { "comment": "Default user role generated for qux", "created_at": 1531065373, "updated_at": 1531065373, "name": "qux", "id": "31614171-4174-42b4-9fae-43c9ce14830f" }, { "created_at": 1531065975, "updated_at": 1531065975, "name": "qux-role", "id": "ffe93269-7993-4308-965e-0286d0bc87b9" } ], "user": { "created_at": 1531065373, "created_at": 1531065373, "id": "4d87bf78-5824-4756-b0d0-ceaa9bd9b2d5", "name": "qux", "enabled": true, "user_token": "sUnv6uBehM91amYRNWESsgX3HzqoBnR5" } }
-
Check that the correct permissions are listed for
qux
:curl -i -X GET http://localhost:8001/teamA/rbac/users/qux/permissions \ -H 'Kong-Admin-Token:exampletokenA'
Response:
{ "entities": { "d25afc46-dc59-48b2-b04f-d3ebe19f6d4b": { "actions": [ "read" ], "negative": false }, "3ed24101-19a7-4a0b-a10f-2f47bcd4ff43": { "actions": [ "read" ], "negative": false } }, "endpoints": {} }
qux
should have two entity permissions and no endpoint permissions.
Admin A is done setting up qux
, and qux
can now use their user token to read
the two entities over Kong’s admin API.
Let’s assume that Admin A enabled entity-level enforcement as well.
Note that as qux
has no endpoint-level permissions. If both endpoint and
entity-level enforcement is enabled, qux
won’t be able to read their entities, as
endpoint-level validation comes before entity-level.
-
As
qux
, try listing all RBAC users:curl -i -X GET http://localhost:8001/teamA/rbac/users/ \ -H Kong-Admin-Token:sUnv6uBehM91amYRNWESsgX3HzqoBnR5
Response:
{ "message": "qux, you do not have permissions to read this resource" }
-
As
qux
, try to accessservice1
:curl -i -X GET http://localhost:8001/teamA/services/service1 \ -H Kong-Admin-Token:sUnv6uBehM91amYRNWESsgX3HzqoBnR5
Response:
{ "host": "httpbin.konghq.com", "created_at": 1531066074, "updated_at": 1531066074, "connect_timeout": 60000, "id": "3ed24101-19a7-4a0b-a10f-2f47bcd4ff43", "protocol": "http", "name": "service1", "read_timeout": 60000, "port": 80, "path": null, "updated_at": 1531066074, "retries": 5, "write_timeout": 60000 }
Wildcards in permissions
RBAC supports the use of wildcards (*
) in many aspects of permissions.
Creating endpoint permissions
To create an endpoint permission via /rbac/roles/:role/endpoints
,
you must pass the parameters below, all of which can be replaced by a *
character:
-
endpoint
:*
matches any endpoint -
workspace
:*
matches any workspace -
actions
:*
evaluates to all actions—read, update, create, delete
Special case: endpoint
, in addition to a single *
, also accepts *
within the endpoint itself, replacing a URL segment between /
. For example,
all of the following are valid endpoints:
-
/rbac/*
: where*
replaces any possible segment, for example/rbac/users
and/rbac/roles
-
/services/*/plugins
:*
matches any service name or ID
Note
*
is not a generic, shell-like, glob pattern.
If workspace
is omitted, it defaults to the current request’s workspace. For
example, a role-endpoint permission created with /teamA/roles/admin/endpoints
is scoped to workspace teamA
.
Creating entity permissions
For entity permissions created via /rbac/roles/:role/entities
,
the following parameter accepts a *
character:
-
entity_id
:*
matches any entity ID
Entities nested in entity-level RBAC
With entity-level RBAC enabled, endpoints that list all entities of a particular collection will only list entities that the user has access to.
In the example above, if user qux
listed all routes, they would only get
the entities they have access to in the response, even though there
could be more in the workspace:
curl -i -X GET http://localhost:8001/teamA/routes \
-H 'Kong-Admin-Token:sUnv6uBehM91amYRNWESsgX3HzqoBnR5'
Response:
{
"next": null,
"data": [
{
"created_at": 1531066253,
"updated_at": 1531066253,
"id": "d25afc46-dc59-48b2-b04f-d3ebe19f6d4b",
"hosts": null,
"preserve_host": false,
"regex_priority": 0,
"service": {
"id": "3ed24101-19a7-4a0b-a10f-2f47bcd4ff43"
},
"paths": [
"/anything"
],
"methods": null,
"strip_path": false,
"protocols": [
"http",
"https"
]
}
]
}
Some Kong endpoints carry a total
field in responses. With entity-level RBAC
enabled, the global count of entities is displayed, but only entities the user
has access to are themselves shown.
For example, if Team A has a number of plugins configured, but qux
only has access to one of them,
the following would be the expected output for a GET request to /teamA/plugins
:
curl -i -X GET http://localhost:8001/teamA/plugins \
-H 'Kong-Admin-Token:sUnv6uBehM91amYRNWESsgX3HzqoBnR5'
Response:
{
"total": 2,
"data": [
{
"created_at": 1531070344,
"updated_at": 1531070344,
"config": {
"key_in_body": false,
"run_on_preflight": true,
"anonymous": "",
"hide_credentials": false,
"key_names": [
"apikey"
]
},
"id": "8813dd0b-3e9d-4bcf-8a10-3112654f86e7",
"name": "key-auth",
"enabled": true
}
]
}
Notice the total
field is 2, but qux
only got one entity in the response.
Creating entities in entity-level RBAC
As entity-level RBAC provides access control to individual existing entities, it does not apply to creation of new entities. For that, endpoint-level permissions must be configured and enforced.
For example, if endpoint-level
permissions are not enforced, qux
will be able to create new entities, and
will automatically have permissions to perform any actions to entities
they create:
curl -i -X POST http://localhost:8001/teamA/routes \
--data paths[]=/anything \
--data service.id=3ed24101-19a7-4a0b-a10f-2f47bcd4ff43 \
--data strip_path=false \
-H 'Kong-Admin-Token:sUnv6uBehM91amYRNWESsgX3HzqoBnR5'
Response:
{
"created_at": 1531070828,
"updated_at": 1531070828,
"strip_path": false,
"hosts": null,
"preserve_host": false,
"regex_priority": 0,
"paths": [
"/anything"
],
"service": {
"id": "3ed24101-19a7-4a0b-a10f-2f47bcd4ff43"
},
"methods": null,
"protocols": [
"http",
"https"
],
"id": "6ee76f74-3c96-46a9-ae48-72df0717d244"
}