Présentation des différences entre les plateformes pour la charge de travail de workflow basé sur les événements (EDW)

Avant de répliquer la charge de travail EDW dans Azure, assurez-vous d’avoir une bonne compréhension des différences opérationnelles entre les plateformes AWS et Azure.

Cet article décrit certains des concepts clés relatifs à cette charge de travail, et fournit des liens vers des ressources pour obtenir plus d’informations.

Gestion des identités et des accès

La charge de travail AWS EDW utilise un rôle AWS Identity and Access Management (IAM) qui est assumé par le service EKS. Ce rôle est attribué à des pods EKS pour autoriser l’accès à des ressources AWS, telles que des files d’attente ou des bases de données, sans avoir besoin de stocker des informations d’identification.

Azure implémente le contrôle d’accès en fonction du rôle (RBAC) différemment d’AWS. Dans Azure, les attributions de rôles sont associées à un principal de sécurité (utilisateur, groupe, identité managée ou principal de service), et ce principal de sécurité est associé à une ressource.

Authentification entre les services

La charge de travail AWS EDW utilise la communication des services pour se connecter à une file d’attente et à une base de données. AWS EKS utilise AssumeRole, fonctionnalité d’IAM, pour acquérir des informations d’identification de sécurité temporaires en vue d’accéder à des utilisateurs, applications ou services AWS. Cette implémentation permet aux services d’assumer un rôle IAM qui accorde des droits d’accès spécifiques, procurant ainsi des autorisations limitées et sécurisées entre les services.

Pour l’accès à la base de données Amazon DynamoDB et à Amazon Simple Queue Service (SQS) via la communication des services, le flux de travail AWS utilise AssumeRole avec EKS, qui est une implémentation de la projection du volume de jetons de compte de service Kubernetes. Dans la charge de travail EKS EDW, une configuration permet à un compte de service Kubernetes d’assumer un rôle AWS Identity and Access Management (IAM). Les pods configurés pour utiliser le compte de service peuvent alors accéder à n’importe quel service AWS auquel le rôle est autorisé à accéder. Dans la charge de travail EDW, deux stratégies IAM sont définies pour accorder des autorisations d’accès à Amazon DynamoDB et Amazon SQS.

Avec AKS, vous pouvez utiliser Identité managée Microsoft Entra avec ID de charge de travail Microsoft Entra.

Une identité managée affectée par l’utilisateur est créée, et l’accès à une table Stockage Azure lui est accordé en lui attribuant le rôle Contributeur de données de table de stockage. L’identité managée se voit également accorder l’accès à une file d’attente Stockage Azure grâce à l’attribution du rôle Contributeur aux données en file d’attente du stockage. Ces attributions de rôles sont limitées à des ressources spécifiques, ce qui permet à l’identité managée de lire des messages dans une file d’attente Stockage Azure spécifique et de les écrire dans une table Stockage Azure spécifique. L’identité managée est ensuite mappée à une identité de charge de travail Kubernetes qui sera associée à l’identité des pods où les conteneurs d’applications sont déployés. Pour plus d’informations, consultez Utiliser ID de charge de travail Microsoft Entra avec AKS.

Côté client, les kits SDK Azure Python prennent en charge un moyen transparent d’exploiter le contexte d’une identité de charge de travail, ce qui élimine la nécessité pour le développeur d’effectuer une authentification explicite. Le code s’exécutant dans un espace de noms/pod sur AKS avec une identité de charge de travail établie peut s’authentifier auprès des services externes à l’aide de l’identité managée mappée.

Ressources

Les ressources suivantes peuvent vous aider à en apprendre davantage sur les différences entre AWS et Azure pour les technologies utilisées dans la charge de travail EDW :

Rubrique	AWS vers ressource Azure
Services	Comparaison des services AWS avec les services Azure
Identité	Mappage des concepts AWS IAM aux concepts similaires dans Azure
Comptes	Abonnements et comptes Azure AWS
Gestion des ressources	Conteneurs de ressources
Messagerie	Amazon SQS vers Stockage File d’attente Azure
Kubernetes	AKS pour les professionnels Amazon EKS

Étapes suivantes

Réarchitecturer la charge de travail pour AKS

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont rédigé sa version d’origine :

• Ken Kitty | Responsable de programme technique principal
• Russell de Pina | Responsable de programme technique principal
• Jenny Hayes | Développeuse de contenu confirmée
• Carol Smith | Développeuse de contenu confirmée
• Erin Schaffer | Développeuse de contenu 2