Partager via


Modifications apportées aux subventions gratuites Azure Pipelines

Nous modifions temporairement le processus pour obtenir des subventions gratuites Azure Pipelines afin de résoudre les abus croissants des agents hébergés. Par défaut, les nouvelles organisations créées dans Azure DevOps peuvent ne plus obtenir d’octroi gratuit de pipelines simultanés. Les nouveaux utilisateurs devront envoyer un e-mail et fournir des informations supplémentaires pour obtenir un CI/CD gratuit.

Pour plus d’informations, consultez la liste des fonctionnalités ci-dessous.

Azure Pipelines

Azure Repos

Azure Pipelines

Modifications apportées aux subventions gratuites Azure Pipelines

Azure Pipelines offre depuis plusieurs années un CI/CD gratuit à des projets publics et privés. Comme cela revient à donner du calcul gratuit, il a toujours été une cible d’abus, en particulier l’exploration de chiffrement. Minimiser cet abus a toujours pris de l’énergie de l’équipe. Au cours des derniers mois, la situation s’est considérablement dégradée, avec un pourcentage élevé de nouveaux projets dans Azure DevOps utilisés pour l’exploration de chiffrement et d’autres activités que nous classons comme abusives. Plusieurs incidents de service au cours du mois dernier ont été causés par cet abus qui a entraîné de longs temps d’attente pour les clients existants.

Pour résoudre cette situation, nous avons ajouté une étape supplémentaire pour que les nouvelles organisations dans Azure DevOps obtiennent leur subvention gratuite. Les modifications suivantes prennent effet immédiatement :

  • Par défaut, les nouvelles organisations créées dans Azure DevOps n’obtiennent plus d’octroi gratuit de pipelines simultanés. Cela s’applique aux projets publics et privés dans de nouvelles organisations.
  • Pour demander votre subvention gratuite, envoyez une demande et fournissez clairement les détails suivants :
    • Votre nom
    • Azure DevOps organization pour laquelle vous demandez l’octroi gratuit
    • Si vous avez besoin de la subvention gratuite pour des projets publics ou privés
    • Liens vers les référentiels que vous envisagez de générer (projets publics uniquement)
    • Brève description de votre projet (projets publics uniquement)

Nous examinerons votre demande et y répondrons dans quelques jours.

Notes

Cette modification n’a qu’un impact sur les nouvelles organisations. Elle ne s’applique pas aux projets ou organisations existants. Cela ne change pas le montant de l’octroi gratuit que vous pouvez obtenir. Il ajoute seulement une étape supplémentaire pour obtenir cette subvention gratuite.

Nous nous excusons pour les désagréments occasionnés par les nouveaux clients qui souhaitent utiliser Azure Pipelines pour CI/CD. Nous croyons que cela est nécessaire pour continuer à fournir un haut niveau de service à tous nos clients. Nous continuerons d’explorer les moyens automatisés de prévenir les abus et rétablirons le modèle précédent une fois que nous disposerons d’un mécanisme fiable pour prévenir les abus.

Suppression des stratégies de rétention par pipeline dans les builds classiques

Vous pouvez maintenant configurer des stratégies de rétention pour les builds classiques et les pipelines YAML dans les paramètres de projet Azure DevOps. Bien qu’il s’agit de la seule façon de configurer la rétention pour les pipelines YAML, vous pouvez également configurer la rétention pour les pipelines de build classiques par pipeline. Nous allons supprimer toutes les règles de rétention par pipeline pour les pipelines de build classiques dans une prochaine version.

Ce que cela signifie pour vous : tout pipeline de build classique qui a encore des règles de rétention par pipeline sera bientôt régi par les règles de rétention au niveau du projet.

Pour vous aider à identifier ces pipelines, nous déployons une modification dans cette version pour afficher une bannière en haut de la page de liste des exécutions.

Améliorations apportées à la rétention des builds

Nous vous recommandons de mettre à jour vos pipelines en supprimant les règles de rétention par pipeline. Si votre pipeline nécessite spécifiquement des règles personnalisées, vous pouvez utiliser une tâche personnalisée dans votre pipeline. Pour plus d’informations sur l’ajout de baux de rétention par le biais d’une tâche, consultez la documentation définir des stratégies de rétention pour les builds, les mises en production et les tests.

Nouveaux contrôles pour les variables d’environnement dans les pipelines

L’agent Azure Pipelines analyse la sortie standard des commandes de journalisation spéciales et les exécute. La setVariablecommande peut être utilisée pour définir une variable ou modifier une variable précédemment définie. Cela peut potentiellement être exploité par un acteur en dehors du système. Par exemple, si votre pipeline a une étape qui imprime la liste des fichiers dans un serveur FTP, une personne ayant accès au serveur FTP peut ajouter un nouveau fichier, dont le nom contient la setVariable commande et entraîne la modification de son comportement.

