Partager via

Disponibilité générale de la fédération des identités de charge de travail pour les connexions de service Azure Resource Manager

  • Article

Nous sommes heureux d’annoncer que la fédération des identités de charge de travail est désormais en disponibilité générale dans Azure Pipelines ! Vous pouvez bénéficier d’une expérience simplifiée sans avoir à gérer les secrets et les certificats dans les connexions de service Azure.

Avec cette mise à jour, nous préversions également une nouvelle fonctionnalité dans le cadre de notre intégration améliorée de GitHub à Azure Boards. Vous pouvez maintenant lier directement des demandes ou des validations de tirage GitHub. Il n’y a plus de basculement entre les fenêtres ou le copier/coller. Sélectionnez simplement le référentiel souhaité, recherchez la demande de tirage ou la validation dont vous avez besoin, puis liez-la !

Consultez les notes de publication pour en savoir plus sur ces fonctionnalités.

Général

GitHub Advanced Security pour Azure DevOps

Azure Boards

Azure Pipelines

Azure Repos

Azure Artifacts

Général

Avis final de dépréciation des autres informations d’identification

D’autres informations d’identification ont été officiellement dépréciées en mars 2020, mais certains utilisateurs existants ont été dotés d’une utilisation continue de leurs autres informations d’identification existantes. Depuis janvier 2024, nous avons entièrement déprécié toutes les autres informations d’identification. Pour éviter toute interruption potentielle, passez à l’un des mécanismes d’authentification disponibles que nous fournissons, tels que les jetons d’accès personnels ou les identités managées.

Rotation des secrets en libre-service Azure Devops OAuth

Tous les cinq ans, il est essentiel de mettre à jour la clé secrète client pour votre application Azure DevOps OAuth, afin de garantir la génération continue des jetons d’accès et d’actualisation nécessaires à l’utilisation des API Azure DevOps. Au fur et à mesure que votre clé secrète client approche l’expiration, vous pouvez désormais en générer une nouvelle, en fournissant à votre équipe la liberté de la gérer sans compter sur le support client. Cette flexibilité dans la planification de la rotation des secrets réduit le temps de panne potentiel pour vos clients en attente d’un remplacement en raison d’un secret expiré.

Capture d’écran de Sélectionner une zone géographique.

Recherchez cette nouvelle fonctionnalité dans chacune de vos pages d’application Azure DevOps qui peuvent être accessibles via votre profil ici. En savoir plus sur cette nouvelle étape dans notre guide Azure DevOps OAuth.

GitHub Advanced Security pour Azure DevOps

Extraits de code désormais disponibles en mode Détails de l’alerte

La page de détails de l’alerte pour l’analyse du code et les alertes d’analyse des secrets affiche désormais des extraits de code qui marquent une ou plusieurs lignes de code où l’alerte s’est produite. Pour accéder au fichier d’origine dans votre référentiel Azure DevOps, cliquez sur le nom du fichier au-dessus de l’extrait de code.

Capture d’écran du chemin d’accès du middleware sensible à la casse.

Secrets tronqués affichés dans la vue d’ensemble de l’alerte

Les six derniers caractères des secrets détectés sont désormais affichés dans l’écran vue d’ensemble de l’alerte secrets. Cette fonctionnalité est utile si vous avez plusieurs expositions secrètes du même type de secret, ce qui vous permet d’identifier rapidement l’endroit où des secrets particuliers vivent.

Capture d’écran de la liste des alertes secrètes.

Plus de gravités d’alerte ajoutées pour les alertes d’analyse du code

Les nouvelles gravités d’alerte existent maintenant pour les résultats d’alerte des requêtes CodeQL quality en tant que Error, Warninget Note les gravités. Chaque gravité d’alerte de qualité a son propre badge et sa couleur pour indiquer les gravités de mise à l’échelle. Vous pouvez également filtrer chacune de ces gravités, comme l’échelle low critical de gravité pour les alertes de sécurité.

Capture d’écran du filtre de gravité et liste des alertes d’analyse du code.

Abonnement Azure lié requis pour GitHub Advanced Security pour l’activation d’Azure DevOps

