Azure Pipelines – Atualização do Sprint 227

Features

• Federação de identidade de carga de trabalho no Azure Pipelines (versão prévia pública)

• Agentes de pipeline podem ser registrados usando Microsoft Entra ID em vez de um PAT

• APIs REST para ambientes

• Impedir execuções de pipeline não intencionais

• Criar repositórios do GitHub com segurança por padrão

• Desativação de sobreposição do status da política de cobertura de código para Failed quando a build está com falha

Federação de identidade de carga de trabalho no Azure Pipelines (versão prévia pública)

Deseja parar de armazenar segredos e certificados em conexões de serviço do Azure? Quer parar de se preocupar em substituir esses segredos sempre que expirarem? Agora estamos anunciando uma versão prévia pública da Federação de Identidade de Carga de Trabalho para conexões de serviço do Azure. A Federação de Identidade de Carga de Trabalho utiliza uma tecnologia padrão do setor, Open ID Connect (OIDC), para simplificar a autenticação entre o Azure Pipelines e o Azure. Em vez de segredos, um assunto de federação é usado para facilitar essa autenticação.

Como parte desse recurso, a conexão de serviço do Azure (ARM) foi atualizada com outro esquema para dar suporte à federação de identidade de workload. Isso permite que as tarefas do Pipeline que usam a conexão de serviço do Azure se autentiquem usando um assunto de federação (sc://<org>/<project>/<service connection name>). Os principais benefícios de usar esse esquema em comparação com os esquemas de autenticação existentes são os seguintes:

• Gerenciamento simplificado: você não deve mais gerar, copiar e armazenar segredos de entidades de serviço no Azure AD para o Azure DevOps. Os segredos usados em outros esquemas de autenticação de conexões de serviço do Azure (por exemplo, entidade de serviço) expiram após um determinado período (dois anos atualmente). Quando eles expiram, os pipelines falham. Você precisa regenerar um novo segredo e atualizar a conexão de serviço. Mudar para a federação de identidade de carga de trabalho elimina a necessidade de gerenciar esses segredos e melhora a experiência geral de criar e gerenciar conexões de serviço.
• Segurança aprimorada: com a federação de identidade de carga de trabalho, não há nenhum segredo persistente envolvido na comunicação entre o Azure Pipelines e o Azure. Como resultado, as tarefas em execução em trabalhos de pipeline não podem vazar nem exfiltrar segredos que tenham acesso aos seus ambientes de produção. Isso tem sido frequentemente uma preocupação para nossos clientes.

Você pode aproveitar esses recursos de duas maneiras:

• Use o novo esquema de federação de identidade de carga de trabalho sempre que você criar uma nova conexão de serviço do Azure. Seguindo em frente, esse será o mecanismo recomendado.
• Converta suas conexões de serviço existentes do Azure (que são baseadas em segredos) para o novo esquema. Você pode executar essa conversão uma conexão de cada vez. O melhor de tudo é que você não precisa modificar nenhum dos pipelines que usam essas conexões de serviço. Eles aplicarão automaticamente o novo esquema depois que você concluir a conversão.

Para criar uma nova conexão de serviço do Azure usando a federação de identidade de carga de trabalho, basta selecionar federação de identidade de carga de trabalho (automática) ou (manual) na experiência de criação da conexão de serviço do Azure:

Para converter uma conexão de serviço do Azure criada anteriormente, selecione a ação "Converter" depois de selecionar a conexão:

Todas as tarefas do Azure incluídas no Azure Pipelines agora dão suporte a esse novo esquema. No entanto, se você estiver usando uma tarefa do Marketplace ou uma tarefa personalizada caseira para implantar no Azure, talvez ela ainda não dê suporte à federação de identidade de carga de trabalho. Nesses casos, pedimos que você atualize sua tarefa para dar suporte à federação de identidade de carga de trabalho para melhorar a segurança. Uma lista completa de tarefas com suporte pode ser encontrada aqui.

Para esta versão prévia, oferecemos suporte à federação de identidade de carga de trabalho somente para conexões de serviço do Azure. Esse esquema não funciona com outros tipos de conexões de serviço. Consulte nossos documentos para obter mais detalhes.

Esta postagem no blog contém mais detalhes.

Agentes de pipeline podem ser registrados usando a ID do Microsoft Entra em vez de um PAT

O agente do Pipeline agora suporta mais argumentos para usar uma Entidade de Serviço ou um usuário para registrar um agente. Você deve conceder acesso à identidade usada ao pool de agentes nas configurações de segurança. Isso remove a necessidade de usar um PAT (Token de Acesso Pessoal) para instalação única de agentes.

Registrar um agente usando um Principal de Serviço

Para usar um "Service Principal" para registrar um agente de Pipelines com o Azure DevOps Services, forneça os seguintes argumentos:

--auth 'SP' --clientid 00001111-aaaa-2222-bbbb-3333cccc4444 --clientsecret --tenantid aaaabbbb-0000-cccc-1111-dddd2222eeee

Usar um Principal de Serviço na extensão de VM do Agente

As VMs do Azure podem ser incluídas em Grupos de Implantação usando uma Extensão de VM. A extensão da VM foi atualizada para usar uma Entidade de Serviço em vez de um PAT para registrar o agente:

"settings": {
  "userServicePrincipal": true     
}
"protectedSettings": {
  "clientId": "[parameters('clientId')]"      
  "clientSecret": "[parameters('clientSecret')]"      
  "tenantId": "[parameters('tenantId')]"      
}

Registrar um agente interativamente usando o fluxo de código do dispositivo

Você pode usar um navegador da Web para concluir facilmente a instalação. Ao executar o script de configuração do agente, insira "AAD" para o tipo de autenticação. O script orientará você pelas próximas etapas, incluindo onde ir na Web e qual código inserir. Depois de inserir seu código na Web, retorne ao console para concluir a configuração do agente.

APIs REST para ambientes

Um ambiente é uma coleção de recursos que podem ser alvos de implantações realizadas a partir de um pipeline. Os ambientes oferecem histórico de implantação, rastreabilidade de confirmações e itens de trabalho, e mecanismos de controle de acesso.

Sabemos que você deseja criar ambientes programaticamente, por isso publicamos a documentação para sua API REST.

Evite execuções involuntárias de pipeline

Hoje, se o pipeline YAML não especificar a seção trigger, ele será executado para quaisquer alterações movidas para seu repositório. Isso pode gerar confusão quanto ao motivo de um pipeline ter sido executado e levar a muitas execuções não intencionais.

Adicionamos uma configuração de Pipelines no nível da organização e do projeto chamada Desabilitar gatilho de CI YAML implícito que permite alterar esse comportamento. Você pode optar por não disparar pipelines se a seção de ativação estiver ausente.

Criar repositórios do GitHub com segurança por padrão

No último sprint, introduzimos um controle centralizado para a criação de PRs de repositórios do GitHub bifurcados.

Com esse sprint, estamos habilitando a opção Securely build pull requests from forked repositories no nível da organização, para novas organizações. As organizações existentes não são afetadas.

Desabilitada a substituição do status da política de cobertura de código para Falha quando a compilação está falhando

Anteriormente, o status da política de cobertura de código era substituído por 'Erro' se a compilação no PR estivesse falhando. Isso foi um obstáculo para alguns de vocês que tinham a compilação como uma verificação opcional e a política de cobertura de código como uma verificação obrigatória para PRs, o que resultou em PRs sendo bloqueados.

Com esse sprint, a política de cobertura de código não será alterada para 'Failed' se o build falhar. Esse recurso será habilitado para todos os clientes.

Próximas etapas

Vá até o Azure DevOps e dê uma olhada.

Como fornecer comentários

Adoraríamos ouvir o que você pensa sobre essas características. Use o menu de ajuda para relatar um problema ou fornecer uma sugestão.

Você também pode receber conselhos e suas perguntas respondidas pela comunidade no Stack Overflow.