Azure Pipelines - Atualização da Sprint 227
Recursos
Federação de identidades de carga de trabalho no Azure Pipelines (visualização pública)
Os agentes de pipeline podem ser registrados usando a ID do Microsoft Entra em vez de um PAT
Federação de identidades 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 expirarem? Agora estamos anunciando uma visualização pública da Federação de Identidades 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, o 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 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 precisa 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 dutos falham. Você precisa gerar novamente um novo segredo e atualizar a conexão de serviço. A mudança 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á 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 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 identidades de carga de trabalho sempre que criar uma nova conexão de serviço do Azure. Daqui para 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 por 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 identidades de carga de trabalho, basta selecionar Federação de identidades 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, solicitamos que você atualize sua tarefa para dar suporte à federação de identidades de carga de trabalho para melhorar a segurança. Uma lista completa de tarefas suportadas pode ser encontrada aqui.
Para essa visualização, oferecemos suporte à federação de identidades de carga de trabalho apenas para conexões de serviço do Azure. Esse esquema não funciona com nenhum outro tipo de conexão de serviço. Consulte nossos documentos para mais detalhes.
Esta postagem de blog contém mais detalhes.
Os agentes de pipeline podem ser registrados usando a ID do Microsoft Entra 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 Personal Access Token (PAT) para 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 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 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 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 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 a 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 pipeline foi executado e levar a muitas execuções não intencionais.
Adicionamos uma configuração de Pipelines em nível de organização e projeto chamada Disable implied YAML CI trigger 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 sprint passado, introduzimos um controle centralizado para a construção de PRs a partir de repositórios bifurcados do GitHub.
Com este sprint, estamos habilitando a Securely build pull requests from forked repositories opção no 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 em PR estivesse falhando. Isso 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 necessária para PRs, resultando em PRs sendo bloqueados.
Com esse sprint, a política de cobertura de código não será substituída por 'Falhou' se a compilação falhar. Esse recurso será habilitado para todos os clientes.
Próximas etapas
Observação
Esses recursos serão lançados nas próximas duas a três semanas.
Vá até o Azure DevOps e dê uma olhada.
Como fornecer comentários
Adoraríamos ouvir o que você pensa sobre esses recursos. 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.