Copyright (c) 2026 MindMesh Academy. All rights reserved. This content is proprietary and may not be reproduced or distributed without permission.

4.1.1.2. Role-Based Access Control and Least Privilege

4.1.1.2. Role-Based Access Control and Least Privilege

Managed identities and service principals establish who a pipeline is; role-based access control determines what it can do.

💡 First Principle: The fundamental purpose of authentication and authorization in DevOps is to enforce the principle of least privilege, ensuring that every identity—whether human or service—is verified and granted only the minimum necessary permissions to perform its function, thereby minimizing the attack surface.

Scenario: You are designing a CI/CD pipeline in Azure Pipelines that needs to deploy resources to an Azure subscription and interact with a GitHub repository. Developers need specific access to Azure DevOps projects and repositories. You need to ensure all authentication and authorization are secure and adhere to the principle of least privilege.

What It Is: Authentication is the process of verifying the identity of a user or service. Authorization determines what an authenticated identity can access and what actions it can perform.

For Azure, design authentication using Service Principals for applications and services requiring access to Azure resources. Alternatively, leverage Managed Identities (system-assigned and user-assigned) for Azure resources (like VMs or App Services) to authenticate to cloud services without managing credentials.

GitHub authentication methods include GitHub Apps for programmatic integrations, the ephemeral GITHUB_TOKEN automatically provided to GitHub Actions workflows, and Personal Access Tokens (PATs) for user-level API access and automation.

In Azure DevOps, Service Connections securely store credentials for connecting to external services like Azure or GitHub. Personal Access Tokens (PATs) are used for user-level automation and scripting within Azure DevOps.

GitHub permissions are managed through repository roles, such as admin, maintain, write, triage, and read, each granting specific capabilities.

Azure DevOps implements permissions using built-in security groups (e.g., Project Administrators, Contributors) and custom groups, applying Role-Based Access Control (RBAC) to define access levels.

When recommending access, always enforce the principle of least privilege. Consider specific access levels like limited Stakeholder access in Azure DevOps for basic work item viewing, or controlled Outside Collaborator access in GitHub for external team members.

Key Components of Authentication and Authorization:

⚠️ Common Pitfall: Granting broad permissions (like "Contributor" at the subscription level) to a pipeline's service principal. This violates the principle of least privilege and dramatically increases the blast radius if the pipeline is compromised.

Key Trade-Offs:
  • Granularity vs. Management Complexity: Highly granular permissions are more secure but can be more complex to manage. Using well-defined roles and groups helps balance this.
Practical Implementation: Azure DevOps Service Connection
  1. Create Service Principal: In Azure, create a Service Principal for your pipeline.
  2. Assign Role: Grant it the "Contributor" role only on the specific Resource Group it needs to deploy to.
  3. Create Service Connection: In Azure DevOps, go to Project Settings > Service Connections.
  4. New Service Connection: Choose "Azure Resource Manager" and "Service principal (automatic)" or "(manual)".
  5. Configure: Provide the subscription and scope it to the specific Resource Group.
  6. Use in Pipeline: Reference the service connection name in your YAML pipeline's azureSubscription property.
Service Principals vs Managed Identity — Exam-Critical Decision:

This is one of the most frequently tested topics on the AZ-400. A Service Principal is an identity created in Azure AD for applications and automation. It authenticates using a client secret (password) or certificate. You must manage credential rotation. A Managed Identity is a special type of service principal automatically managed by Azure — no credentials to store, rotate, or manage. There are two types: system-assigned (lifecycle tied to the Azure resource; deleted when the resource is deleted) and user-assigned (independent lifecycle; can be shared across multiple resources). Decision rule: If the service runs on an Azure resource (VM, App Service, Container Instance), prefer Managed Identity. If it runs outside Azure, use a Service Principal.

GitHub Authentication Mechanisms:

GitHub offers three primary authentication methods for automation: (1) GITHUB_TOKEN — automatically generated for each workflow run, scoped to the repository, expires when the workflow completes. Use for operations within the current repository. (2) Personal Access Tokens (PATs) — user-scoped with configurable permissions and expiration. Fine-grained PATs offer repository-specific scoping. (3) GitHub Apps — the most robust option. Apps have their own identity, granular permissions, higher rate limits, and generate installation tokens. Prefer GitHub Apps for production automation over PATs.

Azure DevOps Permissions Model:

Azure DevOps uses a layered permission model: Organization → Project → Repository/Pipeline/Board. Security groups cascade permissions downward. Key built-in groups: Project Administrators (full project control), Build Administrators (manage pipelines), Contributors (commit code, run pipelines), Readers (view only). Service connections have their own permission model — by default, only pipeline administrators can use a service connection, but access can be granted to specific pipelines.

Stakeholder Access vs Outside Collaborator:

In Azure DevOps, Stakeholder access is a free access level that allows users to view work items, dashboards, and wikis but restricts backlog management and code access. In GitHub, Outside Collaborators are users who are not organization members but are granted access to specific repositories. Both are tested on the AZ-400 as cost-effective ways to include non-developer stakeholders.

Reflection Question: How do various authentication methods (Service Principals, Managed Identities, GitHub Apps) and authorization models (GitHub Repository Roles, Azure DevOps Security Groups) collectively protect sensitive resources and maintain system integrity in your DevOps solutions?

Alvin Varughese
Written byAlvin Varughese
Founder•15 professional certifications