Compartilhar via

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

  • Artigo

Temos o prazer de anunciar que a federação de identidades de carga de trabalho agora está disponível para o público geral 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 esta 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 pull ou confirmações do GitHub. Chega de alternar entre janelas ou copiar/colar. Basta selecionar o repositório desejado, encontrar a solicitação pull ou commit que você 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 autorizados com o uso contínuo de suas credenciais alternativas existentes. A partir de janeiro de 2024, eliminamos 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 secreta de autoatendimento do OAuth do Azure Devops

A cada cinco anos, é essencial atualizar o Segredo do Cliente para seu aplicativo OAuth de DevOps do Azure, para garantir a geração contínua de tokens de acesso e atualização necessários para utilizar as APIs de DevOps do Azure. À medida que seu Segredo do Cliente se aproxima da expiração, agora você pode gerar um novo de forma independente, fornecendo à sua equipe a liberdade de gerenciá-lo sem depender do suporte ao cliente. Essa flexibilidade no agendamento de rotação secreta 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 do seu perfil aqui. Saiba mais sobre essa nova etapa em nosso guia OAuth de DevOps do Azure.

GitHub Advanced Security para Azure DevOps

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

A página de detalhes do alerta para verificação de código e alertas de varredura secreta agora mostra trechos de código que marcam uma ou mais linhas de código onde o alerta ocorreu. Para ir para o arquivo original em seu repositório de DevOps do Azure, clique no nome do arquivo acima do trecho 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 quaisquer 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 secreto, permitindo que você identifique rapidamente onde determinados segredos vivem.

Captura de tela da lista de alertas secretos.

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

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

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

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

Se você habilitou anteriormente a Segurança Avançada para repositórios em uma organização de DevOps do Azure sem uma assinatura vinculada do Azure, poderá notar que a Segurança Avançada se desabilitou automaticamente nesses repositórios. Para reabilitar 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 avançadas da API de segurança

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

  • A API de Alertas GET agora oferece 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 habilitaçã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 - Habilitação ou Projeto - Habilitação.
  • Há dois novos pontos de extremidade para obter uma estimativa da contagem de committer ativos de uma organização ou projeto para refletir o custo estimado do uso 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 de 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 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 com uma solicitação pull ou confirmação do GitHub. Você pode usar a sintaxe AB# na solicitação 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 abrir várias janelas e alternar 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 pull ou confirmação do GitHub. Pesquise e selecione o repositório desejado e faça drill down para localizar e vincular à solicitação ou confirmação pull 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 demo adicionar link.

Observação

Esse recurso só está disponível na visualização do Hub Novas Placas.

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

Melhorias no hub de novas placas

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

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

Gif para demonstrar novas melhorias no hub de placas.

Além disso, implementamos 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 as Novas Placas correspondam aos padrões de desempenho definidos com as Placas Antigas.

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 Repositórios 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 do GitHub às Placas do Azure, o controle de Desenvolvimento para repositórios do GitHub será exibido.

Screenshots de controle de desenvolvimento.

Azure Pipelines

A federação de identidades de carga de trabalho para conexões de serviço do Gerenciador de Recursos do Azure agora está disponível para o público 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 expirantes das seguintes maneiras:

Para criar uma nova conexão de serviço do Azure usando a federação de identidades de carga de trabalho, selecione Federação de identidades 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 identidades de 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 mais informações, visite nossa documentação.

O agente Pipelines mostra os 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 Pipelines.

Para conscientizar os clientes, 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 usando mais recursos do que o agente está dimensionado para o qual pode resultar em o agente não responder e falhar em 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 rastreie onde seu agente ficou sem recursos. Se você estiver usando um agente auto-hospedado, verifique se o agente tem 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 execução.
  • Os pacotes pipelines-agent-* não oferecem suporte a tarefas que exigem a execução do Nó 6.

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

Após o registro do agente, os agentes instalados a partir de pacotes pipelines-agent-* agora baixarão versões do Nó que não estão incluídas no agente e não estão bloqueadas em 'Restrições de tarefa' 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 adiada

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 coincidem. 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 a hora 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ção. Após o adiamento, a aprovação passa a valer.

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

Aprovações e verificações de sequenciamento

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 os pipelines executados na main ramificação de um repositório tenham permissão para usar uma conexão de serviço 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 corriam em paralelo, com exceção do bloqueio exclusivo. Isso significava que, se o processo de implantação exigisse que as verificações de desempenho fossem aprovadas antes da aprovação manual, você não poderia impor isso no Azure Pipelines. Você tinha que confiar nas instruções de aprovação e na documentação do processo interno.

Com este sprint, estamos introduzindo o sequenciamento em Aprovações e Verificações. Existem agora 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 da verificação de adição.

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

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

Dentro de cada categoria, as verificações são executadas em paralelo. Ou seja, se você tiver uma verificação Invoke Azure Function 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á executada. 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á. Assim, 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 de edição do pipeline, estamos alterando o botão Salvar no editor para também fazer a validação do 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 Validar , 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 Compilação

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

Anteriormente, quando você adicionava uma nova política de compilação, podia configurar para executar qualquer pipeline na lista suspensa (incluindo os pipelines para os quais você não tinha permissão para compilações de fila). Da mesma forma, você poderia editar a política de compilação existente mesmo que ela estivesse configurada para executar o pipeline para o qual você não tinha permissão de compilações de fila.

Agora estamos impedindo que os usuários façam isso. Se um usuário tiver a permissão Queue builds negada para determinado pipeline, esse pipeline será mostrado como desabilitado (acinzentado) na lista suspensa ao adicionar nova política de compilação.

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

Captura de tela das permissões para Sandbox.

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

Captura de tela da política de compilação de adição.

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

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

Quando o usuário tentar excluir essa política, a caixa de diálogo pop-up solicitando a confirmação de exclusão será exibida.

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

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

A exclusão de uma política de compilação feita via API usando uma user identity permissão de compilações sem fila será bem-sucedida e não haverá aviso ou prevenção (nenhuma alteração em como a exclusão via API funciona).

Azure Artifacts

Suporte para caixas de ferrugem está disponível para o público em geral

A partir de 16 de fevereiro de 2024, o suporte a Rust Crates se tornará um recurso disponível 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

Os Artefatos do Azure agora oferecem suporte npm audit e npm audit fix comandos. Esse recurso permite que os usuários analisem e corrijam as vulnerabilidades de seus projetos atualizando automaticamente versões inseguras de pacotes. Para saber mais, visite, Use 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