What is Azure Pipeline, how to use ‘Service Principle’ trump over ‘Personal Access Token’ in pipeline integration to increase security
-
Share
Introduction
DevOps à ADO à Azure Pipeline
DevOps is a collaborative approach to software development that aims to break down silos between development (Dev) and operations (Ops) teams. It fosters communication, collaboration, and automation throughout the entire software lifecycle, from ideation to deployment and ongoing maintenance.
Key Principles of DevOps:
- Collaboration.
- Automation.
- Continuous Integration and Delivery (CI/CD) [frequent code integration and delivery, allowing for faster feedback loops and quicker deployments.]
- Infrastructure as Code (IaC) [Infrastructure is treated as code, allowing it to be version controlled, managed, and provisioned automatically.]
- Monitoring and Feedback.
Based on the above key principles, DevOps tools are crucial for streamlining software development lifecycles. Some of the well-known are: - Git (GitHub, GitLab, Bitbucket), Chef, Puppet, Docker, Jenkins, Azure DevOps (ADO), Circle-CI, Gear-set, Copado, Prometheus, JIRA etc.
Microsoft Azure DevOps:
Commonly identified as Azure DevOps or ADO is one of the most comprehensive suites of cloud-based tools designed to support the entire DevOps lifecycle. It provides a single platform for teams to plan, develop, test, deploy, and monitor applications. Through: Boards, Repos, Pipelines, Test Plans, Artifacts.
What is Azure pipeline
Azure Pipelines is a cloud-based automation solution provided by Microsoft that supports all major languages and project types. It combines continuous integration, continuous delivery, and continuous testing to build, test, and deliver code to any destination (based on triggers). Like:
- Continuous integration (CI) triggers: These triggers vary based on the type of repository.
- Pull request validation (PR) triggers: These triggers also vary based on the type of repository.
- Comment triggers: These triggers are only supported for GitHub repositories.
- Resource triggers: These triggers are triggered by the resources defined in your pipeline. These resources can be pipelines, builds, repositories, containers, packages, or webhooks sources.
- Code pushed to repository trigger: Automatically start a pipeline upon code pushes to specific branches or repositories.
Azure presently supports 2 distinct types of pipelines namely:
- Build Pipelines: Mainly YAML driven.
- Release Pipelines: Classic release pipelines, use artifacts
Now, Azure Pipelines also offers various ways to trigger one pipeline from another based on the needs. Below are some of the basic scenarios mentioned below:
Triggering based on events:
- Build completion trigger: Run a pipeline when another pipeline completes (success or failure). Filter based on branches, build definitions, etc.
- Release completion trigger: Like build completion, trigger a release pipeline when a build pipeline finishes.
Pipeline Integration using APIs:
- REST API: Programmatically control your pipelines: trigger runs, access build/release info, manage CI/CD workflow.
- PowerShell cmdlets: Manage tasks like the REST API directly from PowerShell scripts.
- Security Token: Security credential used for authentication and authorization of the API
Suitable for: Advanced automation, integrating with custom scripts or tools.
Other methods of integration:
- Service hooks: Connect your pipeline to other tools/services, allowing them to trigger runs or interact with pipeline data.
- Custom extensions: Develop extensions to integrate with tools/services not directly supported by Azure Pipelines.
Security Token mainly used in integration of Pipelines using APIs Access Token.
An Access Token in Azure DevOps is a type of security credential used for authentication and authorization purposes. It provides temporary access to specific resources within Azure DevOps, such as repositories, pipelines, or work items. Access tokens are typically generated by users or applications and can be scoped to limit the permissions granted to the bearer. They are commonly used in scenarios where automated processes or external tools need to interact with Azure DevOps services securely, without requiring the user's direct credentials. Access tokens can be revoked or regenerated as needed, providing flexibility and control over access to sensitive resources.
Key points about Service Principals in Azure DevOps include:
- Identity: A Service Principal has its own identity, typically represented by a unique identifier (Client ID) and an associated secret (Client Secret or Certificate). This identity is used to authenticate the Service Principal when accessing Azure resources.
- Authorization: Service Principals are granted permissions (roles) that determine what actions they can perform on Azure resources. These permissions are defined using Azure Role-Based Access Control (RBAC).
- Secure Authentication: Service Principals can authenticate using various methods, including Client Secrets, Certificates, or Managed Identities. Client Secrets and Certificates provide a secure way for automated processes to authenticate without human intervention.
- Scoped Access: Service Principals can be scoped to limit the resources they can access and the actions they can perform. This helps enforce the principle of least privilege and enhances security.
- Lifecycle Management: Service Principals can be managed, including creating, updating, and deleting them as needed. They can also be rotated or regenerated to enhance security.
Service Principal.
A Service Principal in Azure DevOps is a type of identity used for authentication and authorization within the Azure ecosystem. It represents an application or service and is used to access Azure resources programmatically without the need for interactive login sessions. Service Principals are often used in scenarios where automation tasks, such as Continuous Integration/Continuous Deployment (CI/CD) pipelines, need to interact with Azure services.
- Client ID: The Client ID for Service Principals in Azure DevOps is a unique identifier assigned to each Service Principal, used for authentication and authorization when accessing Azure resources programmatically.
- Tenant ID: The Tenant ID for Service Principals in Azure DevOps is a unique identifier for the Azure Active Directory (AAD) tenant associated with the Service Principal, used for authentication and authorization within the Azure ecosystem.
- Client Secrete: The Client Secret for Service Principals in Azure DevOps is a secure and confidential key used for authentication and authorization, providing access to Azure resources on behalf of the associated application or service principal.
- Subscription ID: The Subscription ID for Service Principals in Azure DevOps is a unique identifier assigned to an Azure subscription, enabling access to specific resources and services within the subscription through the associated service principal.
Why Service Principal and not Personal Access token
Granular Permissions:
- Service principles: You can assign specific permissions to a service principal, limiting its access to only the resources it needs. This minimizes the potential damage if the credentials are compromised.
- Service principles: You can assign specific permissions to a service principal, limiting its access to only the resources it needs. This minimizes the potential damage if the credentials are compromised.
No Password Storage:
- Service principles: You don't store service principal credentials directly in your pipelines or code. Instead, you use certificates or client secrets to store it securely (e.g., Azure Key Vault).
- PATs: PATs are essentially passwords stored in plaintext. Leaving them in code or scripts exposes them to potential leaks.
Reduced Scope and Expiration:
- Service principles: You can set specific scopes and expiration times for service principal access tokens, further limiting their impact even if compromised.
- PATs: PATs typically have longer expiration times and broader scopes, increasing the risk window if compromised.
Easier Rotation and Revocation:
- Service principles: Rotating or revoking access for a service principal is straightforward, as you don't need to track down and invalidate every instance of the associated secret.
- PATs: Rotating or revoking a PAT requires finding and updating all places where it's used, which can be tedious and error prone.
PATs: Rotating or revoking a PAT requires finding and updating all places where it's used, which can be tedious and error prone.
- Service principles: You can easily track service principal activity in Azure DevOps audit logs, identifying suspicious behaviour.
- PATs: Tracking PAT activity is more challenging, as they may be used different user driven.
Overall, using service principles over PATs promotes secure access to Azure DevOps resources by minimizing exposure, enabling granular control, and facilitating better access management.
Conclusion
Say in a project, a critical need emerges to automate the triggering of a specific release pipeline. However, stringent security protocols and concerns preclude integrating this automation with any personal account, such as using a Personal Access Token (PAT). So, usage of Service Principal aligns with the project's security requirements, ensuring that sensitive credentials and access rights are managed and utilized in a secure and compliant manner.
Query and use Azure Key Vault secrets in your Pipeline - Azure Pipelines | Microsoft Learn
AzureKeyVault@2 - Azure Key Vault v2 task | Microsoft Learn
Troubleshoot pipeline failure to start - Azure Pipelines | Microsoft Learn
Fetching the TenanId for a subscription from Azure Active Directory - Stack Overflow
az account tenant | Microsoft Learn
How to get the azure account tenant Id? - Stack Overflow
To learn more about our Salesforce Practice, Capabilities, and Solutions – Click here