Comprendre les identités managées dans Azure Red Hat OpenShift (préversion)

Dans cet article, découvrez les identités managées et comment les utiliser pour contrôler ou activer l’accès aux ressources Azure.

Qu’est-ce que les identités managées ?

Les identités gérées sont des entités de service d’un type spécial, qui peuvent être utilisées pour contrôler ou permettre l’accès aux ressources Azure. Ils permettent de réduire le risque de violations de sécurité en éliminant la nécessité de gérer manuellement les informations d’identification, les certificats, les clés ou les secrets. Une application (ou un service) utilise l’authentification Microsoft Entra ID pour demander des informations d’identification d’autorisation temporaires et limitées afin d’accéder à d’autres services Azure. Pour en savoir plus sur les identités managées dans Azure, consultez Présentation des identités managées pour les ressources Azure.

Dans Azure Red Hat OpenShift, l’identité de charge de travail est utilisée pour représenter une application ou une charge de travail qui s’exécute dans le cluster qui nécessite l’accès aux services Azure. Pour plus d’informations, consultez la documentation relative aux identités de charge de travail.

Les identités managées et les identités de charge de travail permettent de réduire les risques lors de la sécurisation des charges de travail et des applications en fournissant des jetons de courte durée plutôt que des informations d’identification de longue durée telles qu’un principal de service avec des informations d’identification de secret client. Cette méthode fournit une méthode d’authentification plus sécurisée pour les applications si les informations d’identification deviennent compromises en raison de facteurs suivants :

• Durée à court terme des identifiants.
• Ensemble minimal d’autorisations affiné, principe de privilège minimum. Les autorisations sont limitées uniquement à ce dont la charge de travail a besoin et uniquement aux ressources dont elle a besoin pour effectuer la tâche.

Comprendre l’architecture d’attribution de rôle d’identité

Azure Red Hat OpenShift se compose d’opérateurs de base. Les opérateurs de base sont des contrôleurs automatisés chargés de gérer une infrastructure principale de cluster Azure Red Hat OpenShift et de garantir sa stabilité et son intégrité opérationnelle. Un opérateur gère les tâches telles que : déployer et gérer les composants du plan de contrôle, gérer les mises à jour du cluster, superviser la mise en réseau et garantir que les services de niveau cluster essentiels s’exécutent correctement.

Dans un cluster Azure Red Hat OpenShift avec prise en charge des identités managées, les opérateurs principaux reçoivent des autorisations des identités managées assignées par l'utilisateur correspondantes. Une identité managée affectée par l’utilisateur doit être associée à chacun des sept opérateurs Red Hat OpenShift principaux et à l’opérateur de service Azure Red Hat OpenShift. Les opérateurs Azure Red Hat OpenShift sont les suivants :

• Opérateur de registre d'images OpenShift (image-registry)
• Opérateur Réseau OpenShift (cloud-network-config)
• Opérateur de stockage de disque OpenShift (disk-csi-driver)
• Opérateur de stockage de fichiers OpenShift (file-csi-driver)
• Opérateur d'Ingress du Cluster OpenShift
• OpenShift Cloud Controller Manager (cloud-controller-manager)
• OpenShift Machine API Operator (API de gestion des machines)
• Opérateur de service Azure Red Hat OpenShift (aro-operator)

Le cluster Azure Red Hat OpenShift nécessite une identité managée assignée par l’utilisateur. L’identité managée affectée par l’utilisateur supplémentaire est utilisée pour activer l’utilisation des huit identités managées d’opérateur Azure Red Hat OpenShift principales et effectuer la création d’informations d’identification fédérées pour toutes les identités managées. L’identité managée supplémentaire est l’identité de cluster Azure Red Hat OpenShift (aro-cluster). Pour plus d’informations sur les opérateurs de cluster Red Hat OpenShift, consultez la référence des opérateurs de cluster.

L’image suivante montre la relation entre les identités managées et l’attribution de rôle. Les nombres sont attribués aux identités managées pour illustrer l’attribution de rôle dans l’image 3.

Image 1 : rôles et identités affectées par l’utilisateur (tous les diagrammes sont illustrant uniquement)

Rôles Azure intégrés pour Azure Red Hat OpenShift

Des rôles Azure Red Hat OpenShift intégrés spécifiques accordent les autorisations requises aux identités managées prises en charge pour activer les opérations de cluster. Ces rôles suivent le modèle d’Azure en offrant un jeu d’autorisations standardisé pour une fonction de travail commune. Les rôles Azure intégrés pris en charge sont les suivants :

• Azure Red Hat OpenShift Cloud Controller Manager
• Opérateur d’entrée de cluster Azure Red Hat OpenShift
• Opérateur stockage de disque Azure Red Hat OpenShift
• Informations d’identification fédérées Azure Red Hat OpenShift
• Opérateur de stockage de fichiers Azure Red Hat OpenShift
• Opérateur Azure Red Hat OpenShift Image Registry
• Opérateur d’API Azure Red Hat OpenShift Machine
• Opérateur réseau Azure Red Hat OpenShift
• Opérateur de service Azure Red Hat OpenShift

