Disponibilidade geral da federação de identidades de carga de trabalho para conexões de serviço do Azure Resource Manager

  • Artigo

Temos o prazer de anunciar que a federação de identidade de carga de trabalho agora está disponível no Azure Pipelines! Você pode desfrutar de uma experiência simplificada sem a necessidade de gerenciar segredos e certificados em conexões de serviço do Azure.

Com essa atualização, também estamos visualizando um novo recurso como parte de nossa integração aprimorada do GitHub com o Azure Boards. Agora você pode vincular diretamente a solicitações de pull ou confirmações do GitHub. Chega de alternar entre janelas ou copiar/colar. Basta selecionar o repositório desejado, encontrar a solicitação de pull ou commit de que precisa e vinculá-lo!

Confira as notas de versão para saber mais sobre esses recursos.

Geral

GitHub Advanced Security para Azure DevOps

Azure Boards

Azure Pipelines

Azure Repos

Azure Artifacts

Geral

Aviso final de substituição de credenciais alternativas

As credenciais alternativas foram formalmente preteridas em março de 2020, mas alguns usuários existentes foram adquiridos com o uso contínuo de suas credenciais alternativas existentes. A partir de janeiro de 2024, substituímos totalmente todas as credenciais alternativas. Para evitar possíveis interrupções, mude para um dos mecanismos de autenticação disponíveis que fornecemos, como tokens de acesso pessoal ou identidades gerenciadas.

Rotação de segredos de autoatendimento OAuth do Azure Devops

A cada cinco anos, é essencial atualizar o Segredo do Cliente para seu aplicativo OAuth do Azure DevOps para garantir a geração contínua de tokens de acesso e atualização necessários para utilizar as APIs do Azure DevOps. À medida que o segredo do cliente se aproxima da expiração, agora você pode gerar um novo de forma independente, dando à sua equipe a liberdade de gerenciá-lo sem depender do suporte ao cliente. Essa flexibilidade no agendamento da rotação de segredos minimiza o tempo de interrupção potencial para seus clientes que aguardam uma substituição devido a um segredo expirado.

Captura de tela de Selecione uma geografia.

Procure essa nova funcionalidade em cada uma das páginas do aplicativo Azure DevOps que podem ser acessadas por meio de seu perfil aqui. Saiba mais sobre essa nova etapa em nosso guia OAuth do Azure DevOps.

GitHub Advanced Security para Azure DevOps

Trechos de código agora disponíveis na exibição de detalhes do alerta

A página de detalhes do alerta para alertas de varredura de código e varredura secreta agora mostra snippets de código que marcam uma ou mais linhas de código em que o alerta ocorreu. Para acessar o arquivo original no repositório do Azure DevOps, clique no nome do arquivo acima do snippet de código.

Captura de tela do caminho do middleware que diferencia maiúsculas de minúsculas.

Segredos truncados exibidos na visão geral do alerta

Os últimos seis caracteres truncados de todos os segredos detectados agora são exibidos na tela de visão geral do alerta de segredos. Esse recurso é útil se você tiver várias exposições secretas do mesmo tipo de segredo, permitindo que você identifique rapidamente onde estão determinados segredos.

Captura de tela da lista de alertas secretos.

Mais gravidades de alerta adicionadas para alertas de varredura de código

Agora existem novas gravidades de alerta para resultados de alerta das consultas do CodeQL quality como Error, Warninge gravidades Note . Cada gravidade de alerta de qualidade tem seu próprio selo e cor para denotar gravidades de escala. Você também pode filtrar cada uma dessas gravidades, semelhante à low escala de gravidade para critical alertas de segurança.

Captura de tela da lista de alertas de varredura de código e filtro de gravidade.

Assinatura vinculada do Azure necessária para a habilitação do GitHub Advanced Security para Azure DevOps

Se você habilitou anteriormente a Segurança Avançada para repositórios em uma organização do Azure DevOps sem uma assinatura vinculada do Azure, poderá observar que a Segurança Avançada se desabilitou automaticamente nesses repositórios. Para habilitar novamente a Segurança Avançada, adicione uma assinatura do Azure associada à organização. Para obter mais informações sobre como adicionar ou alterar sua assinatura, consulte Alterar assinatura do Azure.

Atualizações da API de Segurança Avançada

