Acesso seguro de pipelines ao Azure Repos

2025-04-30

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Seus repositórios são vitais para o sucesso do seu negócio, pois abrigam o código que alimenta suas operações. O acesso aos repositórios deve ser cuidadosamente controlado. Este artigo orienta você sobre como aprimorar a segurança do pipeline de build e do pipeline de release clássico ao acessar o Azure Repos, para reduzir o risco de acesso não autorizado.

Para garantir o acesso seguro aos repositórios do Azure, habilite as seguintes alternâncias:

Limitar o escopo de autorização de trabalho ao projeto atual para pipelines que não são de lançamento
Limitar o escopo de autorização de trabalho ao projeto atual para pipelines de lançamento
Proteger o acesso a repositórios em pipelines YAML

Este artigo faz parte de uma série que ajuda você a implementar medidas de segurança para o Azure Pipelines. Para obter mais informações, consulte Secure Azure Pipelines.

Pré-requisitos

Categoria	Requisitos
Azure DevOps	– Implemente recomendações para tornar o Azure DevOps seguro e tornar o Azure Pipelines seguro. – Conhecimento básico do YAML e do Azure Pipelines. Para obter mais informações, consulte Criar seu primeiro pipeline.
Permissões	– Para modificar permissões de pipelines: Membro do grupo Administradores do Projeto. – Para modificar as permissões da organização: membro do grupo Administradores de Coleção de Projetos.

Processo Básico

As etapas a seguir para proteger seus pipelines são semelhantes em todos os pipelines:

Identifique os repositórios Azure Repos aos quais seu pipeline requer acesso dentro da mesma organização, mas em projetos diferentes.
Faça isso inspecionando seu pipeline ou habilitando Limitar o escopo de autorização de trabalho ao projeto atual para pipelines de (não)lançamento e observe quais repositórios seu pipeline falha ao fazer check-out. Os repositórios de submódulos podem não aparecer na primeira execução com falha.
Conceda acesso à identidade de build do pipeline a esse projeto para cada projeto que contém um repositório que seu pipeline precisa acessar.
Conceda à identidade de build do pipeline acesso de leitura a esse repositório para cada repositório que seu pipeline realiza o checkout.
Conceda à identidade de build do pipeline acesso de leitura a esse repositório para cada repositório que é usado como um submódulo por um repositório que seu pipeline faz check-out e está no mesmo projeto.
Habilite Limitar o escopo de autorização de trabalho ao projeto atual para pipelines que não são de lançamento, Limitar o escopo de autorização de trabalho ao projeto atual para pipelines de lançamento e Proteger o acesso a repositórios em pipelines em YAML.

Pipelines de build

Para ilustrar as etapas a serem seguidas para melhorar a segurança de seus pipelines quando eles acessam Azure Repos, usamos o exemplo a seguir.

Suponha que você esteja trabalhando no pipeline SpaceGameWeb hospedado no projetofabrikam-tailspin/SpaceGameWeb, no repositório SpaceGameWeb do Azure Repos.
Seu SpaceGameWeb pipeline faz check-out do SpaceGameWebReact repositório no mesmo projeto e dos FabrikamFiber repositórios e FabrikamChat no fabrikam-tailspin/FabrikamFiber projeto.
O FabrikamFiber repositório usa o FabrikamFiberLib repositório como um submódulo, hospedado no mesmo projeto.
As estruturas de repositório do projeto SpaceGameWeb são semelhantes à captura de tela a seguir.
As estruturas de repositório do projeto FabrikamFiber são semelhantes à captura de tela a seguir.
Imagine que seu projeto não está configurado para usar uma identidade de compilação baseada em projeto ou para proteger o acesso a repositórios em pipelines YAML. Além disso, suponha que você já executou seu pipeline com êxito.

Usar uma identidade de build baseada em projeto para pipelines de build

Durante a execução do pipeline, uma identidade é usada para acessar recursos, como repositórios, conexões de serviço e grupos de variáveis. Os pipelines podem utilizar dois tipos de identidades: nível de projeto e nível de coleção. O primeiro prioriza a segurança, enquanto o último enfatiza a facilidade de uso. Para obter mais informações, consulte as identidades de build com escopo e o escopo de autorização de tarefa.

Para maior segurança, use identidades no nível do projeto ao executar seus pipelines. Essas identidades só podem acessar recursos dentro de seu projeto associado, minimizando o risco de acesso não autorizado por agentes mal-intencionados.

Para configurar o pipeline para usar uma identidade no nível do projeto, habilite a configuração limite o escopo de autorização de trabalho ao projeto atual para pipelines que não são de lançamento.

Em nosso exemplo de execução, quando esse controle de alternância estiver desativado, o pipeline SpaceGameWeb poderá acessar todos os repositórios em todos os projetos. Quando o controle de alternância está ativado, SpaceGameWeb só pode acessar recursos no projeto fabrikam-tailspin/SpaceGameWeb, portanto, somente os repositórios SpaceGameWeb e SpaceGameWebReact.

