Modifications apportées aux subventions gratuites Azure Pipelines

Nous modifions temporairement le processus d’acquisition de subventions gratuites Azure Pipelines pour résoudre l’abus croissant des agents hébergés. Par défaut, les nouvelles organisations créées dans Azure DevOps peuvent ne plus obtenir une subvention gratuite 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

• Modifications apportées aux subventions gratuites Azure Pipelines
• Suppression des stratégies de rétention par pipeline dans les builds classiques
• Nouveaux contrôles pour les variables d’environnement dans les pipelines
• Générer des builds de fork de jeton sans restriction
• Modification des modules préinstallés Az, Azure et Azure RM

Azure Repos

• Désactiver un référentiel

Azure Pipelines

Modifications apportées aux subventions gratuites Azure Pipelines

Azure Pipelines propose des projets CI/CD gratuits à des projets publics et privés depuis plusieurs années. Étant donné que cela équivaut à donner un calcul gratuit, il a toujours été une cible pour les abus , en particulier l’exploration de chiffrement. La réduction de cet abus a toujours pris de l’énergie de l’équipe. Au cours des derniers mois, la situation s’est nettement pire, avec un pourcentage élevé de nouveaux projets dans Azure DevOps utilisés pour l’exploration de données de chiffrement et d’autres activités que nous classifions comme abusives. Plusieurs incidents de service au cours du mois dernier ont été provoqués par cet abus, ce qui a entraîné des temps d’attente longs pour les clients existants.

Pour résoudre ce problème, nous avons ajouté une étape supplémentaire pour les nouvelles organisations dans Azure DevOps afin d’obtenir leur subvention gratuite. Les modifications suivantes sont effectives 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 octroi gratuit, envoyez une demande et fournissez clairement les détails suivants :
  • Votre nom
  • Organisation Azure DevOps pour laquelle vous demandez l’octroi gratuit
  • Que vous ayez besoin de l’octroi gratuit pour les 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 allons examiner votre demande et répondre dans les quelques jours.

Remarque

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

Nous nous excusons des inconvénients que cela peut entraîner pour les nouveaux clients souhaitant utiliser Azure Pipelines pour CI/CD. Nous pensons que cela est nécessaire pour continuer à fournir un niveau de service élevé à tous nos clients. Nous continuerons d’explorer les façons automatisées de prévenir les abus et de restaurer le modèle précédent une fois que nous avons 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 du projet Azure DevOps. Bien qu’il s’agit du seul moyen 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 toujours 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.

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 via une tâche, consultez la documentation relative à la définition des stratégies de rétention pour les builds, versions et 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 setVariable commande peut être utilisée pour définir une variable ou modifier une variable précédemment définie. Cela peut ê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 provoquer le changement de comportement du pipeline.

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, task.jsonun auteur de tâche peut contrôler si des variables sont définies par leur 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 builds de fork de jeton sans restriction

Les utilisateurs GitHub utilisent couramment des duplications pour contribuer à un dépôt en amont. Quand Azure Pipelines génère des contributions à partir d’une duplication d’un dépôt GitHub, elle 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é des fourches de construction dans notre documentation.

Les mêmes restrictions s’appliquent par défaut lors de la génération de duplications d’un référentiel 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 proposons de contrôler la génération d’un jeton d’accès de travail standard, même pour les builds de fourche.

Vous pouvez modifier ce paramètre à partir de déclencheurs dans l’éditeur de pipeline. Avant de modifier ce paramètre, assurez-vous que vous comprenez parfaitement les implications de sécurité de l’activation de cette configuration.

Modification des 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 par Ubuntu et Windows pour une prise en charge plus efficace et une utilisation de l’espace d’image.

Au cours de la semaine du 29 mars, toutes les versions, à l’exception des dernières et les plus populaires, seront stockées sous forme d’archives et seront extraites par la tâche Azure PowerShell à 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 la dernière version (actuellement, 5.3.0) et 2.1.0 seront archivés.

   • Tous les modules AzureRM à l’exception de la dernière version (actuellement, 6.13.1) et 2.1.0 seront archivés.

2. Images Ubuntu

   • Tous les modules Az, à l’exception de la dernière version (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.

Les pipelines qui utilisent des tâches Azure in-the-box sur des agents hébergés fonctionnent comme prévu et ne nécessitent pas de mises à jour. Si vous n’utilisez pas ces tâches, basculez vos pipelines vers l’utilisation de la tâche Azure PowerShell pour éviter les modifications apportées aux modules préinstallés.

Remarque

Ces mises à jour n’affectent pas les pipelines s’exécutant sur des agents auto-hébergés.

Azure Repos

Désactiver un référentiel

Les clients ont souvent demandé un moyen de désactiver un référentiel et d’empêcher les utilisateurs d’accéder à son contenu. Par exemple, vous pouvez effectuer cette opération lorsque :

• Vous avez trouvé un secret dans le référentiel.
• Un outil d’analyse tiers a trouvé un référentiel hors conformité.

Dans ce cas, vous pouvez désactiver temporairement le référentiel pendant que vous travaillez pour résoudre le problème. Avec cette mise à jour, vous pouvez désactiver un référentiel si vous disposez d’autorisations de suppression de référentiel . 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 effectuées, les utilisateurs disposant de l’autorisation Supprimer le référentiel peuvent réactiver le référentiel. Pour désactiver ou activer un référentiel, accédez à Paramètres du projet, sélectionnez Référentiels, puis le référentiel spécifique.

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

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

Merci,

Vijay Machiraju