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.