Se você executar nosso pipeline de exemplo, ao ativar a alternância, o pipeline falhará e os logs de erros informarão remote: TF401019: The Git repository with name or identifier FabrikamChat does not exist or you do not have permissions for the operation you are attempting. e remote: TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.

Para corrigir os problemas de checkout, siga as etapas descritas na seção Processo básico deste artigo.

Além disso, confira explicitamente os repositórios de submódulos antes dos repositórios que os usam. Em nosso exemplo, isso significa o repositório FabrikamFiberLib.

Se você executar nosso pipeline de exemplo, ele será bem-sucedido.

Configuração adicional

Para melhorar ainda mais a segurança ao acessar o Azure Repos, considere habilitar Proteger acesso a repositórios em pipelines YAML.

Pipelines YAML
Pipelines de build clássicos

Suponha que o pipeline SpaceGameWeb seja um pipeline YAML e seu código-fonte YAML seja semelhante ao código a seguir.

trigger:
- main

pool:
  vmImage: ubuntu-latest

resources:
  repositories:
    - repository: SpaceGameWebReact
      name: SpaceGameWeb/SpaceGameWebReact
      type: git
    - repository: FabrikamFiber
      name: FabrikamFiber/FabrikamFiber
      type: git
    - repository: FabrikamChat
      name: FabrikamFiber/FabrikamChat
      type: git

steps:
  - script: echo "Building SpaceGameWeb"
  - checkout: SpaceGameWebReact
  - checkout: FabrikamChat
    condition: always()  
  - checkout: FabrikamFiber
    submodules: true
    condition: always()
  - script: |
      cd FabrikamFiber
      git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" submodule update --recursive --remote
  - script: cat $(Build.Repository.LocalPath)/FabrikamFiber/FabrikamFiberLib/README.md
  - ...

Proteger o acesso a repositórios em pipelines YAML

O Azure DevOps fornece um mecanismo de permissões detalhadas para repositórios do Azure Repos, na forma da configuração Protect access to repositories in YAML pipelines. Essa configuração faz com que um pipeline YAML solicite explicitamente permissão para acessar todos os repositórios do Repositório do Azure, independentemente do projeto ao qual pertencem. Para obter mais informações, consulte repositórios de acesso. Essa configuração não afeta o check-out de outros tipos de repositórios, como os hospedados no GitHub.

Em nosso exemplo em execução, quando essa configuração está ativada, o SpaceGameWeb pipeline pede permissão para acessar o SpaceGameWebReact repositório no fabrikam-tailspin/SpaceGameWeb projeto e os FabrikamFiber repositórios e FabrikamChat no fabrikam-tailspin/FabrikamFiber projeto.

Quando você executa o pipeline de exemplo, ele é semelhante ao exemplo a seguir.

Captura de tela da execução do pipeline do SpaceGameWeb pela primeira vez depois de ativar a opção Proteger o acesso a repositórios em pipelines YAML.

Conceda permissão aos repositórios ou recursos do pipeline.

Captura de tela da solicitação para conceder permissão ao pipeline do SpaceGameWeb para acessar três repositórios.

Seu pipeline é executado, mas falha porque não pode fazer check-out do FabrikamFiberLib repositório como um submódulo do FabrikamFiber. Para resolver esse problema, verifique explicitamente o FabrikamFiberLib, adicionando uma - checkout: git://FabrikamFiber/FabrikamFiberLib etapa, antes da -checkout: FabrikamFiber etapa.

O pipeline de exemplo é bem-sucedido.

Nosso código-fonte final do pipeline YAML se parece com o snippet de código a seguir.

trigger:
- main

pool:
  vmImage: ubuntu-latest

resources:
  repositories:
    - repository: SpaceGameWebReact
      name: SpaceGameWeb/SpaceGameWebReact
      type: git
    - repository: FabrikamFiber
      name: FabrikamFiber/FabrikamFiber
      type: git
    - repository: FabrikamChat
      name: FabrikamFiber/FabrikamChat
      type: git

steps:
  - script: echo "Building SpaceGameWeb"
  - checkout: SpaceGameWebReact
  - checkout: FabrikamChat
    condition: always()  
  - checkout: git://FabrikamFiber/FabrikamFiberLib  
  - checkout: FabrikamFiber
    submodules: true
    condition: always()
  - script: |
      cd FabrikamFiber
      git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" submodule update --recursive --remote
  - script: cat $(Build.Repository.LocalPath)/FabrikamFiber/FabrikamFiberLib/README.md

Solução de problemas

Use as seguintes soluções para quaisquer problemas que surjam.

Você usa o git na linha de comando para fazer check-out de repositórios na mesma organização

Por exemplo, se estiver usando o - script: git clone https://$(System.AccessToken)@dev.azure.com/fabrikam-tailspin/FabrikamFiber/_git/OtherRepo/. O comando falha quando a configuração Proteger acesso a repositórios na configuração de pipelines YAML está ativada.

Para resolver o problema, verifique o OtherRepo repositório usando o checkout comando, como - checkout: git://FabrikamFiber/OtherRepo.

Um repositório está usando outro repositório como submódulo

