Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Stratégie multi-comptes

AWS recommande d'utiliser une stratégie multi-comptes et d'utiliser les organisations AWS pour vous aider à isoler et à gérer vos applications et données professionnelles. L'utilisation d'une stratégie multi-comptes présente de nombreux avantages :

Les sections suivantes expliquent comment mettre en œuvre une stratégie multi-comptes pour vos charges de travail EKS en utilisant une approche de cluster EKS centralisée ou décentralisée.

Planification d'une stratégie de comptes à charges de travail multiples pour les clusters à locataires multiples

Dans une stratégie AWS multi-comptes, les ressources appartenant à une charge de travail donnée, telles que les compartiments S3, les ElastiCache clusters et les tables DynamoDB, sont toutes créées dans un compte AWS qui contient toutes les ressources pour cette charge de travail. Ils sont appelés comptes de charge de travail, et le cluster EKS est déployé dans un compte appelé compte de cluster. Les comptes groupés seront explorés dans la section suivante. Le déploiement de ressources dans un compte de charge de travail dédié est similaire au déploiement de ressources Kubernetes dans un espace de noms dédié.

Les comptes de charge de travail peuvent ensuite être ventilés en fonction du cycle de développement du logiciel ou d'autres exigences, le cas échéant. Par exemple, une charge de travail donnée peut avoir un compte de production, un compte de développement ou des comptes permettant d'héberger des instances de cette charge de travail dans une région spécifique. Plus d'informations sont disponibles dans ce livre blanc AWS.

Vous pouvez adopter les approches suivantes lors de la mise en œuvre de la stratégie EKS Multi account :

Cluster EKS centralisé

Dans cette approche, votre cluster EKS sera déployé dans un seul compte AWS appeléCluster Account. En utilisant les rôles IAM pour les comptes de service (IRSA) ou EKS Pod Identities pour fournir des informations d'identification AWS temporaires et AWS Resource Access Manager (RAM) pour simplifier l'accès au réseau, vous pouvez adopter une stratégie multi-comptes pour votre cluster EKS multi-tenant. Le compte de cluster contiendra le VPC, les sous-réseaux, le cluster EKS, les ressources de EC2/Fargate calcul (nœuds de travail) et toutes les configurations réseau supplémentaires nécessaires pour exécuter votre cluster EKS.

Dans une stratégie de comptes à charges de travail multiples pour un cluster à locataires multiples, les comptes AWS s'alignent généralement sur les espaces de noms Kubernetes afin d'isoler les groupes de ressources. Les meilleures pratiques en matière d'isolation des locataires au sein d'un cluster EKS doivent toujours être suivies lors de la mise en œuvre d'une stratégie multi-comptes pour les clusters EKS multi-locataires.

Il est possible d'Cluster Accountsen avoir plusieurs au sein de votre organisation AWS, et il est recommandé d'en avoir plusieurs Cluster Accounts qui répondent à vos besoins en matière de cycle de développement logiciel. Pour les charges de travail fonctionnant à très grande échelle, vous pouvez en avoir besoin de plusieurs Cluster Accounts pour garantir que les quotas de service Kubernetes et AWS sont suffisants pour toutes vos charges de travail.

|Dans le schéma ci-dessus, la RAM AWS est utilisée pour partager des sous-réseaux d'un compte de cluster vers un compte de charge de travail. Les charges de travail exécutées dans des pods EKS utilisent ensuite les identités IRSA ou EKS Pod et le chaînage des rôles pour assumer un rôle dans leur compte de charge de travail et accéder à leurs ressources AWS.

Mise en œuvre d'une stratégie de comptes multi-charges de travail pour un cluster multi-locataires

Partage de sous-réseaux avec AWS Resource Access Manager

AWS Resource Access Manager (RAM) vous permet de partager des ressources entre des comptes AWS.

Si la RAM est activée pour votre organisation AWS, vous pouvez partager les sous-réseaux VPC entre le compte de cluster et vos comptes de charge de travail. Cela permettra aux ressources AWS détenues par vos comptes de charge de travail, telles que les bases de données Amazon ElastiCache Clusters ou Amazon Relational Database Service (RDS) d'être déployées dans le même VPC que votre cluster EKS, et d'être consommables par les charges de travail exécutées sur votre cluster EKS.