Nous avons de nombreux utilisateurs qui s’appuient sur la définition de variables à l’aide de la commande de journalisation dans leur pipeline. Avec cette version, nous apportons les modifications suivantes pour réduire le risque d’utilisations indésirables de la setVariable commande.

  • Nous avons ajouté une nouvelle construction pour les auteurs de tâches. En incluant un extrait de code tel que le suivant dans task.json, un auteur de tâche peut contrôler si des variables sont définies par sa tâche.
{
    "restrictions": {
        "commands": {
            "mode": "restricted"
        },
        "settableVariables": {
            "allowed": [
                "myVar",
                "otherVar"
            ]
        }
    },
}​ 
  • En outre, nous mettons à jour un certain nombre de tâches intégrées telles que ssh afin qu’elles ne puissent pas être exploitées.

  • Enfin, vous pouvez maintenant utiliser des constructions YAML pour contrôler si une étape peut définir des variables.

steps:
- script: echo hello
  target:
    settableVariables: none
steps:
- script: echo hello
  target:
    settableVariables:
    - things
    - stuff

Générer des jetons non restreints pour les builds de duplication

Les utilisateurs GitHub utilisent généralement des duplications forks pour contribuer à un dépôt amont. Quand Azure Pipelines génère contributions à partir d’une duplication d’un dépôt GitHub, il limite les autorisations accordées au jeton d’accès au travail et n’autorise pas l’accès aux secrets de pipeline par ces travaux. Vous trouverez plus d’informations sur la sécurité de la création de duplications dans notre documentation.

Les mêmes restrictions s’appliquent par défaut lors de la génération de duplications d’un dépôt GitHub Enterprise Server. Cela peut être plus restrictif que souhaité dans ces environnements fermés, où les utilisateurs peuvent toujours bénéficier d’un modèle de collaboration interne source. Bien que vous puissiez configurer un paramètre dans un pipeline pour rendre les secrets disponibles pour les duplications, il n’existe aucun paramètre pour contrôler l’étendue du jeton d’accès au travail. Avec cette version, nous vous donnons le contrôle pour générer un jeton d’accès de travail standard, même pour les builds de duplications.

Vous pouvez modifier ce paramètre à partir de Déclencheurs dans l’éditeur de pipeline. Avant de modifier ce paramètre, assurez-vous de bien comprendre les implications en matière de sécurité de l’activation de cette configuration.

Générer des jetons non restreints pour les builds de duplication

Modification dans les modules préinstallés Az, Azure et Azure RM

Nous mettons à jour le processus de préinstallation des modules Az, Azure et AzureRM sur des images hébergées ubuntu et Windows pour une prise en charge et une utilisation plus efficace de l’espace d’image.

Au cours de la semaine du 29 mars, toutes les versions, à l’exception de la version la plus récente et la plus populaire, seront stockées en tant qu’archives et extraites par Azure PowerShell tâche à la demande. La liste détaillée des modifications est ci-dessous :

  1. Images Windows

    • Toutes les versions du module Az à l’exception de la dernière version (actuellement, 5.5.0) seront archivées.

    • Tous les modules Azure à l’exception de ceux les plus récents (actuellement, 5.3.0) et 2.1.0 seront archivés.

    • Tous les modules AzureRM à l’exception de ceux les plus récents (actuellement, 6.13.1) et 2.1.0 seront archivés.

  2. Images Ubuntu

    • Tous les modules Az à l’exception du dernier module (actuellement, 5.5.0) seront archivés ou supprimés complètement de l’image, et seront installés par la tâche à la demande.

Tous les pipelines qui utilisent des tâches Azure prédéfinies sur des agents hébergés fonctionneront comme prévu et ne nécessiteront pas de mises à jour. Si vous n’utilisez pas ces tâches, basculez vos pipelines en utilisant Azure PowerShell tâche pour éviter les modifications apportées aux modules préinstallés.

Notes

Ces mises à jour n’affectent pas les pipelines en cours d’exécution sur les agents auto-hébergés.

Azure Repos

Désactiver un dépôt

Les clients ont souvent demandé un moyen de désactiver un dépôt et d’empêcher les utilisateurs d’accéder à son contenu. Par exemple, vous pouvez effectuer cette opération dans les cas suivants :

  • Vous avez trouvé un secret dans le dépôt.
  • Un outil d’analyse tiers a constaté qu’un dépôt n’était pas conforme.

Dans ce cas, vous pouvez désactiver temporairement le dépôt pendant que vous travaillez pour résoudre le problème. Avec cette mise à jour, vous pouvez désactiver un dépôt si vous disposez des autorisations Supprimer le dépôt . En désactivant un dépôt, vous :

  • Peut répertorier le dépôt dans la liste des dépôts
  • Impossible de lire le contenu du dépôt
  • Impossible de mettre à jour le contenu du dépôt
  • Afficher un message indiquant que le dépôt a été désactivé lorsqu’il tente d’accéder au dépôt dans l’interface utilisateur Azure Repos

Une fois les étapes d’atténuation nécessaires prises, les utilisateurs disposant de l’autorisation Supprimer le dépôt peuvent réactiver le dépôt. Pour désactiver ou activer un dépôt, accédez à Paramètres du projet, sélectionnez Référentiels, puis le dépôt spécifique.

Désactiver un dépôt

É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.

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,

Vijay Machiraju