Várias atualizações para as APIs de Segurança Avançada foram lançadas recentemente:

  • A API de Alertas GET agora dá suporte a um novo parâmetro, ModifiedSince, para retornar uma lista incremental de alertas e retornar apenas alertas que foram modificados desde essa data. Para obter mais informações, consulte Alertas - Lista.
  • Há dois novos pontos de extremidade para buscar ou atualizar o status de ativação de Segurança Avançada de uma organização ou projeto. Ambos os pontos de extremidade retornam uma lista de repositórios com a Segurança Avançada habilitada. Para obter mais informações, consulte Organização - Ativação ou Projeto - Ativação.
  • Há dois novos endpoints para buscar uma estimativa de sua contagem de committers ativos para uma organização ou projeto para refletir quanto pode custar o uso estimado do medidor de Segurança Avançada. Para obter mais informações, consulte Estimativa de uso do medidor organizacional ou Estimativa de uso do medidor do projeto.

As permissões de Segurança Avançada agora são exibidas permanentemente

No passado, os três bits de permissão de Segurança Avançada só estariam presentes como permissões atribuíveis por repositório se a Segurança Avançada estivesse habilitada. Agora, essas permissões estão disponíveis por padrão no painel de permissões de Segurança de Repositórios > e podem ser atribuídas sem que a Segurança Avançada esteja habilitada.

Captura de tela das permissões de Segurança Avançada.

Azure Boards

Você tem duas opções para conectar seu item de trabalho a uma solicitação de pull ou confirmação do GitHub. Você pode usar a sintaxe AB# na solicitação de pull ou vinculá-la diretamente do item de trabalho. Hoje, o processo envolve copiar a URL da solicitação pull do GitHub e colá-la ao adicionar um link. Isso requer a abertura de várias janelas e a alternância entre o GitHub e o Azure DevOps.

Neste sprint, temos o prazer de anunciar uma experiência aprimorada ao habilitar a funcionalidade de pesquisa ao vincular a uma solicitação de pull ou confirmação do GitHub. Pesquise e selecione o repositório desejado e faça uma busca detalhada para localizar e vincular à solicitação de pull ou confirmação específica. Não há mais necessidade de várias alterações de janela e copiar/colar (embora você ainda tenha essa opção).

Gif para demonstração adicionar link.

Observação

Esse recurso está disponível apenas na visualização do Hub de novos quadros.

Se você estiver interessado em obter acesso a esse recurso, envie-nos um e-mail diretamente com o nome da sua organização (dev.azure.com/{nome da organização}).

Melhorias no novo hub de quadros

Com esta versão, introduzimos uma série de aprimoramentos na visualização do New Boards Hub, com foco na acessibilidade e no refluxo da página.

Aqui está um exemplo das alterações de refluxo de página que são adaptáveis com zoom de até 400%.

Gif para demonstrar novas melhorias no hub de placas.

Além disso, lançamos aprimoramentos de desempenho nas páginas de formulário de item de trabalho, quadros e listas de pendências. Com essas mudanças, você pode esperar que os novos quadros correspondam aos padrões de desempenho definidos com os quadros antigos.

Controles de desenvolvimento e implantação

Agora removemos os controles de Desenvolvimento e/ou Implantação do item de trabalho, dependendo de como seu projeto está configurado. Por exemplo, você pode definir as configurações do projeto para desativar Repos e/ou Pipelines.

Capturas de tela de serviços de DevOps.

Quando você for para o item de trabalho, os controles de Desenvolvimento e Implantação correspondentes serão ocultados do formulário.

Capturas de tela de trabalhos relacionados.

Se você decidir conectar um repositório GitHub ao Azure Boards, o controle de desenvolvimento para repositórios GitHub será exibido.

Capturas de tela do controle de desenvolvimento .

Azure Pipelines

A federação de identidade de carga de trabalho para conexões de serviço do Azure Resource Manager agora está em disponibilidade geral

Em setembro, anunciamos a capacidade de configurar conexões de serviço do Azure sem usar um segredo. Desde então, muitos clientes adotaram esse recurso e temos o prazer de anunciar que esse recurso agora está disponível para o público em geral.

Se você ainda não estiver usando a federação de identidades de carga de trabalho, poderá aproveitar as conexões de serviço do Azure sem preocupações que não têm segredos expirados das seguintes maneiras:

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

Captura de tela da federação de identidade da carga de trabalho (automática).

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

Captura de tela da ação Converter.

Para converter várias conexões de serviço, você pode usar a automação, por exemplo, este script do PowerShell:

#!/usr/bin/env pwsh
<# 
.SYNOPSIS 
    Convert multiple Azure Resource Manager service connection(s) to use Workload identity federation

