Authentification moderne avec Azure Workload Identity Federation

Introduction:

Workload Identity Federation fournit un accès sécurisé aux ressources Azure à partir de systèmes extérieurs tels que les actions GitHub, Azure DevOps et Kubernetes sans gestion secrète. Il utilise l’ID Microsoft ENTRA pour un échange de jetons basé sur la confiance, augmentant la sécurité et facilitant les flux CI / CD.

Énoncé du problème:

Un service d’application ou un script exécuté à l’extérieur d’Azure utilise un secret ou un certificat pour accéder aux ressources protégées dans Azure, Microsoft Graph. Les secrets et les certificats présentent un risque de sécurité et peuvent également expirer, ce qui mène aux temps d’arrêt des services.

Approche de la solution:

Workload Identity Federation vous permet d’accéder à l’ID Microsoft ENTRA, ID ENTRA Resources protégées sans avoir à gérer les secrets. Vous pouvez configurer un enregistrement d’application dans l’identification ENTRA pour faire confiance à un fournisseur d’identité externe comme Github, Google Cloud ou Kubernetes afin que votre logiciel externe puisse accéder aux ressources auxquelles l’enregistrement de l’application a été provisoire l’accès

Comment ça marche:

Pour permettre aux charges de travail externes (telles que les actions GitHub) d’utiliser des ressources protégées en ID ENTRA sans manipuler des secrets, vous pouvez configurer une information d’identité fédérée en utilisant l’un ou l’autre:

• Identité gérée assistée par l’utilisateur
• Enregistrement de l’application

UN Identité fédérée L’identification est ce qui associe un jeton de fournisseur d’identité externe (IDP) avec une identité ou une application gérée dans Microsoft ENTRA ID. La configuration des informations d’identification implique le émetteur, sujetet public du jeton, et tous ces éléments devraient correspondre exactement, y compris le cas, pour que l’autorisation se déroule. Une fois la relation de confiance établie, les jetons externes peuvent être échangés contre des jetons d’accès à l’identification ENTRA dans un processus fluide, en utilisant un flux de travail standard pour divers scénarios.

Flux de travail d’échange de jetons:

• La charge de travail externe (par exemple, actions GitHub) sollicite un jeton de son IDP.
• IDP fournit le jeton à la charge de travail.
• La charge de travail passe le jeton sur la plate-forme d’identité Microsoft afin d’obtenir un jeton d’accès.
• Microsoft vérifie le jeton externe par rapport à la configuration Set Trust.
• Sur une vérification réussie, Microsoft fournit un jeton d’accès.
• La charge de travail utilise le jeton d’accès pour accéder aux ressources protégées Microsoft (telles que Azure App Service).
  

  Échange de jetons

Cas d’utilisation: Actions GitHub avec les informations d’identification fédérées
Grâce à la fédération, les actions GitHub peuvent utiliser en toute sécurité les ressources Azure sans garder des secrets. Les jetons fédérés avec connexion AZ sont utilisés par les workflows pour les déploiements Azure sécurisés, ce qui rend CI / CD plus facile et plus sécurisé.

• Pour configurer une identité fédérée pour les actions GitHub avec un enregistrement d’application dans l’identifiant ENTRA
• Accédez aux inscriptions des applications dans l’ID ENTRA et choisissez votre demande.
• Dans le menu de gauche, accédez aux certificats et aux secrets, ouvrez l’onglet Federated Indementials, et cliquez sur Ajouter des informations d’identification.
• Dans le scénario d’identification fédéré, choisissez des actions GitHub déploiement des ressources Azure.
• Entrez votre organisation et votre référentiel GitHub dans lequel le flux de travail est défini.
• Pour le type d’entité, sélectionnez l’environnement, la branche, la demande de traction ou la balise et entrez la valeur pour la même chose. Ces valeurs doivent correspondre exactement à celles définies dans votre flux de travail GitHub.
  Note: La correspondance du modèle n’est pas prise en charge pour les branches et les balises, alors utilisez un nom d’environnement lorsque vous spécifiez plusieurs branches ou balises.
• Fournissez un nom pour les informations d’identification fédérées.
• L’émetteur, le public et les champs de sujet rempliront automatiquement en fonction de votre contribution.
• Cliquez sur Ajouter pour terminer la configuration.
  

  Contaliens fédérés GitHub-Action

