4.1.1. Authentication and Authorization

💡 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:

• Azure Authentication: Service Principals, Managed Identities.
• GitHub Authentication: GitHub Apps, GITHUB_TOKEN, PATs.
• Azure DevOps Authentication: Service Connections, PATs.
• Permissions Models: GitHub Repository Roles, Azure DevOps Security Groups.
• Principles: Least Privilege, Stakeholder/Outside Collaborator access.

⚠️ 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.

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?