Role-based access control in Microservices - Cheat Sheet & Quick Revision

Recall & Review

beginner

What is Role-based Access Control (RBAC)?

RBAC is a method to restrict system access to authorized users based on their roles. Each role has specific permissions, and users get access by being assigned roles.

intermediate

In a microservices architecture, where is RBAC typically enforced?

RBAC can be enforced at the API gateway, service level, or both. The gateway can check user roles before forwarding requests, and services can verify permissions for sensitive operations.

beginner

What are the main components of RBAC?

The main components are: Users (people or systems), Roles (job functions or titles), Permissions (allowed actions), and Sessions (user interactions with assigned roles).

intermediate

How does RBAC improve security in a distributed system?

RBAC limits access to only what users need, reducing risk of unauthorized actions. It simplifies management by grouping permissions into roles instead of assigning individually.

advanced

What is a common challenge when implementing RBAC in microservices?

A common challenge is keeping role and permission data consistent across services. This often requires a centralized identity and access management system or shared policy service.

What does RBAC stand for?

A Rule-based Access Control

B Resource-based Access Control

C Role-based Authorization Code

D Role-based Access Control

RBAC stands for Role-based Access Control, a method to manage user permissions based on roles.

In RBAC, what is assigned to users to grant permissions?

A Passwords

B Roles

C Tokens

D Sessions

Users are assigned roles, and roles have permissions that define what actions users can perform.

Where is RBAC enforcement commonly implemented in microservices?

A API Gateway

B Database only

C Frontend UI only

D Network router

RBAC is often enforced at the API Gateway to filter requests before they reach services.

Which is NOT a main component of RBAC?

A Encryption keys

B Roles

C Permissions

D Users

Encryption keys are unrelated to RBAC components, which focus on users, roles, and permissions.

What is a key benefit of using RBAC?

A Removes need for logging

B Eliminates need for authentication

C Simplifies permission management

D Allows all users full access

RBAC simplifies permission management by grouping permissions into roles.

Explain how Role-based Access Control works in a microservices system.

Think about how users get access and where checks happen.

Describe challenges and solutions for implementing RBAC across multiple microservices.

Consider how multiple services share access rules.

Practice

1. What is the main purpose of Role-Based Access Control (RBAC) in microservices?

easy

A. To encrypt data between microservices

B. To monitor network traffic for security threats

C. To assign permissions to users based on their roles

D. To deploy microservices automatically

Solution

1. Step 1: Understand RBAC concept

   RBAC assigns permissions to users based on their roles, simplifying access management.

2. Step 2: Identify RBAC purpose in microservices

   In microservices, RBAC controls who can access which service or API based on roles.

3. Final Answer:

   To assign permissions to users based on their roles -> Option C

4. Quick Check:

   RBAC = Role-based permission assignment [OK]

Hint: RBAC controls access by roles, not by encryption or deployment [OK]

Common Mistakes:

• Confusing RBAC with encryption
• Thinking RBAC monitors network traffic
• Assuming RBAC automates deployment

2. Which of the following is the correct way to represent a role in an RBAC system for microservices?

easy

A. {"service": "admin", "level": 5}

B. {"role": "admin", "permissions": ["read", "write"]}

C. {"user": "admin", "access": "full"}

D. {"permission": "admin", "role": "read"}

Solution

1. Step 1: Identify correct role structure

   A role should have a name and a list of permissions it grants.

2. Step 2: Match structure to options

   {"role": "admin", "permissions": ["read", "write"]} correctly shows a role with permissions as a list, matching RBAC design.

3. Final Answer:

   {"role": "admin", "permissions": ["read", "write"]} -> Option B

4. Quick Check:

   Role = name + permissions list [OK]

Hint: Roles have permissions list; user or service keys are incorrect here [OK]

Common Mistakes:

• Confusing user with role
• Using 'permission' as role name
• Assigning access level instead of permissions

3. Given this simplified RBAC check in a microservice:

def can_access(user_role, action):
    permissions = {
        "user": ["read"],
        "admin": ["read", "write", "delete"]
    }
    return action in permissions.get(user_role, [])

print(can_access("user", "delete"))

What is the output?

medium

A. None

B. True

C. KeyError

D. False

Solution

1. Step 1: Understand permissions dictionary

   The "user" role has only ["read"] permission, no "delete".

2. Step 2: Check if "delete" is in user permissions

   Since "delete" is not in ["read"], the function returns False.

3. Final Answer:

   False -> Option D

4. Quick Check:

   "delete" in user permissions = False [OK]

Hint: Check if action is in role's permission list [OK]

Common Mistakes:

• Assuming all actions allowed for user
• Expecting KeyError for missing keys
• Confusing True/False return values

4. A microservice uses this RBAC check:

def check_access(role, permission):
    role_permissions = {
        "editor": ["read", "write"],
        "viewer": ["read"]
    }
    return permission in role_permissions[role]

print(check_access("admin", "write"))

What is the problem and how to fix it?

medium

A. KeyError occurs; fix by using role_permissions.get(role, [])

B. SyntaxError due to missing colon; add colon after function

C. Returns False incorrectly; add "admin" role to dictionary

D. Returns True incorrectly; remove "write" from editor permissions

Solution

1. Step 1: Identify error cause

   Accessing role_permissions["admin"] causes KeyError because "admin" key is missing.

2. Step 2: Fix by safe dictionary access

   Use role_permissions.get(role, []) to return empty list if role missing, avoiding error.

3. Final Answer:

   KeyError occurs; fix by using role_permissions.get(role, []) -> Option A

4. Quick Check:

   Missing key causes KeyError; get() avoids it [OK]

Hint: Use get() to avoid KeyError on missing roles [OK]

Common Mistakes:

• Adding roles without permissions
• Confusing syntax errors with runtime errors
• Ignoring missing key errors

5. In a microservices architecture, where is the best place to enforce RBAC to ensure scalability and security?

hard

A. At the API Gateway before requests reach microservices

B. On the client side before sending requests

C. Only in the database layer with SQL permissions

D. Inside each microservice individually

Solution

1. Step 1: Consider scalability and security needs

   Enforcing RBAC centrally avoids duplication and reduces risk of inconsistent checks.

2. Step 2: Identify best enforcement point

   API Gateway is the central entry point, ideal for RBAC enforcement before microservices.

3. Final Answer:

   At the API Gateway before requests reach microservices -> Option A

4. Quick Check:

   Central RBAC at API Gateway = scalable & secure [OK]

Hint: Enforce RBAC centrally at API Gateway for best results [OK]

Common Mistakes:

• Enforcing RBAC only in microservices causes duplication
• Relying on client-side enforcement is insecure
• Using database permissions alone misses API-level control