Role-based access control in Microservices - System Design Guide

Problem Statement

When users have unrestricted access to all parts of a microservices system, sensitive data can be exposed and unauthorized actions can occur. Without clear boundaries, it becomes impossible to enforce security policies consistently across multiple services, leading to potential breaches and compliance failures.

Solution

Role-based access control assigns users to roles that define their permissions. Each microservice checks the user's role before allowing access to resources or actions. This centralizes permission management and ensures consistent enforcement of security rules across the system.

Architecture

User Client ├──────▶

→API Gateway ├──────▶

↓

Role & Token

Validation

↓

Microservice 2

(Checks Role)

This diagram shows a user request passing through an API Gateway to an Auth Service that issues role-based tokens. Microservices validate these tokens and enforce access based on user roles.

Trade-offs

✓ Pros

→

Centralizes permission management, simplifying updates and audits.

→

Enables consistent security enforcement across multiple microservices.

→

Reduces risk of unauthorized access by limiting user actions to assigned roles.

→

Scales well as new services and roles are added without redesigning access logic.

✗ Cons

→

Requires careful role design to avoid overly broad or too restrictive permissions.

→

Adds complexity to service interactions due to token validation and role checks.

→

Changes in roles may require token refresh or session invalidation to take effect.

Use when your system has multiple microservices requiring consistent access control and when user actions must be limited by roles, especially at scale beyond hundreds of users.

Avoid if your system is a simple single-service app with few users, where role management overhead outweighs security benefits.

Real World Examples

Uber

Uber uses RBAC to ensure drivers, riders, and support staff have access only to the data and actions relevant to their roles, preventing data leaks and unauthorized operations.

Amazon

Amazon Web Services implements RBAC to control user permissions across its vast cloud services, enabling fine-grained access control for customers and internal teams.

LinkedIn

LinkedIn applies RBAC to restrict access to user data and administrative functions, ensuring compliance with privacy regulations and internal policies.

Code Example

The before code allows any user to create orders without checks. The after code verifies the user's roles include 'order_creator' before proceeding, enforcing RBAC.

Microservices

### Before: No role checks in microservice endpoint
class OrderService:
    def create_order(self, user, order_data):
        # No access control
        process_order(order_data)
        return "Order created"


### After: Role-based access control applied
class OrderService:
    def create_order(self, user, order_data):
        if 'order_creator' not in user.roles:
            raise PermissionError("User lacks permission to create orders")
        process_order(order_data)
        return "Order created"

Alternatives

Attribute-based access control (ABAC)

ABAC uses user attributes and resource properties for access decisions instead of fixed roles.

Use when: Choose ABAC when access rules require fine-grained, dynamic policies based on multiple user and resource attributes.

Access control lists (ACL)

ACLs specify permissions per user or group directly on each resource rather than via roles.

Use when: Choose ACLs for simple systems with few users and resources where direct permission assignment is manageable.

Summary

Role-based access control limits user actions by assigning permissions to roles rather than individuals.

It centralizes security management and enforces consistent access rules across microservices.

RBAC is best for systems with multiple services and users requiring clear permission boundaries.

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