Pour partager une ressource via la RAM, ouvrez la RAM dans la console AWS du compte du cluster et sélectionnez « Resource Shares » et « Create Resource Share ». Nommez votre partage de ressources et sélectionnez les sous-réseaux que vous souhaitez partager. Sélectionnez à nouveau Suivant et entrez les identifiants de compte à 12 chiffres pour les comptes de charge de travail avec lesquels vous souhaitez partager les sous-réseaux, sélectionnez à nouveau Suivant, puis cliquez sur Créer un partage de ressources pour terminer. Après cette étape, le compte de charge de travail peut déployer des ressources dans ces sous-réseaux.

Les partages de RAM peuvent également être créés par programmation ou avec une infrastructure sous forme de code.

Choisir entre EKS Pod Identities et IRSA

À l'occasion de re:Invent 2023, AWS a lancé EKS Pod Identities, un moyen plus simple de fournir des informations d'identification AWS temporaires à vos pods sur EKS. Les identités de pod IRSA et EKS sont des méthodes valides pour fournir des informations d'identification AWS temporaires à vos pods EKS et elles continueront d'être prises en charge. Vous devez déterminer quelle méthode de livraison répond le mieux à vos besoins.

Lorsque vous travaillez avec un cluster EKS et plusieurs comptes AWS, IRSA peut directement assumer des rôles dans les comptes AWS autres que celui dans lequel le cluster EKS est directement hébergé, tandis que les identités EKS Pod nécessitent que vous configuriez le chaînage des rôles. Reportez-vous à la documentation EKS pour une comparaison approfondie.

Accès aux ressources de l'API AWS avec des rôles IAM pour les comptes de service

IAM Roles for Service Accounts (IRSA) vous permet de fournir des informations d'identification AWS temporaires à vos charges de travail exécutées sur EKS. L'IRSA peut être utilisé pour obtenir des informations d'identification temporaires pour les rôles IAM dans les comptes de charge de travail à partir du compte de cluster. Cela permet à vos charges de travail exécutées sur vos clusters EKS du compte de cluster de consommer facilement les ressources de l'API AWS, telles que les compartiments S3 hébergés dans le compte de charge de travail, et d'utiliser l'authentification IAM pour des ressources telles que les bases de données Amazon RDS ou Amazon EFS. FileSystems

Les ressources de l'API AWS et les autres ressources qui utilisent l'authentification IAM dans un compte de charge de travail ne sont accessibles qu'à l'aide des informations d'identification des rôles IAM dans ce même compte de charge de travail, sauf lorsque l'accès entre comptes est possible et a été explicitement activé.

Activation de l'IRSA pour l'accès entre comptes

Pour permettre à IRSA pour les charges de travail de votre compte de cluster d'accéder aux ressources de vos comptes de charge de travail, vous devez d'abord créer un fournisseur d'identité IAM OIDC dans votre compte de charge de travail. Cela peut être fait avec la même procédure que pour configurer l'IRSA, sauf que le fournisseur d'identité sera créé dans le compte de charge de travail.

Ensuite, lorsque vous configurez IRSA pour vos charges de travail sur EKS, vous pouvez suivre les mêmes étapes que dans la documentation, mais utiliser l'identifiant de compte à 12 chiffres du compte de charge de travail, comme indiqué dans la section « Exemple de création d'un fournisseur d'identité à partir du cluster d'un autre compte ».

Une fois cette configuration terminée, votre application exécutée dans EKS pourra utiliser directement son compte de service pour assumer un rôle dans le compte de charge de travail et utiliser les ressources qu'il contient.

Accès aux ressources de l'API AWS avec EKS Pod Identities

Les identités EKS Pod constituent un autre moyen de fournir des informations d'identification AWS temporaires à vos charges de travail exécutées sur EKS. EKS Pod Identities s'intègre au plan de contrôle EKS et à un agent intégré au cluster afin que les pods reçoivent des informations d'identification sans que vous ayez à créer ou à gérer un fournisseur d'identité IAM OIDC. Les identités EKS Pod constituent l'approche recommandée pour les nouvelles charges de travail sur les types de nœuds pris en charge, tandis que l'IRSA reste une alternative entièrement prise en charge.