.LINK
    https://aka.ms/azdo-rm-workload-identity-conversion

.EXAMPLE
    ./convert_azurerm_service_connection_to_oidc_simple.ps1 -Project <project> -OrganizationUrl https://dev.azure.com/<organization>
#> 
#Requires -Version 7.3

param ( 
    [parameter(Mandatory=$true,HelpMessage="Name of the Azure DevOps Project")]
    [string]
    [ValidateNotNullOrEmpty()]
    $Project,

    [parameter(Mandatory=$true,HelpMessage="Url of the Azure DevOps Organization")]
    [uri]
    [ValidateNotNullOrEmpty()]
    $OrganizationUrl
) 
$apiVersion = "7.1"
$PSNativeCommandArgumentPassing = "Standard" 

#-----------------------------------------------------------
# Log in to Azure
$azdoResource = "499b84ac-1321-427f-aa17-267ca6975798"
az login --allow-no-subscriptions --scope ${azdoResource}/.default
$OrganizationUrl = $OrganizationUrl.ToString().Trim('/')

#-----------------------------------------------------------
# Retrieve the service connection
$getApiUrl = "${OrganizationUrl}/${Project}/_apis/serviceendpoint/endpoints?authSchemes=ServicePrincipal&type=azurerm&includeFailed=false&includeDetails=true&api-version=${apiVersion}"
az rest --resource $azdoResource -u "${getApiUrl} " -m GET --query "sort_by(value[?authorization.scheme=='ServicePrincipal' && data.creationMode=='Automatic' && !(isShared && serviceEndpointProjectReferences[0].projectReference.name!='${Project}')],&name)" -o json `
        | Tee-Object -Variable rawResponse | ConvertFrom-Json | Tee-Object -Variable serviceEndpoints | Format-List | Out-String | Write-Debug
if (!$serviceEndpoints -or ($serviceEndpoints.count-eq 0)) {
    Write-Warning "No convertible service connections found"
    exit 1
}

foreach ($serviceEndpoint in $serviceEndpoints) {
    # Prompt user to confirm conversion
    $choices = @(
        [System.Management.Automation.Host.ChoiceDescription]::new("&Convert", "Converting service connection '$($serviceEndpoint.name)'...")
        [System.Management.Automation.Host.ChoiceDescription]::new("&Skip", "Skipping service connection '$($serviceEndpoint.name)'...")
        [System.Management.Automation.Host.ChoiceDescription]::new("&Exit", "Exit script")
    )
    $prompt = $serviceEndpoint.isShared ? "Convert shared service connection '$($serviceEndpoint.name)'?" : "Convert service connection '$($serviceEndpoint.name)'?"
    $decision = $Host.UI.PromptForChoice([string]::Empty, $prompt, $choices, $serviceEndpoint.isShared ? 1 : 0)

    if ($decision -eq 0) {

        Write-Host "$($choices[$decision].HelpMessage)"
    } elseif ($decision -eq 1) {
        Write-Host "$($PSStyle.Formatting.Warning)$($choices[$decision].HelpMessage)$($PSStyle.Reset)"
        continue 
    } elseif ($decision -ge 2) {
        Write-Host "$($PSStyle.Formatting.Warning)$($choices[$decision].HelpMessage)$($PSStyle.Reset)"
        exit 
    }

    # Prepare request body
    $serviceEndpoint.authorization.scheme = "WorkloadIdentityFederation"
    $serviceEndpoint.data.PSObject.Properties.Remove('revertSchemeDeadline')
    $serviceEndpoint | ConvertTo-Json -Depth 4 | Write-Debug
    $serviceEndpoint | ConvertTo-Json -Depth 4 -Compress | Set-Variable serviceEndpointRequest
    $putApiUrl = "${OrganizationUrl}/${Project}/_apis/serviceendpoint/endpoints/$($serviceEndpoint.id)?operation=ConvertAuthenticationScheme&api-version=${apiVersion}"
    # Convert service connection
    az rest -u "${putApiUrl} " -m PUT -b $serviceEndpointRequest --headers content-type=application/json --resource $azdoResource -o json `
            | ConvertFrom-Json | Set-Variable updatedServiceEndpoint
    
    $updatedServiceEndpoint | ConvertTo-Json -Depth 4 | Write-Debug
    if (!$updatedServiceEndpoint) {
        Write-Debug "Empty response"
        Write-Error "Failed to convert service connection '$($serviceEndpoint.name)'"
        exit 1
    }
    Write-Host "Successfully converted service connection '$($serviceEndpoint.name)'"
}

