Azure Pipelines Security

Service connections, variable groups, and pipeline permissions

Language / Topic

Azure DevOps Pipelines

Rules

Azure Pipelines Security · balanced balanced

- Use service connections with Workload Identity Federation (OIDC) — no stored secrets for Azure resource access

- Link variable groups to Azure Key Vault; never hardcode secrets in YAML or pipeline variables

- Restrict pipeline permissions: limit service connections and variable groups to specific pipelines, not project-wide

- Use extends templates to enforce security policies — prevents pipelines from running arbitrary scripts

- Mark all secret variables as isSecret: true; they are masked in logs and excluded from environment exports

- Use Workload Identity Federation for service connections — eliminates stored secrets with short-lived OIDC tokens

- Link variable groups to Azure Key Vault: secrets are fetched at runtime, rotated centrally, never stored in pipelines

- Use SecretsFilter to fetch only required Key Vault secrets — avoid * which exposes entire vault on compromise

- Restrict service connection scope: assign to specific pipelines, not project-wide; require approval for use

- Use extends templates to enforce security policies: block inline script execution, mandate approved tasks only

- Mark variables as secret (isSecret: true); secrets are masked in logs and unavailable to forked PR builds

- Separate Key Vaults per environment (dev, staging, prod) — different access controls, different blast radius

- Configure branch policies: require PR reviews, linked work items, and successful builds before merging to main

- Use pipeline permissions to restrict who can edit YAML and which repos can trigger protected pipelines

- Set pipeline-level permissions: Readers see runs, Contributors trigger builds, Administrators modify pipelines

- Disable script access to OAuth token unless explicitly needed — set env: SYSTEM_ACCESSTOKEN only where required