Si vous avez précédemment activé Advanced Security pour les dépôts dans une organisation Azure DevOps sans abonnement Azure lié, vous remarquerez peut-être que Advanced Security s’est automatiquement désactivé sur ces référentiels. Pour réactiver Advanced Security, ajoutez un abonnement Azure associé à l’organisation. Pour plus d’informations sur l’ajout ou la modification de votre abonnement, consultez Modifier l’abonnement Azure.

Mises à jour avancées API de sécurité

Différentes mises à jour des API de sécurité avancées récemment livrées :

  • L’API GET Alerts prend désormais en charge un nouveau paramètre, ModifiedSincepour renvoyer une liste incrémentielle d’alertes et renvoyer uniquement les alertes qui ont été modifiées depuis cette date. Pour plus d’informations, consultez Alertes - Liste.
  • Il existe deux nouveaux points de terminaison pour récupérer ou mettre à jour l’état d’activation advanced security d’une organisation ou d’un projet. Les deux points de terminaison retournent une liste de référentiels avec Advanced Security activé. Pour plus d’informations, consultez Org - Enablement ou Project - Enablement.
  • Il existe deux nouveaux points de terminaison pour extraire une estimation du nombre de commiteurs actifs d’une organisation ou d’un projet afin de refléter l’utilisation estimée du compteur Advanced Security. Pour plus d’informations, consultez l’estimation de l’utilisation du compteur d’organisation ou l’estimation de l’utilisation du compteur de projet.

Les autorisations avancées de sécurité sont désormais affichées définitivement

Dans le passé, les trois bits d’autorisation Advanced Security ne seraient présents que comme autorisations assignables par dépôt si Advanced Security était activé. À présent, ces autorisations sont disponibles par défaut dans le volet Autorisations de sécurité des référentiels > et peuvent être affectées sans activer Advanced Security.

Capture d’écran des autorisations avancées de sécurité.

Azure Boards

Vous avez deux options pour connecter votre élément de travail avec une demande de tirage ou une validation GitHub. Vous pouvez utiliser la syntaxe AB# dans la demande de tirage ou la lier directement à partir de l’élément de travail. Aujourd’hui, le processus implique de copier l’URL de la demande de tirage GitHub et de la coller lors de l’ajout d’un lien. Cela nécessite l’ouverture de plusieurs fenêtres et le basculement entre GitHub et Azure DevOps.

Dans ce sprint, nous sommes heureux d’annoncer une expérience améliorée en activant la fonctionnalité de recherche lors de la liaison à une demande de tirage ou à une validation GitHub. Recherchez et sélectionnez le référentiel souhaité, puis explorez-le pour rechercher et lier à la demande ou à la validation de tirage spécifique. Il n’est plus nécessaire de modifier plusieurs fenêtres et de copier-coller (même si vous avez toujours cette option).

Gif pour la démonstration ajouter un lien.

Remarque

Cette fonctionnalité est disponible uniquement dans la préversion du New Boards Hub.

Si vous souhaitez obtenir l’accès à cette fonctionnalité, envoyez-nous un e-mail directement avec le nom de votre organisation (dev.azure.com/{nom de l’organisation}).

Améliorations apportées aux nouveaux hubs de tableaux

Avec cette version, nous avons introduit une gamme d’améliorations apportées à la préversion du New Boards Hub, en mettant l’accent sur l’accessibilité et le reflow de page.

Voici un exemple de changement de flux de pages qui sont adaptatifs jusqu’à 400 % de zoom.

Gif pour démonstration de nouvelles améliorations du hub de tableaux.

En outre, nous avons déployé des améliorations de performances dans les pages de formulaires, de tableaux et de backlogs d’éléments de travail. Avec ces modifications, vous pouvez vous attendre à ce que les nouveaux tableaux correspondent aux normes de performances définies avec les anciens tableaux.

Contrôles de développement et de déploiement

Nous supprimons maintenant les contrôles développement et/ou déploiement de l’élément de travail, en fonction de la configuration de votre projet. Par exemple, vous pouvez configurer vos paramètres de projet pour désactiver repos et/ou pipelines.