Para obter mais informações, visite nossa documentação.

O agente do Pipelines mostra problemas de utilização de recursos com mais destaque

Em outubro passado, adicionamos a capacidade de rastrear o uso de memória e espaço em disco pelo agente do Pipelines.

Para conscientizar os clientes de que eles podem ter restrições de recursos, como limitações de memória ou espaço em disco em seu agente, tornamos as restrições de recursos mais visíveis:

Captura de tela do aviso de memória limitada e espaço em disco.

Se você vir qualquer uma das mensagens acima, isso pode ser causado por uma tarefa que usa mais recursos do que o agente está dimensionado, o que pode resultar na não resposta do agente e na falha de um trabalho de pipeline:

"Paramos de ouvir o agente"

Nesses casos, habilite logs detalhados para obter mensagens de utilização de recursos mais refinadas e rastrear onde seu agente ficou sem recursos. Se você estiver usando um agente auto-hospedado, certifique-se de que seu agente tenha recursos adequados.

Instalação fora de banda do executor de tarefas do Nó 6

O Azure Pipelines fornece duas versões de pacotes de agente:

  • Os pacotes vsts-agent-* suportam tarefas usando o Nó 6 para serem executados.
  • pipelines-agent-* não suportam tarefas que requerem o Nó 6 para serem executados.

Os clientes que criam agentes auto-hospedados podem baixá-los na página Versões do agente de pipeline. As versões do Node incluídas com o agente são usadas para executar tarefas. Consulte Versões do executor do nó.

Após o registro do agente, os agentes instalados de pacotes pipelines-agent-* agora baixarão as versões do Node que não estão incluídas no agente e não estão bloqueadas em "Restrições de tarefas" nas configurações da organização. Isso permite que os clientes usem pacotes de agente pipelines-agent-* e controlem a instalação do Nó 6 com "Restrições de tarefa" nas configurações da organização.

Aprovação diferida

As aprovações podem ser usadas para aprovar uma implantação. No entanto, há situações em que a hora em que a aprovação é dada e a hora em que a implantação deve começar não correspondem. Por exemplo, para a implantação específica que você analisa, você sabe que está fora dos limites. Imagine que não pode prosseguir imediatamente, mas deve ocorrer durante a noite.

Para cobrir esses cenários, adicionamos a opção de adiar aprovações para pipelines YAML. Agora, você pode aprovar uma execução de pipeline e especificar quando a aprovação deve ser efetiva.

Captura de tela de aprovar uma execução de pipeline.

Ao selecionar Adiar aprovação, você pode configurar o momento em que a aprovação entra em vigor.

Captura de tela de Adiar aprovação.

Captura de tela de after_approval_deferred.

A aprovação aparece como adiada no painel de verificações. Após o tempo adiado, a aprovação entra em vigor.

A captura de tela da aprovação é efetiva.

Sequenciamento de aprovações e verificações

Com esse sprint, você pode especificar a ordem em que as aprovações e verificações são executadas.

Aprovações e verificações permitem controlar implantações em produção. Por exemplo, você pode especificar que somente pipelines executados no main branch de um repositório têm permissão para usar uma conexão de serviço do ARM de produção. Além disso, você pode exigir aprovação humana e que o sistema passe por uma verificação de desempenho.

Até hoje, todas as aprovações e verificações eram executadas em paralelo, exceto a fechadura exclusiva. Isso significava que, se o processo de implantação exigisse que as verificações de desempenho fossem aprovadas antes que a aprovação manual fosse fornecida, você não poderia impor isso no Azure Pipelines. Você tinha que confiar nas instruções de aprovação e na documentação interna do processo.

Com este sprint, estamos introduzindo o sequenciamento em Aprovações e Verificações. Agora existem cinco categorias de aprovações e verificações:

  1. Verificações estáticas: controle de ramificação, modelo necessário e artefato de avaliação
  2. Verificações pré-dinâmicas Aprovação
  3. Verificações dinâmicas: Aprovação, Invocar Azure Function, Invocar API REST, Horário comercial, Consultar alertas do Azure Monitor
  4. Verificações pós-dinâmicas Aprovação
  5. Bloqueio exclusivo

Captura de tela de adicionar cheque.

A ordem também é mostrada na guia Aprovações e verificações.

Captura de tela da guia de aprovações e cheques.