• Après avoir configuré l’identité fédérée, vous devrez référencer les valeurs suivantes de l’enregistrement de votre application dans votre flux de travail GitHub Actions:
  Azure_client_id: L’ID de l’application (client) de votre application.
  Azure_tenant_id & azure_subscription_id: Le répertoire (locataire) et l’identifiant d’abonnement pour votre compte Azure.
  

  girub

• Après cela, vous pouvez tester les informations d’identification fédérées en utilisant le flux de travail ci-dessous.

Cas d’utilisation: Azure DevOps avec des informations d’identification fédérées
Azure DevOps utilise désormais un processus de fédération de la charge de travail pour obtenir des jetons à partir de l’ID ENTRA que le pipeline peut utiliser directement pour s’authentifier avec un jeton OpenID Connect (OIDC) afin d’accéder aux ressources Azure en toute sécurité.
Lors de la configuration des informations d’identification fédérées pour Azure DevOps, il existe deux méthodes de configuration principales, selon votre niveau d’accès et vos besoins de contrôle:

Configuration automatique:
Cette méthode est la plus appropriée lorsque votre configuration Azure DevOps a les autorisations nécessaires pour créer ou mettre à jour les enregistrements d’applications et les informations d’identification fédérées automatiquement. Azure DevOps le définit dans les coulisses dans le cadre de la création de la connexion de service.

• • Ouvrez votre projet Azure DevOps et accédez aux paramètres du projet.
  • Dans les pipelines, choisissez les connexions de service et cliquez sur une nouvelle connexion de service.
  • Sélectionnez Azure Resource Manager comme type de connexion.
  • Définissez le type d’identité sur l’enregistrement de l’application (automatique).
  • Sélectionnez Workload Identity Federation comme méthode des informations d’identification.
  • Sélectionnez la portée correcte: abonnement, groupe de gestion ou espace de travail d’apprentissage automatique.
  • Sélectionnez votre abonnement Azure et sélectionnez éventuellement un groupe de ressources.
  • Entrez un nom de connexion de service et une référence de gestion des services facultative.
  • Cliquez sur Enregistrer pour permettre à Azure DevOps de terminer automatiquement l’enregistrement de l’application et la configuration des informations d’identification fédérée.
    

    Connexion de service automatique

Configuration manuelle:
Choisissez cette approche si la gestion granulaire de la façon dont l’enregistrement de l’application ou l’identité gérée est créé et sécurisé est nécessaire. Ceci est idéal pour les organisations ayant des politiques de gouvernance strictes ou qui souhaitent contrôler l’attribution d’identité et les relations de confiance fédérées à la main.
Pour la configuration manuelle, utilisez les étapes suivantes:

• Créez une identité gérée ou un enregistrement d’application géré par l’utilisateur dans Azure.
• Dans Azure DevOps, créez une connexion de service Azure Resource Manager.
  

  Connexion de service manuel

• Utilisez les informations sur l’enregistrement des applications / les clients et les détails du client existants.
  

  Connexion de service manuel

  

  Connexion de service manuel

• Marquez l’URL de l’émetteur et l’identifiant de sujet à partir de la configuration Azure DevOps.
  Configurez-les dans des références fédérées:
  Pour l’enregistrement des applications: Accédez à des certificats et à des secrets> des informations d’identification fédérées.
  Pour l’identité gérée: Accédez à la lame des informations d’identification fédérée.
  

  Des références fédérées

Attribuez les rôles requis (par exemple, contributeur ou lecteur) à l’enregistrement de l’application ou à l’identité gérée à la portée spécifiée. Enfin, vérifiez la connexion du service à l’aide d’un pipeline de test pour assurer l’accès Azure.

Cas d’utilisation: Kubernetes avec des informations d’identification fédérées
L’identité fédérée permet aux charges de travail de Kubernetes (AKS, EKS, GKE ou clusters autogérés) d’accéder en toute sécurité aux services Azure tels que le stockage Blob, les Postgres ou les clés en échangeant des jetons via ID ENTRA – il n’y a aucune exigence d’avoir des secrets stockés dans des pods.

