Recursos de pipeline

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

O Azure Pipelines oferece segurança além de apenas proteger o arquivo YAML e o código-fonte. Quando os pipelines YAML são executados, o acesso aos recursos passa por um sistema chamado verificações. As verificações podem suspender ou até mesmo falhar uma execução de pipeline para manter os recursos seguros. Um pipeline pode acessar dois tipos de recursos, protegidos e abertos.

Recursos protegidos

Seus pipelines geralmente têm acesso a segredos. Por exemplo, para assinar seu build, você precisa de um certificado de assinatura. Para implantar em um ambiente de produção, você precisa de uma credencial para esse ambiente. O Azure Pipelines requer a função administrador ao abrir o acesso a um recurso para todos os pipelines para todos os recursos protegidos, exceto para Ambientes. Para Ambientes, você precisará da função Criador . Saiba mais sobre a proteção de recursos.
No Azure Pipelines, todos os seguintes são considerados recursos protegidos em pipelines do YAML:

• Pools de agentes
• Variáveis secretas em grupos de variáveis
• Arquivos seguros
• Conexões de serviço
• Ambientes
• Repositórios

"Protegido" significa:

• Eles podem ser acessíveis a usuários específicos e pipelines específicos dentro do projeto. Eles não podem ser acessados por usuários e pipelines fora de um projeto.
• Você pode executar outras verificações manuais ou automatizadas sempre que um pipeline do YAML usa um desses recursos. Para saber mais sobre recursos protegidos, confira Sobre recursos de pipeline.

Como proteger recursos do repositório

Opcionalmente, os repositórios podem ser protegidos. No nível da organização ou do projeto, você pode optar por limitar o escopo do token de acesso do Azure Pipelines aos repositórios mencionados. Quando você fizer isso, o Azure Pipelines adicionará mais duas proteções:

• O token de acesso fornecido ao agente para executar trabalhos só terá acesso a repositórios explicitamente mencionados na seção resources do pipeline.
• Os repositórios adicionados ao pipeline precisarão ser autorizados por alguém com acesso de contribuição ao repositório na primeira vez que o pipeline usar o repositório.

Essa configuração está ativada por padrão para todas as organizações criadas após maio de 2020. As organizações criadas antes disso devem habilitá-la nas configurações da organização.

Abrir recursos

Todos os outros recursos em um projeto são considerados recursos abertos. Os recursos abertos incluem:

• Artifacts
• Pipelines
• Planos de teste
• Itens de trabalho

Você aprenderá mais sobre quais pipelines podem acessar quais recursos na seção sobre projetos.

Permissões de usuário

A primeira linha de defesa para recursos protegidos são as permissões do usuário. Em geral, verifique se você só concede permissões aos usuários que precisam delas. Todos os recursos protegidos têm um modelo de segurança semelhante. Um membro da função de usuário para um recurso pode:

• Remover aprovadores e verificações configuradas nesse recurso
• Conceder acesso a outros usuários ou pipelines para usar esse recurso

Permissões de pipeline

Quando você usa pipelines YAML, as permissões de usuário não são suficientes para proteger seus recursos protegidos. Você pode copiar facilmente o nome de um recurso protegido (por exemplo, uma conexão de serviço para seu ambiente de produção) e incluí-lo em um pipeline diferente. As permissões de pipeline protegem contra essa cópia. Para cada um dos recursos protegidos, verifique se você desabilitou a opção de conceder acesso a "todos os pipelines". Em vez disso, concedeu explicitamente acesso a pipelines específicos em que você confia.

Verificações

No YAML, uma combinação de permissões de usuário e pipeline não é suficiente para proteger totalmente seus recursos protegidos. As permissões de pipeline para recursos são concedidas a todo o pipeline. Nada impede que um adversário crie outro branch em seu repositório, injete código mal-intencionado e use o mesmo pipeline para acessar esse recurso. Mesmo sem intenção mal-intencionada, a maioria dos pipelines precisa de um segundo conjunto de olhares sobre as alterações (especialmente para o próprio pipeline) antes de implantar em produção. As verificações permitem pausar a execução de pipeline até que determinadas condições sejam atendidas:

• Marcar de aprovação manual. Cada execução que usa um recurso protegido por projeto é bloqueada para sua aprovação manual antes de prosseguir. A proteção manual oferece a oportunidade de examinar o código e garantir que ele venha do branch certo.
• Verificação de branch protegido. Se você tiver processos manuais de revisão de código em vigor para alguns de seus branches, poderá estender essa proteção para pipelines. Configure uma verificação de branch protegido em cada um de seus recursos. Isso impedirá automaticamente a execução do pipeline em quaisquer branches de usuário.
• Verificação de recurso protegidos Você pode adicionar verificações a ambientes, conexões de serviço, repositórios, grupos de variáveis, pools de agentes, grupos de variáveis e arquivos seguros para especificar condições que devem ser atendidas antes que uma fase em qualquer pipeline possa consumir um recurso. Saiba mais sobre verificações e aprovações.

Próximas etapas

Em seguida, considere como agrupar recursos em uma estrutura de projeto.