• Creating custom API-level and operation-level RBAC roles
• Integrating RBAC automation into CI/CD pipelines
• Best practices for maintaining least-privilege access

Overview

In our previous discussion, we explored why custom RBAC is a cost-effective alternative to Azure APIM Workspaces. Now, let's implement it.

This guide provides production-ready scripts and Azure DevOps pipelines for implementing Role-Based Access Control in Azure API Management. You'll create custom roles for API-level and operation-level access while following the principle of least privilege.

Understanding Azure APIM RBAC

Azure API Management uses three distinct roles for access control:

1. Built-in Role: API Management Service Reader

• Read-only access to the entire APIM service
• Baseline role for all users

2. Custom API-Level Role

• Manage all operations within specific APIs
• Cannot delete or modify APIs themselves
• Format: ApiRole-${identityType}-${identityName}-APIs

3. Custom Operation-Level Role

• Access to specific operations only within a single API
• Most restrictive role with smallest scope
• Format: OperationRole-${identityType}-${identityName}-${apiName}

Role Hierarchy

Azure API Management Service
│
│── Service Reader Role (Built-in)
│── API-Level Custom Role
│   ├── API 1, API 2, API n
└── Operation-Level Custom Role
    └── Operation 1, Operation 2, Operation n

Implementation Scripts

📚 GitHub Repository

Azure APIM RBAC Implementation

Repository Structure:

• /scripts - Bash scripts for RBAC operations
  • assign-api-roles.sh - API-level role assignment
  • assign-operation-roles.sh - Operation-level role assignment
  • remove-definitions-and-roles.sh - Role cleanup
• /.pipelines - Azure DevOps YAML templates
  • assign-api-rbac-pipeline.yaml
  • assign-operations-rbac-pipeline.yml
  • remove-roles-definitions-rbac-pipeline.yaml
• README.md - Setup and usage instructions

API-Level Access (All Operations of APIs)

Grant users access to manage all operations within specific APIs without modifying the APIs themselves.

Script: /scripts/assign-api-roles.sh
Pipeline: /.pipelines/assign-api-rbac-pipeline.yaml

Role Definition:

Allowed Actions:

"Actions": [
  "Microsoft.ApiManagement/service/apis/read",
  "Microsoft.ApiManagement/service/apis/operations/read",
  "Microsoft.ApiManagement/service/apis/operations/write",
  "Microsoft.ApiManagement/service/apis/operations/delete",
  "Microsoft.ApiManagement/service/apis/policies/read",
  "Microsoft.ApiManagement/service/apis/operations/policies/read",
  "Microsoft.ApiManagement/service/apis/operations/policies/write",
  "Microsoft.ApiManagement/service/apis/operations/policies/delete"
]

Denied Actions:

"NotActions": [
  "Microsoft.ApiManagement/service/apis/write",
  "Microsoft.ApiManagement/service/apis/delete",
  "Microsoft.ApiManagement/service/apis/revisions/*",
  "Microsoft.ApiManagement/service/apis/schemas/*",
  "Microsoft.ApiManagement/service/users/*",
  "Microsoft.ApiManagement/service/gateways/*"
]

What this means:

• ✅ Read APIs and operations
• ✅ Create, update, delete operations
• ✅ Manage operation policies
• ❌ Modify or delete APIs
• ❌ Manage API revisions or schemas

Usage:

./scripts/assign-api-roles.sh \
  "subscription-id" \
  "resource-group" \
  "apim-instance" \
  "user@example.com" \
  '["api1", "api2"]'

Pipeline Parameters:

• userEmail - User/group for role assignment
• apiNames - List of APIs to grant access to

Operation-Level Access (Selective Operations)

Grant access to specific operations only within a single API—the most granular control.

Script: /scripts/assign-operation-roles.sh
Pipeline: /.pipelines/assign-operations-rbac-pipeline.yml

Role Definition:

Allowed Actions:

"Actions": [
  "Microsoft.ApiManagement/service/apis/read",
  "Microsoft.ApiManagement/service/apis/operations/read",
  "Microsoft.ApiManagement/service/apis/operations/write",
  "Microsoft.ApiManagement/service/apis/operations/policies/read",
  "Microsoft.ApiManagement/service/apis/operations/policies/write"
]

Denied Actions:

"NotActions": [
  "Microsoft.ApiManagement/service/apis/write",
  "Microsoft.ApiManagement/service/apis/delete",
  "Microsoft.ApiManagement/service/apis/policies/write",
  "Microsoft.ApiManagement/service/apis/policies/delete",
  "Microsoft.ApiManagement/service/apis/revisions/*",
  "Microsoft.ApiManagement/service/apis/schemas/*",
  "Microsoft.ApiManagement/service/users/*",
  "Microsoft.ApiManagement/service/gateways/*"
]

What this means:

• ✅ Read API information
• ✅ Read and write specific operations only
• ✅ Manage policies for those operations
• ❌ Access other operations
• ❌ Modify API-level policies

Usage:

./scripts/assign-operation-roles.sh \
  "subscription-id" \
  "resource-group" \
  "apim-instance" \
  "user@example.com" \
  "api1" \
  '["getUsers", "createUser"]'

Pipeline Parameters:

• userEmail - User/group for role assignment
• apiName - Single API name
• operationNames - Specific operations to grant access to

Role Cleanup

Remove RBAC roles and assignments when no longer needed.

Script: /scripts/remove-definitions-and-roles.sh
Pipeline: /.pipelines/remove-roles-definitions-rbac-pipeline.yaml

Usage:

./scripts/remove-definitions-and-roles.sh \
  "user@example.com" \
  '["ApiRole-user-username-APIs"]'

Pipeline Parameters:

