Compartilhar via

Acesso seguro de pipelines ao Azure Repos

  • Artigo

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 lançamento clássico ao acessar 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 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

Processo Básico

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

  1. 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 habilite 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 não consegue verificar. Os repositórios de submódulo podem não aparecer na primeira execução com falha.
  2. Conceda acesso à identidade de build do pipeline a esse projeto para cada projeto que contenha um repositório que seu pipeline precisa acessar.
  3. Conceda à identidade de build do pipeline acesso de leitura a esse repositório para cada repositório que o pipeline fizer check-out.
  4. Conceda à identidade de build 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 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 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. Captura de tela da estrutura do repositório SpaceGameWeb.
  • As estruturas do repositório do projeto FabrikamFiber são semelhantes à captura de tela a seguir. Captura de tela da estrutura do repositório FabrikamFiber.
  • 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 identidades de build 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 agentes mal-intencionados.

Para configurar o 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 de não 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, verifique explicitamente os repositórios do submódulo, antes dos repositórios que os utilizam. 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 Azure Repos, considere habilitar Proteger o acesso a repositórios em pipelines YAML.

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 para o Azure Repos na forma de Proteger acesso a repositórios na configuração de pipelines YAML. Essa configuração faz com que um pipeline YAML solicite explicitamente permissão para acessar todos os repositórios do Azure Repos, independentemente de a qual projeto eles 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 o controle de alternância Proteger 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 ao pipeline do SpaceGameWeb permissão 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 o acesso a repositórios em 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 fazer check-out de submódulos.

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

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

Pipelines de lançamento clássicos

O processo para proteger o acesso a repositórios para pipelines de lançamento é 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 o pipeline use uma identidade no nível do projeto, ative a configuração Limitar escopo de autorização de trabalho ao projeto atual para 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.