Depuis la version 1.3.0-preview1 de PSResourceGet, une simple commande Get-PSResourceRepository affiche une colonne qui change la donne :
Name Uri Trusted Priority
---- --- ------- --------
MicrosoftArtifactRegistry https://mcr.microsoft.com/ True 40
PSGallery https://www.powershellgallery.com/api/v2 False 50
La PowerShell Gallery, le dépôt communautaire historique que tu utilises probablement depuis des années sans y penser, n’est plus Trusted par défaut. Un nouveau dépôt, le Microsoft Artifact Registry, prend la tête avec une priorité plus haute (40 contre 50 — plus le chiffre est bas, plus PSResourceGet le consulte tôt). Ce n’est pas un détail cosmétique : c’est un changement de posture de sécurité assumé par Microsoft.
Pourquoi la PowerShell Gallery a perdu la confiance par défaut
La PowerShell Gallery reste ouverte à quiconque crée un compte et génère une clé API — c’est ce qui en a fait un dépôt communautaire riche au fil des ans. Mais cette ouverture a un coût : plusieurs chercheurs en sécurité ont documenté des scénarios de typosquatting (publier un module au nom presque identique à un paquet populaire pour piéger une faute de frappe) et de spoofing, où un module malveillant se fait passer pour un paquet officiel Microsoft en copiant son nom d’affichage et sa description.
Rien de tout ça n’est propre à PowerShell — npm et PyPI ont vécu les mêmes attaques, à plus grande échelle encore. Mais pour un administrateur système qui installe des modules avec des privilèges élevés, souvent sur des serveurs de production, le risque n’a rien de théorique. Traiter la Gallery comme non fiable par défaut est une position raisonnable, même si elle demande un temps d’adaptation : tu devras explicitement faire confiance à un dépôt (Set-PSResourceRepository -Name PSGallery -Trusted) ou valider chaque installation communautaire au cas par cas.
Le Microsoft Artifact Registry, concrètement
Le MAR n’est pas un nouveau service pensé pour PowerShell : c’est le registre où Microsoft publie déjà ses images de conteneurs officielles. PSResourceGet s’appuie sur cette infrastructure existante depuis la version 1.1.0 du module, et devient dépôt par défaut à partir de la 1.3.0-preview1, aux côtés de PSGallery. Aucune authentification n’est nécessaire pour chercher, télécharger ou installer un paquet — seule la publication est verrouillée côté Microsoft, ce qui élimine mécaniquement le risque de typosquatting sur les modules officiels.
L’enregistrer prend une seule ligne :
# Enregistre MAR avec les réglages par défaut (Trusted, priorité 40)
Register-PSResourceRepository -MicrosoftArtifactRegistry
# Vérifie ce qui est enregistré
Get-PSResourceRepository
# Recherche et installation, sans rien changer d'autre
Find-PSResource -Repository MicrosoftArtifactRegistry -Name Az.Accounts
Install-PSResource -Name Az.Accounts -Repository MicrosoftArtifactRegistry
Si tu es encore sur PowerShell 5.1, ou sur une version de PowerShell 7 antérieure à 7.5.0, il faut d’abord installer PSResourceGet manuellement — le module n’est pas mis à jour automatiquement avec l’exécutable :
Install-Module -Name Microsoft.PowerShell.PSResourceGet -Repository PSGallery
Le cas Az : plus rapide, mais pas encore sans accroc
Le module Az est le premier gros bénéficiaire concret de ce changement : l’installer depuis le MAR plutôt que depuis PSGallery accélère nettement le téléchargement, sans passer par le processus de publication communautaire classique. La commande recommandée par Microsoft :
Register-PSResourceRepository -Name MAR -Uri https://mcr.microsoft.com -ApiVersion ContainerRegistry
Install-PSResource -Name Az -Repository MAR
Il y a un vrai bug à connaître avant de foncer en production : certains sous-modules, comme Az.KeyVault, échouent à l’installation depuis le MAR avec l’erreur Install-PSResource: Package(s) 'Az.Keyvault' could not be installed from repository 'MAR'. Le correctif est suivi sur le dépôt GitHub de PSResourceGet, mais en attendant, le contournement documenté par Microsoft reste d’installer ce module précis depuis PSGallery. Ce n’est pas gênant tant que tu sais que ce cas existe — ça devient un mauvais moment si tu le découvres au milieu d’un déploiement.
Ce que ça change pour tes scripts et tes pipelines
Si tu gères tes serveurs avec des modules exclusivement Microsoft (Az, Microsoft.Graph, ExchangeOnlineManagement dans ses versions récentes), la bascule est presque transparente : enregistre le MAR, laisse PSGallery en untrusted, et tes installations continuent de fonctionner sans invite de confirmation. C’est la configuration que je recommande par défaut sur un serveur de production.
La situation se complique si tu dépends de modules communautaires bien installés — ImportExcel, PSFramework, ou des modules DSC tiers n’ont aucune raison d’apparaître un jour sur le MAR, qui reste réservé aux publications officielles Microsoft. Dans ce cas, remettre PSGallery en Trusted globalement annule une bonne partie de l’intérêt du changement. Une approche plus fine consiste à garder PSGallery non fiable, et à n’accorder la confiance ponctuellement à l’installation (Install-PSResource -Name ImportExcel -TrustRepository) pour les modules que tu as toi-même audités, plutôt que de rouvrir la porte à l’ensemble du dépôt communautaire.
FAQ
Dois-je désinstaller PSGallery ?
Non, et ce n’est même pas recommandé : de nombreux modules n’existent que là. Le changement porte sur le niveau de confiance par défaut, pas sur la disponibilité du dépôt.
Le MAR remplace-t-il PSGallery à terme ?
Non, ce n’est pas l’objectif annoncé. Le MAR couvre les modules officiels Microsoft ; PSGallery reste la référence pour l’écosystème communautaire, qui représente la grande majorité des modules publiés.
Est-ce que ça concerne aussi PowerShellGet v2 (Install-Module) ?
Non, cette évolution est propre à PSResourceGet. Si tu es toujours sur PowerShellGet v2, c’est une raison supplémentaire de migrer.
Faut-il une version précise de PSResourceGet ?
Le support du MAR existe depuis la 1.1.0, mais il ne devient dépôt par défaut qu’à partir de la 1.3.0-preview1. Vérifie ta version avec Get-Module Microsoft.PowerShell.PSResourceGet -ListAvailable avant de t’étonner qu’il manque à ta liste de dépôts.
Passe à l’action
Lance Get-PSResourceRepository sur un de tes serveurs cette semaine, et regarde ce qui en sort. Si PSGallery apparaît encore Trusted sans que tu l’aies décidé consciemment, c’est le bon moment pour revoir cette configuration module par module plutôt que de la laisser filer.
Pour creuser le sujet, la documentation officielle Microsoft détaille le support du Microsoft Artifact Registry dans PSResourceGet ainsi que les dépôts pris en charge, et BleepingComputer revient sur les failles de spoofing identifiées sur la PowerShell Gallery. On avait détaillé la migration vers PSResourceGet dans cet article, et la feuille de route 2026 de l’équipe PowerShell dans celui-ci.
Laisser un commentaire