Pour obtenir une description détaillée des rôles Azure Red Hat OpenShift intégrés, consultez les rôles intégrés Azure.

Étendue de l’attribution de rôle

Un déploiement Azure Red Hat OpenShift nécessite qu’un réseau virtuel avec au moins deux sous-réseaux vides (un pour les nœuds du plan de contrôle et l’autre pour les nœuds Worker) existe dans un groupe de ressources. Pour l’exemple d’image 2 suivant, ce groupe de ressources est appelé groupe de ressources réseau.

Image 2 - Groupe de ressources réseau

Un cluster Azure Red Hat OpenShift avec des identités managées nécessite la création d’identités managées affectées par l’utilisateur avec leurs attributions de rôles correspondantes. Suivez les étapes pour créer un cluster Azure Red Hat OpenShift avec des identités managées activées. Après avoir créé un cluster Azure Red Hat OpenShift, les attributions de rôles dans le groupe de ressources réseau ressemblent à l’exemple suivant dans l’image 3.

Image 3 : attributions de rôles sur des objets réseau

Les attributions de rôles d’identité sont effectuées au niveau de l’étendue la plus limitée possible. La plupart des identités managées se trouvent sur les sous-réseaux spécifiques requis, tandis que l’opérateur Opérateur réseau, Image Registry et Stockage de fichiers Azure, qui nécessitent des autorisations sur le réseau virtuel, sont effectuées au niveau de l’étendue du réseau virtuel.

Il existe une autre affectation qui n’est pas représentée dans l’image 3 :

• Identité de cluster : cette affectation est définie sur les autres identités elles-mêmes afin de pouvoir créer les informations d’identification fédérées pour que ces composants fonctionnent.

Les étendues d’attribution de rôle sont représentées dans l’image suivante.

Image 4 - Affectations de rôles

Considérations

Lorsque vous utilisez des identités managées et respectez les principes des privilèges minimum, il offre de nombreux avantages. Toutefois, il y a quelques considérations ou compromis à garder à l’esprit.

• Étant donné que les attributions de rôles doivent se produire au niveau de l’étendue la plus basse possible, il y aura plus d’attributions de rôles. Lors de l’exécution d’affectations au niveau de l’étendue du sous-réseau, s’il existe davantage de sous-réseaux utilisés par le cluster, par exemple, en ségrégeant des charges de travail dans différents sous-réseaux, les attributions de rôles doivent également se produire sur ces sous-réseaux.

• Étant donné qu’Azure a une limite de 4 000 attributions de rôles par abonnement, si la limite est un problème, envisagez d’effectuer les attributions de rôles à un niveau supérieur (par exemple, le réseau virtuel ou le groupe de ressources). Veillez à prendre en compte vos stratégies de sécurité et la hiérarchie d’héritage Azure qui peuvent vous accorder des autorisations pour les ressources involontaires. Par exemple, l’exécution d’une attribution de rôle au niveau du groupe de ressources accorderait à cette identité l’accès à chaque objet de ce groupe de ressources. Pour plus d’informations, consultez Présentation de l’étendue

• Selon l’étendue à laquelle vous décidez d’effectuer les attributions de rôles, le nombre total d’attributions de rôles diffère. Voici le nombre total d’attributions de rôles pour une installation de cluster de base, selon l’étendue sélectionnée pour effectuer les attributions de rôles :

  • Étendue du sous-réseau : 28 (11 sur les objets réseau + 8 sur les identités managées + 8 sur le groupe de ressources managé + 1 pour le fournisseur de ressources)
  • Étendue du réseau virtuel : 24 (7 sur les objets réseau + 8 sur les identités managées + 8 sur le groupe de ressources managé + 1 pour le fournisseur de ressources)
  • Étendue du groupe de ressources réseau : 17 (8 sur le groupe de ressources réseau + 8 sur le groupe de ressources managé + 1 pour le fournisseur de ressources) (en supposant que les identités managées se trouvent dans le même groupe de ressources réseau)
  • Il peut y avoir plus d’affectations sur les composants/fonctionnalités facultatifs
    • +4 pour chaque sous-réseau ajouté
    • +4 si vous utilisez bring your own (BYO) Network Security Group (NSG)
    • +3 si vous utilisez la table de routage
    • +2 si vous utilisez la passerelle NAT

• Étant donné que le pilote CSI (Container Storage Interface) Azure Files a toujours une dépendance sur les clés d’accès partagé, la classe de stockage de fichiers Azure par défaut est désactivée dans les clusters avec l’identité managée/charge de travail activée par défaut et est facultative pour activer votre cluster. Si vous souhaitez utiliser Azure File dans Azure Red Hat OpenShift, créez votre propre StorageClass pour utiliser des clés partagées afin d'accéder au stockage. Pour plus d’informations, consultez Comment configurer une classe de stockage de fichiers Azure.

• Lorsque vous mettez à jour votre cluster, veillez à définir l’annotation upgradeable-to sur la ressource CloudCredential du cluster. Pour plus d’informations, consultez Mettre à jour un cluster Azure Red Hat OpenShift avec des identités managées activées.

Étapes suivantes

• En savoir plus sur les Identités managées.
• Créez un cluster Azure Red Had OpenShift avec des identités managées.