Federação de identidade de carga de trabalho para visualização pública do Azure Pipelines

Temos o prazer de anunciar que a federação de identidades de carga de trabalho para Pipelines do Azure está agora em pré-visualização pública! As conexões de serviço do Azure (ARM) foram atualizadas com um esquema adicional para dar suporte à federação de identidades de carga de trabalho.

Confira as notas de versão para saber como você pode se inscrever para a visualização pública.

Azure Boards

• Limites para caminhos de área e iteração

Pipelines do Azure

• Federação de identidade de carga de trabalho no Azure Pipelines (visualização pública)

• Os agentes de pipeline podem ser registrados usando o Microsoft Entra ID em vez de um PAT

• APIs REST para ambientes

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

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

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

Repositórios do Azure

• Suporte a filtros sem lobos e sem árvores

Azure Boards

Limites para caminhos de área e iteração

Os limites desempenham um papel importante na manutenção da saúde e da eficiência de um serviço grande e global. Neste sprint, estamos introduzindo limites rígidos de 10.000 por projeto para caminhos de área e iteração. Visite a página Acompanhamento de trabalho, processos e limites de projeto para saber mais sobre os diferentes limites no serviço.

Pipelines do Azure

Federação de identidade de carga de trabalho no Azure Pipelines (visualização pública)

Deseja parar de armazenar segredos e certificados em conexões de serviço do Azure? Quer parar de se preocupar em girar esses segredos sempre que eles expiram? Agora estamos anunciando uma visualização pública da Federação de Identidade de Carga de Trabalho para conexões de serviço do Azure.A federação de identidades de carga de trabalho usa 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, é utilizado um requerente de federação para facilitar esta 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 identidades de carga de trabalho. Isso permite que as tarefas de 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 da utilização deste esquema em relação aos sistemas de autenticação existentes são os seguintes:

• Gerenciamento simplificado: você não pode 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 expiram, os oleodutos falham. Você tem que regenerar um novo segredo e atualizar a conexão de serviço. Mudar para a federação de identidades de carga de trabalho elimina a necessidade de gerenciar esses segredos e melhora a experiência geral de criação e gerenciamento de conexões de serviço.
• Segurança aprimorada: com a federação de identidades 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 executadas em trabalhos de pipeline não podem vazar ou exfiltrar segredos que tenham acesso aos seus ambientes de produção. Esta tem sido muitas vezes uma preocupação para os 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 criar uma nova conexão de serviço do Azure. No futuro, este 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 assim 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 de 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 interna para implantar no Azure, talvez ela ainda não ofereça suporte à federação de identidades de carga de trabalho. Nesses casos, pedimos que você atualize sua tarefa para dar suporte à federação de identidades de carga de trabalho para melhorar a segurança. Uma lista completa das tarefas suportadas pode ser encontrada aqui.

Para esta visualização, damos suporte à federação de identidade de carga de trabalho somente para conexões de serviço do Azure. Esse esquema não funciona com nenhum outro tipo de conexão de serviço. Consulte os nossos documentos para mais detalhes.

Esta postagem no blog contém mais detalhes.

Os agentes de pipeline podem ser registrados usando o Microsoft Entra ID em vez de um PAT

O agente de pipeline agora oferece suporte a mais argumentos para usar uma entidade de serviço ou um usuário para registrar um agente. Você deve conceder à identidade usada acesso ao pool de agentes em suas configurações de segurança. Isso elimina a necessidade de usar um token de acesso pessoal (PAT) para a configuração única de agentes.

Registrar um agente usando uma entidade de serviço

Para usar uma Entidade de Serviço para registrar um agente de Pipelines com os Serviços de DevOps do Azure, forneça os seguintes argumentos:

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

Usar uma entidade 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 VM foi atualizada para usar uma entidade de serviço em vez de uma 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 configuração. Ao executar o script de configuração do agente, digite "AAD" para o tipo de autenticação. O script irá guiá-lo através das próximas etapas, incluindo onde ir na Web e qual código inserir. Depois de inserir o 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 você pode direcionar com implantações de um pipeline. Os ambientes fornecem histórico de implantação, rastreabilidade para itens de trabalho e confirmações e mecanismos de controle de acesso.

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

Impedir execuções não intencionais de pipeline

Hoje, se o pipeline do YAML não especificar uma trigger seção, ele será executado para quaisquer alterações enviadas por push para seu repositório. Isso pode criar confusão sobre por que um gasoduto funcionou 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 YAML CI implícito que permite alterar esse comportamento. Você pode optar por não acionar pipelines se sua seção de gatilho estiver ausente.

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

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

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

Substituição desabilitada 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 'Falha' se sua compilação no PR estivesse falhando. Este foi um bloqueador 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 RPs, resultando em RPs sendo bloqueados.

Com este sprint, a política de cobertura de código não será substituída por 'Falha' se a compilação falhar. Este recurso será habilitado para todos os clientes.

Repositórios do Azure

Suporte a filtros sem lobos e sem árvores

O Azure DevOps agora dá suporte a duas filtragens adicionais durante a clonagem/busca. São eles: --filter=blob:none e ainda --filter=tree:0 A primeira opção (clone sem blob) é melhor usada para desenvolvimento regular, enquanto a segunda opção (clone sem árvore) se encaixa melhor para os casos em que você descarta o clone depois, por exemplo, executando uma compilação.

Próximos passos

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

Como fornecer feedback

Gostaríamos muito de ouvir o que você pensa sobre esses recursos. Use o menu Ajuda para relatar um problema ou fornecer uma sugestão.

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

Obrigado,

Silviu Andrica