Captures d’écran des services DevOps.

Lorsque vous accédez à l’élément de travail, les contrôles de développement et de déploiement correspondants sont masqués du formulaire.

Captures d’écran du travail associé.

Si vous décidez de connecter un dépôt GitHub à Azure Boards, le contrôle de développement pour les dépôts GitHub s’affiche.

Captures d’écran du contrôle de développement .

Azure Pipelines

La fédération des identités de charge de travail pour les connexions de service Azure Resource Manager est désormais en disponibilité générale

En septembre, nous avons annoncé la possibilité de configurer des connexions de service Azure sans utiliser de secret. Depuis lors, de nombreux clients ont adopté cette fonctionnalité et nous sommes heureux d’annoncer que cette fonctionnalité est désormais en disponibilité générale.

Si vous n’utilisez pas encore la fédération des identités de charge de travail, vous pouvez tirer parti des connexions de service Azure sans souci qui n’ont pas de secrets arrivant à expiration de la manière suivante :

Pour créer une connexion de service Azure à l’aide de la fédération d’identité de charge de travail, sélectionnez Fédération des identités de charge de travail (automatique) dans l’expérience de création de connexion de service Azure :

Capture d’écran de la fédération des identités de charge de travail (automatique).

Pour convertir une connexion de service Azure créée précédemment, sélectionnez l’action « Convertir » après avoir sélectionné la connexion :

Capture d’écran de l’action Convertir.

Pour convertir plusieurs connexions de service, vous pouvez utiliser l’automatisation, par exemple, ce script 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)'"
}

Pour plus d’informations, consultez notre documentation.

L’agent Pipelines présente des problèmes d’utilisation des ressources plus en évidence

En octobre dernier , nous avons ajouté la possibilité de suivre l’utilisation de la mémoire et de l’espace disque par l’agent Pipelines.

Pour rendre les clients conscients, ils peuvent avoir des contraintes de ressources telles que la mémoire ou les limitations de l’espace disque sur leur agent, nous avons rendu les contraintes de ressources plus visibles :

Capture d’écran de l’avertissement de mémoire limitée et d’espace disque.

Si vous voyez l’un des messages ci-dessus, cela peut être dû à une tâche utilisant plus de ressources que l’agent est dimensionné, ce qui peut entraîner la réactivité de l’agent et l’échec d’un travail de pipeline :

« Nous avons cessé d’entendre l’agent »

Dans ce cas, activez les journaux détaillés pour obtenir des messages d’utilisation des ressources plus précis et suivre l’emplacement où votre agent a dépassé les ressources. Si vous utilisez un agent auto-hébergé, vérifiez que votre agent dispose de ressources adéquates.

Installation hors bande de l’exécuteur de tâches Node 6

Azure Pipelines fournit deux versions de packages d’agent :

  • Les packages vsts-agent-* prennent en charge les tâches à l’aide de Node 6 pour s’exécuter.
  • Les packages pipelines-agent-* ne prennent pas en charge les tâches qui nécessitent l’exécution de Node 6.

Les clients qui créent des agents auto-hébergés peuvent les télécharger à partir de la page mises en production de l’agent pipeline. Les versions de Nœud incluses avec l’agent sont utilisées pour exécuter des tâches. Consultez les versions de Node Runner.

Après l’inscription de l’agent, les agents installés à partir de packages pipelines-agent-* téléchargent désormais les versions de Nœud qui ne sont pas incluses dans l’agent et qui ne sont pas bloquées sous « Restrictions de tâche » dans les paramètres de l’organisation. Cela permet aux clients d’utiliser des packages d’agent pipelines-agent-* et de contrôler l’installation de Node 6 avec des « restrictions de tâche » dans les paramètres de l’organisation.

Approbation différée

Les approbations peuvent être utilisées pour se déconnecter d’un déploiement. Toutefois, il existe des situations où l’heure à laquelle l’approbation est donnée et l’heure à laquelle le déploiement doit commencer ne correspond pas. Par exemple, pour le déploiement particulier que vous passez en revue, vous savez qu’il s’agit d’un déploiement hors limites. Imaginez qu’il ne peut pas continuer immédiatement, plutôt qu’il devrait avoir lieu pendant la nuit.