Dentro de cada categoria, as verificações são executadas em paralelo. Ou seja, se você tiver uma verificação Invocar Função do Azure e uma verificação de horário comercial, elas serão executadas ao mesmo tempo.

Captura de tela das verificações para implantação.

As categorias de verificação são executadas uma a uma e, se uma falhar, o restante das verificações não será executado. Isso significa que, se você tiver uma verificação de controle de ramificação e uma aprovação, se o controle de ramificação falhar, a aprovação também falhará. Portanto, nenhum e-mail desnecessário será enviado.

Captura de tela das verificações de falha na implantação.

Você pode aprovar uma implantação depois que todas as verificações dinâmicas forem executadas, usando uma aprovação de verificações pós-dinâmicas, ou fazer uma validação manual antes de prosseguir com as verificações dinâmicas, usando uma aprovação de verificações pré-dinâmicas.

Validar e salvar por padrão ao editar pipelines YAML

Um pipeline YAML incorreto pode levar ao desperdício de tempo e esforço. Para melhorar a produtividade da edição do pipeline, estamos alterando o botão Salvar no editor para também fazer a validação YAML.

Captura de tela do novo botão.

Captura de tela de validar e salvar.

Se o pipeline tiver erros, você ainda poderá salvá-lo.

A captura de tela do pipeline é válida.

Captura de tela dos erros detectados.

Também melhoramos a experiência de validação , para que você possa ver os erros em uma lista mais fácil de entender.

Captura de tela da lista de erros.

Azure Repos

Prevenção para usuários não autorizados configurarem o pipeline como uma política de build

Prevenção para usuários não autorizados configurarem o pipeline como uma política de build

Anteriormente, quando você adicionava uma nova política de build, podia configurar para executar qualquer pipeline da lista suspensa (incluindo os pipelines para os quais você não tinha permissão de builds de fila). Da mesma forma, você pode editar a política de build existente, mesmo que ela tenha sido configurada para executar o pipeline para o qual você não tinha permissão de build de fila.

Agora estamos impedindo que os usuários façam isso. Se um usuário for negado a permissão de build de fila para determinado pipeline, esse pipeline será mostrado como desabilitado (esmaecido) na lista suspensa ao adicionar uma nova política de build.

Veja a imagem abaixo mostrando o pipeline chamado "Sandbox" com a permissão de builds de fila sendo negada.

Captura de tela das permissões para Sandbox.

Veja a imagem abaixo mostrando o pipeline chamado "Sandbox" desabilitado (esmaecido) na lista suspensa quando o usuário com permissão de builds de fila negada está tentando adicionar uma nova política de build.

Captura de tela de adicionar política de compilação.

Quando a política de build configurada para executar o pipeline chamado "Sandbox" já existir, o usuário sem permissão de builds de fila não poderá editar ou exibir a política de build. Este caso é mostrado na imagem a seguir.

Captura de tela da validação de compilação.

Quando você tenta excluir essa política, a caixa de diálogo pop-up solicitando a confirmação da exclusão será exibida.

Captura de tela da confirmação de exclusão.

Essas alterações também se aplicam a qualquer chamada de API que resulte na criação ou edição da política de compilação. Quando qualquer uma dessas ações for executada usando uma identidade de usuário sem permissão de compilação de fila, a chamada falhará retornando o código de erro apropriado e a mensagem de erro dizendo “TFS.WebApi.Exception: TF401027: Você precisa da permissão QueueBuild neste pipeline para executar esta ação.".

A exclusão de uma política de build feita via API usando uma user identity permissão sem Queue builds será bem-sucedida e não haverá nenhum aviso ou prevenção (nenhuma alteração na forma como a exclusão via API funciona).

Azure Artifacts

O suporte para Rust Crates está disponível para o público em geral

A partir de 16 de fevereiro de 2024, o suporte ao Rust Crates se tornará um recurso em disponibilidade geral para o Azure Artifacts. Os medidores de faturamento serão ativados, usando o mesmo modelo de preços que se aplica aos outros protocolos suportados.

Suporte do Azure Artifacts para auditoria npm

O Azure Artifacts agora dá suporte npm audit a comandos e npm audit fix comandos. Esse recurso permite que os usuários analisem e corrijam as vulnerabilidades de seus projetos atualizando automaticamente as versões de pacotes inseguros. Para saber mais, visite Usar a auditoria npm para detectar e corrigir vulnerabilidades de pacote.

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.

Ir para o Azure DevOps

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.

Fazer uma sugestão

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

Obrigada,

Dan Hellem