Connecter GitHub Actions à Azure Machine Learning en toute sécurité
Vos flux de travail de validation peuvent désormais intercepter les erreurs de code avant d’atteindre main. L’étape suivante consiste à permettre à ces flux de travail de communiquer avec Azure Machine Learning : l’envoi de travaux, la lecture des résultats et l’inscription de modèles. Cela nécessite une authentification, et la manière dont vous la gérez est importante pour la sécurité.
Secrets et variables
GitHub fournit deux emplacements pour stocker la configuration du flux de travail :
- Les secrets sont des valeurs chiffrées pour les informations d’identification et d’autres configurations sensibles. GitHub masque les valeurs secrètes reconnues dans les journaux d'activité, mais les workflows doivent toujours éviter de les exposer.
- Les variables contiennent une configuration non sensible. Utilisez-les pour les noms d’espace de travail, les noms de groupes de ressources et les valeurs similaires que vous souhaitez réutiliser dans les flux de travail.
Les secrets propres à un environnement sont plus restreints que les secrets du dépôt : une tâche doit cibler cet environnement avant de pouvoir y accéder.
Principaux de service et privilèges minimum
L’une des façons d’authentifier un flux de travail pour Azure est avec un principal de service , une identité non humaine dans Microsoft Entra ID. Vous créez le principal, attribuez-le à un rôle Azure et stockez ses informations d’identification en tant que secret GitHub.
Le rôle et l’étendue sont importants. Attribuez un rôle approprié à l'étendue la plus restreinte nécessaire au workflow, par exemple l’espace de travail Azure Machine Learning ou son groupe de ressources.
Fédération des identités de charge de travail avec OpenID Connect
Stocker des identifiants à longue durée de vie sous forme de secret présente un risque : si le secret est exposé, il reste valide jusqu’à ce que vous le renouveliez. La fédération des identités de charge de travail avec OpenID Connect (OIDC) évite de stocker ces informations d’identification de longue durée.
Au lieu de stocker des secrets clients, vous configurez une relation d’approbation entre votre dépôt GitHub et une application Microsoft Entra. Lorsqu’un flux de travail s’exécute, GitHub émet un jeton OIDC de courte durée. Azure valide le jeton et retourne un jeton d’accès : aucune information d’identification stockée n’est échangée.
Tip
Préférez la fédération des identités de charge de travail par rapport aux secrets client du principal de service pour les nouveaux workflows. Les jetons de courte durée réduisent l’exposition et suppriment la nécessité de renouveler un secret client enregistré.
Authentification de flux de travail et suivi Git
Lorsque vous soumettez des fichiers sources à partir d’un référentiel Git local, Azure Machine Learning peut enregistrer le référentiel, la branche et le commit avec la tâche de formation. Ce suivi fonctionne avec n'importe quel service Git compatible et n'attache pas un référentiel GitHub spécifique à l'espace de travail.
Le suivi Git et l’authentification de workflow résolvent différents problèmes. Le suivi connecte un travail à la version source qui l’a produite. L’authentification accorde au flux de travail l’autorisation de soumettre cette tâche.
Tip
Quelles valeurs de flux de travail sont des identificateurs et quelles sont les informations d’identification qui doivent rester secrètes ?