Pour couvrir ces scénarios, nous avons ajouté la possibilité de différer les approbations pour les pipelines YAML. À présent, vous pouvez approuver une exécution de pipeline et spécifier quand l’approbation doit être effective.

Capture d’écran de l’approbation d’une exécution de pipeline.

Lorsque vous sélectionnez Différer l’approbation, vous pouvez configurer l’heure à laquelle l’approbation devient effective.

Capture d’écran de report de l’approbation.

Capture d’écran de after_approval_deferred.

L’approbation s’affiche comme différée dans le volet de vérifications. Une fois le délai différé, l’approbation est effective.

Capture d’écran de l’approbation effective.

Séquencement des approbations et vérifications

Avec ce sprint, vous pouvez spécifier l’ordre dans lequel les approbations et les vérifications s’exécutent.

Les approbations et les vérifications vous permettent de contrôler les déploiements en production. Par exemple, vous pouvez spécifier que seuls les pipelines qui s’exécutent sur la main branche d’un référentiel sont autorisés à utiliser une connexion de service ARM de production. En outre, vous pouvez exiger une approbation humaine et que le système passe un contrôle des performances.

Jusqu’à aujourd’hui, toutes les approbations et vérifications s’étaient exécutées en parallèle, à l’exception du verrou exclusif. Cela signifie que si votre processus de déploiement nécessitait des vérifications de performances avant que l’approbation manuelle ne soit donnée, vous n’avez pas pu l’appliquer dans Azure Pipelines. Vous devez vous appuyer sur les instructions d’approbation et la documentation interne du processus.

Avec ce sprint, nous introduisons le séquencement dans approbations et vérifications. Il existe maintenant cinq catégories d’approbations et de vérifications :

  1. Contrôles statiques : Contrôle de branche, Modèle requis et Évaluer l'artefact
  2. Vérifications pré-dynamiques Approbation
  3. Contrôles dynamiques : Approbation, Invocation d'une fonction Azure, Invocation d'une API REST, Heures ouvrables, Interrogation des alertes Azure Monitor
  4. Approbation post-dynamique des vérifications
  5. Verrou exclusif

Capture d’écran de l’ajout d’une vérification.

L’ordre s’affiche également sous l’onglet Approbations et vérifications.

Capture d’écran de l’onglet Approbations et vérifications.

Dans chaque catégorie, les vérifications s’exécutent en parallèle. Autrement dit, si vous disposez d’une vérification de fonction Azure Invoke et d’une vérification des heures d’ouverture, elles s’exécutent en même temps.

Capture d’écran des vérifications pour le déploiement.

Les catégories de vérification s’exécutent une par une et, si elles échouent, le reste des vérifications ne sont pas exécutées. Cela signifie que si vous disposez d’une vérification du contrôle Branche et d’une approbation, si le contrôle Branche échoue, l’approbation échoue également. Par conséquent, aucun e-mail inutile ne sera envoyé.

Capture d’écran des vérifications de l’échec du déploiement.

Vous pouvez vous déconnecter d’un déploiement une fois que toutes les vérifications dynamiques ont été exécutées, à l’aide d’une approbation post-dynamique des vérifications ou effectuer une validation manuelle avant de procéder à des vérifications dynamiques, à l’aide d’une approbation de vérifications pré-dynamiques.

Valider et enregistrer par défaut lors de la modification des pipelines YAML

Un pipeline YAML incorrect peut entraîner des pertes de temps et d’efforts. Pour améliorer la productivité de la modification de votre pipeline, nous modifions le bouton Enregistrer dans l’éditeur pour effectuer également la validation YAML.

Capture d’écran du nouveau bouton.

Capture d’écran de validation et d’enregistrement.

Si votre pipeline a des erreurs, vous pourrez toujours l’enregistrer.

Capture d’écran du pipeline valide.

Capture d’écran des erreurs détectées.

