Get Started - Explore RBAC - Workspace Admin Configures Regular Users, Roles and Members

Introduction

From this point on, team admins are able to drive the process; the next logical step is for Team users to be created; such team users could be, for example, engineers that are part of Team A (or B or C). 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. Such a role needs to have permissions to all of Admin API endpoints, except RBAC and Workspaces—regular users will not need access to these in general and, if they do, the Admin can grant them.

Learning Lab

In this learning lab, you will use the Workspace Admin to configure regular users, roles and members giving these members specific access privileges to the workspace.

High Level Tasks

Pre-requisites:

  • Step 0: Review: Setup the environment
  • Step 0: Review: Create RBAC super-admin user and enable RBAC
  • Step 0: Review: Kong Super Admin to RBAC user to create 3 workspaces each with 1 Admin

The Workspace Admin user will:

  • Step 1: Create regular users and role for each workspace
  • Step 2: Create permissions in the regular users role:
    • Create permission to all of Admin API—positive permission on *
    • Filter out RBAC and workspaces with negative permissions
  • Step 3: Create new members for each workspace
  • Step 4: Verify access using new member user-token

Step 0: Review: Setup the environment

Let’s setup the environment that will load the following

Launch Setup Script

Run this script in the terminal to setup your environment (~30 seconds).

launch.sh

Step 0: Review: Create RBAC super-admin user and enable RBAC

ADD SCRIPT HERE

Step 0: Review: Kong Super Admin to RBAC user to create 3 workspaces each with 1 Admin

ADD SCRIPT HERE


Step 1: Create regular users and role for each workspace

http post :8001/teamA/rbac/roles \
name=users \
Kong-Admin-Token:$adminA_user_token

Step 2: Create permissions in the regular users role:

Create permission to all of Admin API—positive permission on *

First, let’s create permissions to all of Admin API—positive permission on *

http post :8001/teamA/rbac/roles/users/endpoints/ \
endpoint=* \
workspace=teamA \
actions=* \
Kong-Admin-Token:$adminA_user_token

Q. What actions do you see?

Filter out RBAC and workspaces with negative permissions

Filter out RBAC with negative permissions

http post :8001/teamA/rbac/roles/users/endpoints/ \
endpoint=/rbac/* \
workspace=teamA \
actions=* \
Kong-Admin-Token:$adminA_user_token

Filter out workspace with negative permissions

http post :8001/teamA/rbac/roles/users/endpoints/ \
endpoint=/workspaces/* \
workspace=teamA \
actions=* \
Kong-Admin-Token:$adminA_user_token

Step 3: Create new members for each workspace

Team A just got 3 new members: foogineer, bargineer, and bazgineer. Admin A will welcome them to the team by creating RBAC users for them and giving them access to Kong!

Create foogineer:

http post :8001/teamA/rbac/users \
name=foogineer \
Kong-Admin-Token:$adminA_user_token

Add foogineer to the users role:

http post :8001/teamA/rbac/users/foogineer/roles \
roles=users \
Kong-Admin-Token:$adminA_user_token

Create bargineer:

http post :8001/teamA/rbac/users \
name=bargineer \
Kong-Admin-Token:$adminA_user_token

Add bargineer to the users role:

http post :8001/teamA/rbac/users/bargineer/roles \
roles=users \
Kong-Admin-Token:$adminA_user_token

Create bazgineer:

http post :8001/teamA/rbac/users \
name=bazgineer \
Kong-Admin-Token:$adminA_user_token

Add bazgineer to the users role:

http post :8001/teamA/rbac/users/bazgineer/roles \
roles=users \
Kong-Admin-Token:$adminA_user_token

Set Variables

Set variable for foogineer, bargineer and bazgineer user_token

Let’s set these variables for later use.

foogineer_user_token variable

foogineer_user_token=$(http get :8001/teamA/rbac/users/foogineer Kong-Admin-Token:$adminA_user_token | python -c "import sys, json; print json.load(sys.stdin)['user_token']")

bargineer_user_token variable

bargineer_user_token=$(http get :8001/teamA/rbac/users/bargineer Kong-Admin-Token:$adminA_user_token | python -c "import sys, json; print json.load(sys.stdin)['user_token']")

bazgineer_user_token variable

bazgineer_user_token=$(http get :8001/teamA/rbac/users/bazgineer Kong-Admin-Token:$adminA_user_token | python -c "import sys, json; print json.load(sys.stdin)['user_token']")

Alternatively You can get each user token with the following command e.g. fooengineer.

http get :8001/teamA/rbac/users/foogineer \
Kong-Admin-Token:$adminA_user_token


Step 4: Verify access using new member user-token

The new members, foogineer, bargineer, and bazgineer, all have gotten their RBAC user tokens from their Team A admin, and are now allowed to explore Kong—within the confines of their Team A workspace. Let’s validate they can in fact do anything they wish, except over RBAC and Workspaces.

List Workspaces using foogineer token

http get :8001/teamA/workspaces/ \
Kong-Admin-Token:$foogineer_user_token

Q. What message do you receive?

{ “message”: “foogineer, you do not have permissions to read this resource” }

list plugins

http get :8001/teamA/plugins \
Kong-Admin-Token:$foogineer_user_token

Enable some plugin — e.g., key-auth:

http post :8001/teamA/plugins \
name=key-auth \
Kong-Admin-Token:$foogineer_user_token

list plugins

http get :8001/teamA/plugins \
Kong-Admin-Token:$foogineer_user_token

Summary

This ends our use case tutorial; it demonstrates the power of RBAC and workspaces with a real-world scenario. Following, we will approach Entity-Level RBAC, an extension of our powerful access control to entity-level granularity.

Learning Challenge:

Repeat Step 4 but instead of configuring basic-auth plugin, try to configure a service, route, or consumer. Use either the bargineer or bazgineer user.

Edit this page