KubeQuest

Appearance

Lab 02: Role-Based Access Control (RBAC) ​

Time: 60 minutes
Difficulty: Intermediate-Advanced
Portal Locations: Azure Portal → Subscriptions/Resource Groups → Access Control (IAM)

Lab Overview ​

You are the Azure administrator for Contoso Ltd. Multiple teams need access to Azure resources with different permission levels. You must implement the principle of least privilege while ensuring teams can do their jobs.

Pre-Lab Setup ​

Before starting, create these resources:

  1. Resource Group 1: rg-project-dev

    • Location: East US

  2. Resource Group 2: rg-project-prod

    • Location: East US

  3. Storage Account: stprojectdev[random] in rg-project-dev

    • SKU: Standard LRS
    • Create a blob container named documents
    • Upload any test file to the container

  4. Key Vault: kv-project-dev-[random] in rg-project-dev

    • Create a secret named ApiKey with value test-secret-123

Task 1: Understand Role Assignment Components ​

Objective ​

Before making any changes, analyze the existing role assignments in your subscription.

Requirements ​

Navigate to your subscription's Access Control (IAM) and answer these questions:

  1. List all role assignments at the subscription level

    • How many assignments exist?
    • What roles are assigned?
    • Are any inherited from a management group?

  2. View the definition of the "Contributor" role

    • What actions does it ALLOW?
    • What actions does it DENY (NotActions)?
    • Can a Contributor assign roles to others?

  3. Compare Reader vs Contributor vs Owner

    • What is the key difference between each?

Validation ​

  • [ ] You can access IAM → Role assignments at subscription level
  • [ ] You can view role definitions and understand Actions/NotActions
  • [ ] You understand the inheritance model (Management Group → Subscription → Resource Group → Resource)

Task 2: Assign Built-in Roles at Resource Group Scope ​

Objective ​

Grant a user read-only access to the development resource group, but NO access to production.

Requirements ​

  1. Target User: Use a test user from Lab 01 (or create: devuser@yourdomain.onmicrosoft.com)

  2. Assign Role:

    • Role: Reader
    • Scope: rg-project-dev only
    • NOT at subscription level
    • NOT at rg-project-prod

  3. Verify Inheritance:

    • Check if the user can see the storage account in rg-project-dev
    • Check if the user can see the key vault in rg-project-dev

Validation ​

  • [ ] Role assignment exists on rg-project-dev only
  • [ ] User CAN see resources in rg-project-dev
  • [ ] User CANNOT see rg-project-prod at all
  • [ ] User CANNOT create or modify any resources

Task 3: Data Plane vs Control Plane Permissions ​

Objective ​

Understand the critical difference between managing a resource and accessing its data.

Requirements ​

  1. Current State: User has Reader on rg-project-dev

  2. Test Control Plane Access:

    • Can the user view storage account properties? (Expected: Yes)
    • Can the user view storage account keys? (Expected: No)
    • Can the user view Key Vault properties? (Expected: Yes)

  3. Test Data Plane Access:

    • Can the user view blobs in the storage container? (Expected: No)
    • Can the user view the secret in Key Vault? (Expected: No)

  4. Add Data Plane Permission:

    • Assign Storage Blob Data Reader role to the user
    • Scope: Storage account level (not resource group)

  5. Re-test Data Plane:

    • Can the user now view blobs? (Expected: Yes)

Validation ​

  • [ ] User has Reader (control plane) on resource group
  • [ ] User has Storage Blob Data Reader (data plane) on storage account
  • [ ] User CAN view blob contents
  • [ ] User still CANNOT view storage account keys
  • [ ] User still CANNOT view Key Vault secrets (no data plane role assigned)

Task 4: Assign Contributor with Scope Limitation ​

Objective ​

Grant a developer the ability to deploy resources, but only to the development environment.

Requirements ​

  1. Create Second Test User: developer@yourdomain.onmicrosoft.com

  2. Assign Role:

    • Role: Contributor
    • Scope: rg-project-dev

  3. Verify Permissions:

    • User CAN create a new storage account in rg-project-dev
    • User CANNOT create anything in rg-project-prod
    • User CANNOT assign roles to others (verify this!)

Validation ​

  • [ ] Developer has Contributor on rg-project-dev
  • [ ] Developer CAN create resources in dev
  • [ ] Developer CANNOT access prod resource group
  • [ ] Developer CANNOT access IAM to assign roles

Task 5: Key Vault Access Configuration ​

Objective ​

Configure Key Vault access using Azure RBAC (not access policies).

