Acesso seguro ao Azure Repos a partir de pipelines

Serviços de DevOps do Azure | 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 compilação e do pipeline de versão clássica 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 de não liberação
• Limitar o escopo de autorização de trabalho ao projeto atual para pipelines de liberação
• Proteja o acesso a repositórios em pipelines YAML

Processo Básico

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

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

Construir pipelines

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

• Suponha que você esteja trabalhando no SpaceGameWeb pipeline hospedado no fabrikam-tailspin/SpaceGameWeb projeto, no SpaceGameWeb repositório do Azure Repos.
• Seu SpaceGameWeb pipeline verifica o SpaceGameWebReact repositório no mesmo projeto e os 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 SpaceGameWeb estruturas do repositório do projeto são parecidas com as da captura de tela a seguir.
• As FabrikamFiber estruturas do repositório do projeto são parecidas com as da 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 compilação baseada em projeto para pipelines de compilação

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 segundo enfatiza a facilidade de uso. Para obter mais informações, consulte Identidades de compilação com escopo e escopo de autorização de trabalho.

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 atores mal-intencionados.

Para configurar seu pipeline para usar uma identidade no nível do projeto, habilite a configuração Limitar o escopo de autorização de trabalho ao projeto atual para pipelines sem liberação.

Em nosso exemplo de execução, quando essa alternância está desativada, o SpaceGameWeb pipeline pode acessar todos os repositórios em todos os projetos. Quando a alternância está ativada, SpaceGameWeb só pode acessar recursos no fabrikam-tailspin/SpaceGameWeb projeto, portanto, apenas os SpaceGameWeb e SpaceGameWebReact repositórios.

Se você executar nosso pipeline de exemplo, quando você ativar a alternância, o pipeline falhará e os logs de erro 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, verifique explicitamente os repositórios do submódulo, antes dos repositórios que os usam. No nosso exemplo, significa o FabrikamFiberLib repositório.

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

Configuração adicional

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

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

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

Pipelines de liberação clássicos

O processo para garantir o acesso a repositórios para pipelines de liberação é semelhante ao de pipelines de construção.

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

Usar uma identidade de compilação baseada em projeto para pipelines de versão 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: uma de nível de projeto e uma de nível de coleção. O primeiro proporciona melhor segurança. Este último proporciona facilidade de utilização. Leia mais sobre identidades de compilação 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 melhora 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 ao projeto atual para pipelines de liberação.

Em nosso exemplo de execução, quando essa alternância está desativada, o pipeline de FabrikamFiberDocRelease liberação pode acessar todos os repositórios em todos os projetos, incluindo o FabrikamFiber repositório. Quando a alternância está ativada, FabrikamFiberDocRelease só pode acessar recursos no projeto, de fabrikam-tailspin/FabrikamFiberDocRelease modo que o FabrikamFiber repositório fica inacessível.

Se você executar nosso pipeline de exemplo, quando você ativar a alternância, o pipeline falhará e os logs informarão que você 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.

Artigos relacionados

• Identidades de compilação com escopo
• Escopo da autorização de trabalho
• Conceder acesso à identidade de compilação de um pipeline a um projeto
• Conceder a identidade de compilação de um pipeline Acesso de leitura a um repositório
• Como fazer check-out de submódulos