Digamos que um dos repositórios dos quais o seu pipeline faz check-out use outro repositório (no mesmo projeto) como submódulo, como é o caso em nosso exemplo para os repositórios FabrikamFiber e FabrikamFiberLib. Leia mais sobre como obter submódulos.

Além disso, suponha que você tenha dado à identidade de build SpaceGame acesso de leitura ao repositório, mas o check-out do repositório ainda falhará ao fazer check-out do FabrikamFiber submódulo.

Para resolver esse problema, verifique explicitamente o FabrikamFiberLib, adicionando uma - checkout: git://FabrikamFiber/FabrikamFiberLib etapa antes da -checkout: FabrikamFiber uma.

Em pipelines de build clássicos, você não pode declarar explicitamente outros repositórios como recursos. Confira mais repositórios Azure Repos adicionando tarefas de linha de comando com git clone comandos, semelhantes ao seguinte comando para verificar o FabrikamFiber repositório: git -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" clone --recurse-submodules https://dev.azure.com/silviuandrica/FabrikamFiber/_git/FabrikamFiber.

Proteger o acesso a repositórios na configuração de pipelines do YAML

A configuração Proteger acesso a repositórios em pipelines YAML faz com que um pipeline YAML solicite explicitamente permissão para acessar todos os repositórios do Azure Repos, independentemente de a que projeto pertencem. Para obter mais informações, consulte tokens do Access, Proteger o acesso a repositórios em pipelines YAML.

Tenha cuidado ao ativar a configuração Proteger acesso a repositórios em pipelines YAML. Se você fizer isso, seus pipelines de build clássicos não poderão acessar nenhum outro repositório do Azure DevOps, exceto aquele especificado em suas Configurações. Em nosso pipeline de exemplo, você recebe um erro e a mensagem de log TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.

Se o projeto usar pipelines de build YAML e clássicos e seus pipelines de build clássicos verificarem mais repositórios do Azure DevOps além dos especificados em suas configurações, crie dois projetos, um para os pipelines YAML e outro para pipelines de build clássicos. Em seguida, no projeto de pipelines YAML, habilite a configuração desejada.

A configuração Proteger acesso a repositórios na configuração de pipelines YAML não se aplica a repositórios hospedados em outros serviços, como o GitHub.

A configuração do escopo de autorização do trabalho de compilação

A configuração Limitar o escopo de autorização de trabalho ao projeto atual para pipelines não relacionadas a lançamentos substitui a configuração do escopo de autorização do trabalho de build. Se você ativar o anterior, o pipeline será executado com identidade baseada em projeto, mesmo que o escopo de autorização do trabalho Build especifique a coleção de projetos.

Captura de tela da execução bem-sucedida da configuração de escopo de autorização da tarefa de build.

Pipelines de lançamento clássicos

O processo para proteger o acesso a repositórios para pipelines de release é semelhante ao de pipelines de build.

Para ilustrar as etapas que você precisa seguir, usamos um exemplo em execução. Em nosso exemplo, há um pipeline de lançamento chamado FabrikamFiberDocRelease no projeto fabrikam-tailspin/FabrikamFiberDocRelease. Suponha que o pipeline faça check-out do repositório FabrikamFiber no projeto fabrikam-tailspin/FabrikamFiber, execute um comando para gerar a documentação pública e, em seguida, publique-a em um site. Além disso, imagine que o FabrikamFiber repositório use o FabrikamFiberLib repositório (no mesmo projeto) como um submódulo.

Usar uma identidade de build baseada em projeto para pipelines de lançamento clássicos

Quando um pipeline é executado, ele usa uma identidade para acessar vários recursos, como repositórios, conexões de serviço, grupos de variáveis. Há dois tipos de identidades que um pipeline pode usar: um no nível do projeto e um no nível da coleção. O primeiro oferece melhor segurança. Este último oferece facilidade de uso. Leia mais sobre identidades de build com escopo e escopo de autorização de trabalho.

Recomendamos que você use identidades no nível do projeto para executar seus pipelines. Por padrão, as identidades no nível do projeto só podem acessar recursos no projeto do qual são membros. O uso dessa identidade aprimora a segurança, pois reduz o acesso obtido por uma pessoa mal-intencionada ao sequestrar seu pipeline.

Para fazer com que seu pipeline use uma identidade no nível do projeto, ative a configuração Limitar o escopo de autorização de trabalho para o projeto atual em pipelines de lançamento.

Em nosso exemplo de execução, quando esse controle de alternância estiver desativado, o pipeline de lançamento FabrikamFiberDocRelease poderá acessar todos os repositórios em todos os projetos, incluindo o repositório FabrikamFiber. Quando o controle de alternância está ativado, FabrikamFiberDocRelease só pode acessar recursos no projeto fabrikam-tailspin/FabrikamFiberDocRelease, portanto, o repositório FabrikamFiber torna-se inacessível.

Se você executar nosso pipeline de exemplo, ao ativar a alternância, o pipeline falhará e os logs informarão remote: TF401019: The Git repository with name or identifier FabrikamFiber does not exist or you do not have permissions for the operation you are attempting.

Para corrigir esses problemas, siga as etapas na seção Processo básico deste artigo.

Nosso pipeline de exemplo é bem-sucedido.