• userEmail - User/group whose assignments to remove
• roleNames - Array of role names to delete

Azure DevOps Integration

Pipeline Architecture

Main Pipeline
│
│── Variables (from apim-rbac-variables group)
│   ├── azureSubscription
│   ├── subscriptionId
│   ├── resourceGroup
│   └── apimInstance
│
│── Parameters (runtime)
│   ├── userEmail
│   └── apiNames / apiName + operationNames
│
└── Stage: RBACManagement
    └── Job: ExecuteRBACManagement
        ├── Verify Azure connectivity
        └── Assign RBAC role

Variable Group Setup

Create apim-rbac-variables in Azure DevOps with:

• azureSubscription - Azure service connection
• subscriptionId - Azure subscription ID
• resourceGroup - Target resource group
• apimInstance - APIM instance name

Recommended Workflow

1. Deploy APIs using your standard process
2. Run RBAC pipeline with appropriate parameters
3. Verify assignments in Azure portal
4. Clean up when permissions no longer needed

Note: If using Azure resource locks, remove them before RBAC operations.

Best Practices

Security & Access

• Start with least privilege—grant minimum permissions needed
• Review role assignments monthly
• Remove unused roles promptly

Organization

• Use consistent role naming: ApiRole-${type}-${name}-APIs
• Document all permission grants with business justification
• Keep RBAC scripts in source control alongside API definitions

Maintenance

• Schedule quarterly audits of active assignments
• Check for conflicting higher-level roles
• Maintain audit trail of all changes

Wrapping Up

Custom RBAC provides fine-grained access control in Azure APIM without Premium Workspaces. Automated pipelines eliminate manual work while maintaining security and cost efficiency.

Next Steps: Clone the GitHub repository and customize for your environment.

📚 Resources

GitHub Repository: Azure APIM RBAC Implementation
Complete scripts, pipeline templates, and implementation examples

Related Reading:
RBAC vs APIM Workspaces: Cost-Effective API Governance

💬 Let's Connect

Questions? Reach out on LinkedIn or comment below.

Found this useful? Share with your team!

The Future Stack by Rama - Cloud • APIs • DevOps • Architecture • AI

Hashnode | LinkedIn

Keep building! 🚀 — Rama Thotapalli

In today's rapidly evolving digital landscape, how can organizations allow multiple teams to manage their own APIs without granting full control over the entire Azure API Management (APIM) instance? As companies expand, they require a secure and isolated method to onboard teams. Traditionally, "Workspaces" have been the solution, offering isolated environments for team collaboration. However, a recent change in Azure's pricing model has transformed this into a significant financial decision.

The Enterprise Challenge: Isolation vs. Cost

For years, teams relied on the Developer or Standard tiers to achieve multi-team isolation. However, in September 2024, a significant change occurred: the Workspaces feature, which offers isolated sandboxes for different teams, became exclusive to the Premium tier. While Workspaces are considered the 'gold standard' for team collaboration due to their ability to provide complete isolation and management autonomy, the increased cost of entry has become a substantial hurdle for many organizations.

The True Cost of a Workspace Setup (2026 USD Estimates)

Implementing a workspace-based flow today requires an investment of approximately $34,812 USD per year, per instance. This includes:

• Premium Instance Base: Approximately $33,612 per year, which is mandatory to unlock the Workspace feature.

• Workspace Packs: Around $1,200 per year to support more than five teams.

• Optional Physical Isolation: Adding a Workspace Gateway to ensure one team's traffic never impacts another can increase the total to approximately $51,600 USD per year. This option is particularly beneficial for organizations that require strict traffic segregation for compliance or performance reasons.

The Lean Alternative: Granular RBAC

Can you achieve these same goals without the ~$51k price tag? The answer is Yes. By using Azure's native Role-Based Access Control (RBAC), you can achieve fine-grained isolation at the API and Product levels with no additional licensing costs.

Why RBAC Wins for Most Use Cases

• No Additional Cost: You can use your existing APIM tier (including Standard v2) without upgrading to Premium.

• Custom Precision: You can create specific roles (e.g., ApiRole-TeamA-APIs) that allow teams to "Read/Write" their own operations while strictly "Denying" them the ability to delete APIs or see other teams' work.

• Central Governance: Your central platform team retains "Owner" rights, while developers act as "Contributors" only within their assigned scope. This ensures a balance between autonomy and control.

Which One Should You Choose?

• Choose Workspaces if you're a large global enterprise requiring total physical traffic isolation and separate management planes for numerous autonomous business units. Consider the long-term benefits of complete isolation against the cost.

• Choose RBAC if you need a secure, scalable way to onboard 5–20 teams and wish to avoid the significant cost increase associated with the Premium SKU. Evaluate your team's specific needs and the potential for cost savings.

The Final Verdict

In our environment, the decision was straightforward: the high cost of a Workspace (approximately $51,000 USD per instance) was not justifiable. We discovered that our objectives could be effectively achieved through Custom RBAC roles and automated onboarding pipelines, saving the organization tens of thousands of dollars annually. For organizations facing similar decisions, consider your specific requirements and explore both options to determine the best fit.

What's Next?

Ready to implement this solution? Check out our follow-up article, Implementing Granular RBAC in Azure API Management: A Cost-Effective Alternative to Workspaces, where we dive into the technical details. You'll find a step-by-step guide on setting up custom RBAC roles, creating automated onboarding pipelines, and managing role-based access control for your APIs.

💬 Let's Connect

Questions? Reach out on LinkedIn or comment below.

Found this useful? Share with your team!

The Future Stack by Rama - Cloud • APIs • DevOps • Architecture • AI

Hashnode | LinkedIn

Keep building! 🚀 — Rama Thotapalli