Avec EKS Pod Identities, vous associez un compte de service Kubernetes dans votre cluster à un rôle IAM dans le même compte AWS que le cluster. EKS utilise cette association pour obtenir des informations d'identification temporaires pour ce rôle IAM et les transmettre en toute sécurité aux pods qui utilisent le compte de service. Votre application peut ensuite utiliser les kits SDK AWS standard et la chaîne d'informations d'identification par défaut pour appeler les API AWS ; aucun fournisseur d'informations d'identification ou fichier de configuration personnalisés n'est requis.

Activation d'EKS Pod Identities pour l'accès entre comptes

EKS Pod Identities prend en charge de manière native l'accès entre comptes en utilisant un rôle IAM cible dans le compte de charge de travail et en chaînant les rôles IAM. Lorsque vous créez une association Pod Identity pour un compte de service Kubernetes, vous spécifiez à la fois un rôle IAM d'espace dans le compte de cluster et un rôle IAM cible dans le compte de charge de travail. EKS Pod Identity utilise le rôle de module pour assumer le rôle cible et renvoie des informations d'identification temporaires pour le rôle cible au module.

Consultez ce blog AWS pour une présentation détaillée et des considérations relatives à cette approche.

Identités ABAC et EKS Pod pour un accès entre comptes

Lorsque vous utilisez EKS Pod Identities pour assumer des rôles (chaîne de rôles) dans d'autres comptes dans le cadre d'une stratégie multi-comptes, vous avez la possibilité d'attribuer un rôle IAM unique à chaque compte de service qui doit accéder à un autre compte, ou d'utiliser un rôle IAM commun à plusieurs comptes de service et d'utiliser ABAC pour contrôler les comptes auxquels il peut accéder.

Pour utiliser ABAC afin de contrôler quels comptes de service peuvent assumer un rôle dans un autre compte grâce au chaînage des rôles, vous créez une déclaration de politique de confiance qui autorise uniquement le rôle IAM du pod à assumer un rôle à partir du compte de cluster EKS (ID de compte 111122223333) lorsque les valeurs attendues sont présentes. La politique de confiance des rôles suivante ne permettra au rôle pod IAM du compte de cluster EKS d'assumer un rôle que si kubernetes-service-account les kubernetes-namespace balises eks-cluster-arn et ont toutes la valeur attendue.

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:role/account-a-role"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:RequestTag/kubernetes-service-account": "PayrollApplication",
                    "aws:RequestTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/ProductionCluster",
                    "aws:RequestTag/kubernetes-namespace": "PayrollNamespace"
                }
            }
        }
    ]
}

Vous pouvez également utiliser les politiques de session EKS Pod Identity pour limiter davantage les autorisations d'un pod sans créer de rôles IAM supplémentaires. Les politiques de session sont appliquées lorsque EKS Pod Identity assume le rôle et que les autorisations qui en résultent se situent à l'intersection de la politique de rôle et de la politique de session ; pour les considérations et les étapes détaillées, consultez le blog AWS Containers sur les politiques de session pour Amazon EKS Pod Identity.

Lorsque vous utilisez cette stratégie, il est recommandé de s'assurer que le rôle IAM commun ne dispose que d'sts:TagSessionautorisations sts:AssumeRole et qu'aucun autre accès AWS n'est disponible.

Lorsque vous utilisez ABAC, il est important de contrôler qui est autorisé à attribuer des rôles IAM, des utilisateurs et des sessions STS uniquement à ceux qui en ont strictement besoin. Une personne capable de définir kubernetes- des eks- balises peut être en mesure de définir des balises identiques à celles qui seraient transmises lors du chaînage des rôles EKS Pod Identity et pourrait être en mesure d'augmenter ses privilèges. Vous pouvez restreindre l'accès à ces balises à l'aide de la politique IAM ou de la politique de contrôle des services (SCP) ; par exemple, pour les contrôles, reportez-vous à ProtectPodIdentitiesTagsOnRolesAndUserset. STS-Protect-EKS-pod-identities-tags

Choisir entre EKS Pod Identities et IRSA