Nous avons également amélioré l’expérience De validation , afin que vous puissiez voir les erreurs dans une liste plus facile à comprendre.

Capture d’écran de la liste des erreurs.

Azure Repos

Prévention pour les utilisateurs non autorisés à configurer le pipeline en tant que stratégie de génération

Prévention pour les utilisateurs non autorisés à configurer le pipeline en tant que stratégie de génération

Auparavant, lorsque vous avez ajouté une nouvelle stratégie de build, vous pouvez configurer pour exécuter n’importe quel pipeline à partir de la liste déroulante (y compris les pipelines pour lesquels vous n’avez pas d’autorisation de build de file d’attente). De même, vous pouvez modifier la stratégie de build existante même si celle-ci a été configurée pour exécuter le pipeline pour lequel vous n’avez pas autorisé les builds de file d’attente.

Maintenant, nous empêchant les utilisateurs de le faire. Si un utilisateur n’est pas autorisé à générer une file d’attente pour un pipeline donné, ce pipeline est affiché comme désactivé (grisé) dans la liste déroulante lors de l’ajout d’une nouvelle stratégie de génération.

Consultez l’image ci-dessous montrant le pipeline nommé « Bac à sable » avec l’autorisation de génération de files d’attente refusée.

Capture d’écran des autorisations pour sandbox.

Consultez l’image ci-dessous montrant le pipeline nommé « Sandbox » désactivé (grisé) dans la liste déroulante lorsque l’utilisateur disposant de l’autorisation de génération de file d’attente refusée tente d’ajouter une nouvelle stratégie de génération.

Capture d’écran de l’ajout d’une stratégie de génération.

Lorsque la stratégie de génération configurée pour exécuter le pipeline nommé « Sandbox » existe déjà, l’utilisateur sans autorisation de génération de file d’attente ne pourra pas modifier ou afficher la stratégie de génération. Ce cas est illustré sur l’image suivante.

Capture d’écran de la validation de build.

Lorsque vous essayez de supprimer cette stratégie, la boîte de dialogue contextuelle demandant la confirmation de suppression s’affiche.

Capture d’écran de la suppression de confirmation.

Ces modifications s’appliquent également aux appels d’API qui entraînent la création ou la modification de la stratégie de génération. Lorsque l’une de ces actions est exécutée à l’aide d’une identité utilisateur sans autorisation de génération de file d’attente, l’appel retourne le code d’erreur approprié et le message d’erreur indiquant que “TFS.WebApi.Exception: TF401027: vous avez besoin de l’autorisation QueueBuild sur ce pipeline pour effectuer cette action. »

La suppression d’une stratégie de génération effectuée via l’API à l’aide d’une user identity autorisation de builds de file d’attente réussit et aucun avertissement ni prévention n’est effectué (aucune modification de la suppression via l’API fonctionne).

Azure Artifacts

La prise en charge de Rust Crates est généralement disponible

À compter du 16 février 2024, la prise en charge de Rust Crates deviendra une fonctionnalité généralement disponible pour Azure Artifacts. Les compteurs de facturation seront activés à l’aide du même modèle tarifaire que celui qui s’applique aux autres protocoles pris en charge.

Prise en charge des artefacts Azure pour l’audit npm

Azure Artifacts prend désormais en charge npm audit et npm audit fix commandes. Cette fonctionnalité permet aux utilisateurs d’analyser et de corriger les vulnérabilités de leur projet en mettant automatiquement à jour les versions de package non sécurisées. Pour en savoir plus, utilisez l’audit npm pour détecter et corriger les vulnérabilités des packages.

Étapes suivantes

Notes

Ces fonctionnalités seront déployées au cours des deux à trois prochaines semaines.

Accédez à Azure DevOps et jetez un coup d’œil.

Accéder à Azure DevOps

Comment fournir des commentaires

Nous aimerions savoir ce que vous pensez de ces fonctionnalités. Utilisez le menu Aide pour signaler un problème ou faire une suggestion.

Faire une suggestion

Vous pouvez également obtenir des conseils et répondre à vos questions par la communauté sur Stack Overflow.

Merci,

Dan Hellem