Requirements ​

  1. Verify Key Vault Permission Model:

    • Open Key Vault → Settings → Access configuration
    • Ensure "Azure role-based access control" is selected
    • (If using Access policies, switch to RBAC for this lab)

  2. Assign Secret Reader:

    • User: devuser (from Task 2)
    • Role: Key Vault Secrets User
    • Scope: Key Vault resource level

  3. Test Access:

    • User should be able to view the ApiKey secret value

  4. Challenge: What if you wanted the user to read secrets but NOT see their values?

    • Which role would you use?

Validation ​

  • [ ] Key Vault is using Azure RBAC for permission model
  • [ ] User has Key Vault Secrets User role
  • [ ] User CAN view secret value in portal
  • [ ] User CANNOT delete or modify the secret

Task 6: Create a Custom Role ​

Objective ​

Create a custom role that allows starting/stopping VMs but nothing else.

Requirements ​

  1. Create Custom Role Definition:

    • Name: Virtual Machine Operator

    • Description: Can start, stop, and restart VMs. Cannot create or delete.

    • Allowed Actions:

      • Microsoft.Compute/virtualMachines/read
      • Microsoft.Compute/virtualMachines/start/action
      • Microsoft.Compute/virtualMachines/restart/action
      • Microsoft.Compute/virtualMachines/powerOff/action
      • Microsoft.Compute/virtualMachines/deallocate/action
      • Microsoft.Network/*/read (to see network info)
      • Microsoft.Resources/subscriptions/resourceGroups/read

    • NOT Allowed:

      • Cannot delete VMs
      • Cannot create VMs
      • Cannot modify VM configuration

  2. Assignable Scopes:

    • Your subscription only

  3. Assign the Role:

    • Assign to a test user at the rg-project-dev scope

Validation ​

  • [ ] Custom role appears in role definitions
  • [ ] Role can be assigned to users
  • [ ] User with role CAN stop/start VMs (create a test VM to verify)
  • [ ] User with role CANNOT delete or create VMs

Task 7: Deny Assignments (Conceptual) ​

Objective ​

Understand how deny assignments work (even though you cannot create them directly).

Requirements ​

  1. Research: Navigate to your subscription → IAM → Deny assignments

    • Are there any deny assignments?
    • Who created them (if any exist)?

  2. Understand the Concept:

    • Deny assignments can ONLY be created by Azure Blueprints
    • They block access even if a role assignment would allow it
    • They are evaluated AFTER allow assignments

  3. Scenario Analysis: A user has:

    • Contributor role at subscription level
    • Deny assignment that blocks delete operations on rg-project-prod

    Question: Can the user delete resources in rg-project-prod?

Validation ​

  • [ ] You understand that Deny > Allow
  • [ ] You know deny assignments come from Blueprints only
  • [ ] Answer to scenario: NO - deny blocks even though Contributor would allow

Task 8: Role Assignment Conditions (Preview) ​

Objective ​

Add conditions to a role assignment for more granular control.

Requirements ​

  1. Assign Storage Blob Data Contributor to a user with conditions:

    • User: developer
    • Role: Storage Blob Data Contributor
    • Scope: Storage account

  2. Add Condition:

    • The user can ONLY access blobs where the blob index tag project equals alpha

  3. Test:

    • Upload a blob WITH tag project=alpha → User should access
    • Upload a blob WITHOUT that tag → User should NOT access

Note: This is an advanced feature. Skip if conditions UI is not available in your region.

Validation ​

  • [ ] Role assignment has condition attached
  • [ ] Condition enforces tag-based access
  • [ ] Access is correctly limited based on blob tags

Task 9: Remove and Audit Role Assignments ​

Objective ​

Clean up role assignments and review the audit trail.

Requirements ​

  1. View Activity Log:

    • Navigate to subscription → Activity log
    • Filter by Operation: "Create role assignment" and "Delete role assignment"
    • Review who made changes and when

  2. Export Role Assignments:

    • From IAM, download role assignments as CSV
    • Review the export format

  3. Remove Test Assignments:

    • Remove all role assignments created during this lab
    • Keep only your original admin access

Validation ​

  • [ ] Activity log shows role assignment operations
  • [ ] You can export assignments to CSV
  • [ ] All test assignments are removed

Cleanup Instructions ​

  1. Remove all custom roles created during this lab
  2. Remove all role assignments to test users
  3. Delete the test resource groups:
    • rg-project-dev
    • rg-project-prod
  4. Delete test users (if created specifically for this lab)

Key Concepts Tested ​

  • Role assignment = Principal + Role + Scope
  • Scope hierarchy and inheritance
  • Control plane vs Data plane permissions
  • Built-in roles: Reader, Contributor, Owner
  • Custom roles and their limitations
  • Key Vault RBAC vs Access Policies
  • Activity logging for compliance
  • Deny assignments (Blueprints only)

Released under the MIT License.

Copyright © 2026 OpsAlchemy