Les identités IRSA et EKS Pod sont des options valides pour fournir des informations d'identification AWS temporaires à vos charges de travail EKS. Les identités EKS Pod sont recommandées pour les nouvelles applications exécutées sur les types de nœuds pris en charge et IRSA convient parfaitement lorsque OIDC et IRSA sont déjà en place ou que vous exécutez sur des plateformes non prises en charge par EKS Pod Identities.

Tenez compte des points suivants lorsque vous décidez lequel utiliser :

IRSA et EKS Pod Identities prennent tous deux en charge les stratégies multi-comptes. Vous pouvez utiliser l'une ou l'autre approche de manière cohérente dans l'ensemble de votre cluster ou adopter un modèle mixte dans lequel les charges de travail existantes continuent d'utiliser IRSA et les nouvelles charges de travail utilisent EKS Pod Identities.

De-centralized Clusters EKS

Dans cette approche, les clusters EKS sont déployés sur les comptes AWS de charge de travail respectifs et coexistent avec d'autres ressources AWS telles que les compartiments Amazon S3, les VPC, les tables Amazon DynamoDB, etc. Chaque compte de charge de travail est indépendant, autonome et géré par les équipes commerciales respectives. Unit/Application Ce modèle permet de créer des plans réutilisables pour diverses fonctionnalités du cluster (cluster, traitement par lotsAI/ML , usage général, etc.) et de vendre les clusters en fonction des besoins de l'équipe d'application. Les équipes chargées des applications et des plateformes opèrent à partir de leurs GitOpsréférentiels respectifs pour gérer les déploiements sur les clusters de charge de travail.

Dans le schéma ci-dessus, les clusters Amazon EKS et les autres ressources AWS sont déployés sur les comptes de charge de travail respectifs. Les charges de travail exécutées dans les pods EKS utilisent ensuite les identités IRSA ou EKS Pod pour accéder à leurs ressources AWS.

GitOps est un moyen de gérer le déploiement d'applications et d'infrastructures afin que l'ensemble du système soit décrit de manière déclarative dans un référentiel Git. Il s'agit d'un modèle opérationnel qui vous permet de gérer l'état de plusieurs clusters Kubernetes en utilisant les meilleures pratiques en matière de contrôle de version, d'artefacts immuables et d'automatisation. Dans ce modèle multi-clusters, chaque cluster de charge de travail est amorcé avec plusieurs dépôts Git, ce qui permet à chaque équipe (application, plateforme, sécurité, etc.) de déployer ses modifications respectives sur le cluster.

Vous utiliseriez les rôles IAM pour les comptes de service (IRSA) ou les identités EKS Pod dans chaque compte afin de permettre à vos charges de travail EKS d'obtenir des informations d'identification AWS temporaires afin d'accéder en toute sécurité à d'autres ressources AWS. Les rôles IAM sont créés dans les comptes AWS de charge de travail respectifs et les mappent aux comptes de service k8s pour fournir un accès IAM temporaire. Ainsi, aucun accès entre comptes n'est requis dans cette approche. Suivez la documentation sur les rôles IAM pour les comptes de service pour savoir comment configurer chaque charge de travail pour IRSA, et la documentation EKS Pod Identities sur la façon de configurer les identités des pods EKS dans chaque compte.

Mise en réseau centralisée

Vous pouvez également utiliser la RAM AWS pour partager les sous-réseaux VPC avec des comptes de charge de travail et y lancer des clusters Amazon EKS et d'autres ressources AWS. Cela permet de centraliser le réseau managment/administration, de simplifier la connectivité réseau et de décentraliser les clusters EKS. Consultez ce blog AWS pour une présentation détaillée et des considérations relatives à cette approche.

Dans le schéma ci-dessus, la RAM AWS est utilisée pour partager des sous-réseaux d'un compte réseau central vers un compte de charge de travail. Le cluster EKS et les autres ressources AWS sont ensuite lancés dans ces sous-réseaux dans les comptes de charge de travail respectifs. Les pods EKS utilisent les identités IRSA ou EKS Pod pour accéder à leurs ressources AWS.

Clusters centralisés et clusters De-centralized EKS

La décision d'utiliser un système centralisé ou une De-centralized solution dépendra de vos besoins. Ce tableau montre les principales différences entre chaque stratégie.