• Pour prendre en charge l’identité de la charge de travail de Kubernetes dans le service Azure Kubernetes, les capacités de l’émetteur OIDC et de la charge de travail doivent être activées. Vous pouvez le faire lors de la création d’un cluster ou de la mise à niveau d’un existant avec les drapeaux suivants via la CLI Azure: –Enable-OIDC-issuer et –Enable-workload-identity.
• Après l’activation, obtenez l’URL de l’émetteur OIDC en exécutant la commande ci-dessous. Cela doit être utilisé lors de la configuration des informations d’identification fédérées dans l’ID Microsoft Entra
  

  Export aks_oidc_issuer = ”$ (az aks show –name » $ ​​{cluster_name} « \ –Resource-group «$ {Resource_Group}» \ –Query «oidcissuerprofile.issuerurl» \ –Output tsv) »

• Créez un compte de service Kubernetes et annotez-le avec l’ID client de l’enregistrement d’identité / d’application géré existant ou nouvellement créé
  

  export service_account_namespace = « par défaut » Export Service_Account_name = ”Workload-Identity-sa $ random_id » Cat Apversion: V1 genre: ServiceAccount métadonnées: Annotations: azure.workload.identity / client-id: « $ {user_assigned_client_id} » Nom: « $ {service_account_name} » Espace de noms: « $ {service_account_namespace} » Eof

• Ajoutez une URL de l’émetteur de cluster, un espace de noms, un compte de service dans votre application d’enregistrement / l’identité gérée sous la session fédérée d’identification.
  

  Des références fédérées pour Kubernetes

• Une fois le déploiement de vos pods d’application, assurez-vous qu’ils pointent vers le bon compte de service Kubernetes en spécifiant l’espace de noms et le nom de service dans le manifeste du pod.
• Vous trouverez ci-dessous un échantillon de manifeste pour récupérer un secret à partir du coffre-fort Azure en utilisant l’identité de la charge de travail. Et avant cela, attribuez le rôle clé des secrets de coffre-fort à l’identité gérée ou l’enregistrement de l’application associée pour permettre l’accès aux secrets.
  

  kubectl appliquer -f – Apversion: V1 genre: god métadonnées: Nom: Sample-Workload-Identity-Key-Vault Espace de noms: $ {service_account_namespace} Étiquettes: azure.workload.identity / use: «true» SPEC: ServiceAccountName: $ {service_account_name} conteneurs: références – Image: ghcr.io/azure/azure-workload-identity/msal-go Nom: OIDC Env: – Nom: keyvault_url valeur: $ {keyvault_url} – Nom: Secret_name Valeur: $ {keyvault_secret_name} Elector de nœuds: kubernetes.io/OS: Linux Eof

Limites:-

• Il y a une limite de 20 informations d’identité fédérées par enregistrement d’application ou identité gérée assistée par l’utilisateur. Cela limite le nombre de configurations de confiance distinctes que vous pouvez avoir par identité, qui peuvent être un point d’étranglement pour les cas d’utilisation multi-environnement complexes ou multi-fournisseurs.
• Microsoft Entra ID a une correspondance stricte et sensible à la casse entre l’émetteur, le sujet et le public du jeton et les valeurs équivalentes fixées dans les informations d’identification fédérées. L’inadéquation provoque le rejet du jeton, donc l’exactitude dans la configuration est cruciale. Si vous souhaitez contourner avec une limitation de correspondance de jetons stricts, utilisez une identité fédérée flexible mais c’est aperçu public

Conclusion:-

Federating Identity with Azure Services fournit un moyen sécurisé et efficace d’authentifier sans secrets ni informations d’identification. En utilisant une identité gérée attribuée par l’utilisateur ou un enregistrement d’application, la configuration de la Fédération de l’identité de charge de travail permet à vos pipelines CI / CD – tels que ceux des actions GitHub ou des DevOps Azure – pour accéder solidement aux ressources Azure. En établissant correctement la relation de confiance et en remplissant les rôles appropriés, vous pouvez avoir un processus de déploiement plus durable, évolutif et sécurisé qui est conforme aux normes de sécurité du cloud actuelles

Vous avez trouvé cela utile? PARTAGEZ-LE