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 :

• Augmentation des quotas de service d'API AWS. Des quotas sont appliqués aux comptes AWS, et l'utilisation de plusieurs comptes pour vos charges de travail augmente le quota global disponible pour vos charges de travail.

• Politiques de gestion des identités et des accès (IAM) simplifiées. Le fait d'accorder aux charges de travail et aux opérateurs qui les prennent en charge l'accès uniquement à leurs propres comptes AWS permet de passer moins de temps à élaborer des politiques IAM précises afin de respecter le principe du moindre privilège.

• Isolation améliorée des ressources AWS. De par leur conception, toutes les ressources fournies au sein d'un compte sont logiquement isolées des ressources mises en service dans d'autres comptes. Cette limite d'isolation vous permet de limiter les risques liés à un problème lié à une application, à une mauvaise configuration ou à des actions malveillantes. Si un problème survient au sein d'un compte, les répercussions sur les charges de travail contenues dans d'autres comptes peuvent être réduites ou éliminées.

• Autres avantages, comme décrit dans le livre blanc sur la stratégie multi-comptes AWS

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 calcul EC2 /Fargate (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 ». Donnez un nom à votre partage de ressources et sélectionnez les sous-réseaux que vous souhaitez partager. Sélectionnez à nouveau Suivant et entrez le compte à 12 chiffres IDs 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 IRSA et EKS Pod 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

EKS Pod Identities est une nouvelle façon de fournir des informations d'identification AWS à vos charges de travail exécutées sur EKS. Les identités de pods EKS simplifient la configuration des ressources AWS, car vous n'avez plus besoin de gérer les configurations OIDC pour fournir des informations d'identification AWS à vos pods sur EKS.

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

Contrairement à IRSA, EKS Pod Identities ne peut être utilisée que pour accorder directement l'accès à un rôle dans le même compte que le cluster EKS. Pour accéder à un rôle dans un autre compte AWS, les pods qui utilisent EKS Pod Identities doivent effectuer un chaînage des rôles.

Le chaînage des rôles peut être configuré dans le profil d'une application avec son fichier de configuration aws à l'aide du fournisseur d'informations d'identification de processus disponible dans divers AWS SDKs. credential_processpeut être utilisé comme source d'informations d'identification lors de la configuration d'un profil, par exemple :

# Content of the AWS Config file
[profile account_b_role]
source_profile = account_a_role
role_arn = arn:aws:iam::444455556666:role/account-b-role

[profile account_a_role]
credential_process = /eks-credential-processrole.sh

La source du script appelé par credential_process :

#!/bin/bash
# Content of the eks-credential-processrole.sh
# This will retreive the credential from the pod identities agent,
# and return it to the AWS SDK when referenced in a profile
curl -H "Authorization: $(cat $AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE)" $AWS_CONTAINER_CREDENTIALS_FULL_URI | jq -c '{AccessKeyId: .AccessKeyId, SecretAccessKey: .SecretAccessKey, SessionToken: .Token, Expiration: .Expiration, Version: 1}'

Vous pouvez créer un fichier de configuration aws comme indiqué ci-dessus avec les rôles de compte A et B et spécifier les variables AWS_CONFIG_FILE et AWS_PROFILE env dans les spécifications de votre pod. Le webhook d'identité EKS Pod ne remplace pas si les variables d'environnement existent déjà dans les spécifications du pod.

# Snippet of the PodSpec
containers:
  - name: container-name
    image: container-image:version
    env:
    - name: AWS_CONFIG_FILE
      value: path-to-customer-provided-aws-config-file
    - name: AWS_PROFILE
      value: account_b_role

Lorsque vous configurez des politiques d'approbation des rôles pour le chaînage des rôles avec les identités des pods EKS, vous pouvez référencer les attributs spécifiques d'EKS sous forme de balises de session et utiliser le contrôle d'accès basé sur les attributs (ABAC) pour limiter l'accès à vos rôles IAM à des sessions d'identité EKS Pod spécifiques, telles que le compte de service Kubernetes auquel appartient un pod.

Notez que certains de ces attributs peuvent ne pas être uniques pour tous. Par exemple, deux clusters EKS peuvent avoir des espaces de noms identiques, et un cluster peut avoir des comptes de service portant le même nom dans tous les espaces de noms. Ainsi, lorsque vous accordez l'accès via EKS Pod Identities et ABAC, il est recommandé de toujours prendre en compte l'ARN et l'espace de noms du cluster lors de l'octroi de l'accès à un compte de service.

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 en matière de rôles qui autorise uniquement un rôle à être assumé par une session de rôle lorsque les valeurs attendues sont présentes. La politique de confiance des rôles suivante ne permet à un rôle du compte de cluster EKS (ID de compte 111122223333) d'assumer un rôle que si les kubernetes-service-account 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:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalTag/kubernetes-service-account": "PayrollApplication",
                    "aws:PrincipalTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/ProductionCluster",
                    "aws:PrincipalTag/kubernetes-namespace": "PayrollNamespace"
                }
            }
        }
    ]
}

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

Lorsque vous utilisez ABAC, il est important de contrôler qui est autorisé à attribuer des rôles et des utilisateurs IAM uniquement à ceux qui en ont strictement besoin. Une personne capable de baliser un rôle ou un utilisateur IAM serait en mesure de définir des balises roles/users identiques à celles définies par EKS Pod Identities et pourrait être en mesure d'augmenter ses privilèges. Vous pouvez restreindre les personnes autorisées à définir les balises kubernetes- et les eks- balises sur le rôle IAM et les utilisateurs à l'aide de la politique IAM ou de la politique de contrôle des services (SCP).

Clusters EKS décentralisés

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 VPCs, les tables Amazon DynamoDB, etc. Chaque compte de charge de travail est indépendant, autonome et géré par le cluster Unit/Application teams. This model allows the creation of reusuable blueprints for various cluster capabilities — AI/ML commercial, le traitement par lots, l'usage général, etc., et vendent 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 une gestion/administration centralisée du réseau, une connectivité réseau simplifiée et des clusters EKS décentralisés. 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 EKS centralisés ou décentralisés

La décision d'utiliser une solution centralisée ou décentralisée dépendra de vos besoins. Ce tableau montre les principales différences entre chaque stratégie.

#	Cluster EKS centralisé	Clusters EKS décentralisés
Gestion des clusters :	Il est plus facile de gérer un seul cluster EKS que d'administrer plusieurs clusters	Une automatisation efficace de la gestion des clusters est nécessaire pour réduire la charge opérationnelle liée à la gestion de plusieurs clusters EKS
Rentabilité :	Permet la réutilisation des ressources du cluster et du réseau EKS, ce qui favorise la rentabilité	Nécessite des configurations réseau et de clusters par charge de travail, ce qui nécessite des ressources supplémentaires
Résilience :	Plusieurs charges de travail sur le cluster centralisé peuvent être affectées si un cluster est altéré	Si un cluster est endommagé, les dommages sont limités aux seules charges de travail exécutées sur ce cluster. Toutes les autres charges de travail ne sont pas affectées
Isolation et sécurité :	L'isolation/la mutualisation souple est obtenue à l'aide de constructions natives de k8s telles que. Namespaces Les charges de travail peuvent partager les ressources sous-jacentes telles que le processeur, la mémoire, etc. Les ressources AWS sont isolées dans leurs propres comptes de charge de travail qui, par défaut, ne sont pas accessibles depuis d'autres comptes AWS.	Isolation renforcée des ressources informatiques, car les charges de travail s'exécutent dans des clusters et des nœuds individuels qui ne partagent aucune ressource. Les ressources AWS sont isolées dans leurs propres comptes de charge de travail qui, par défaut, ne sont pas accessibles depuis d'autres comptes AWS.
Performances et évolutivité :	Lorsque les charges de travail augmentent à très grande échelle, vous pouvez rencontrer des quotas de service Kubernetes et AWS dans le compte du cluster. Vous pouvez déployer des comptes de cluster supplémentaires pour encore plus d'évolutivité	Au fur et à mesure que de nouveaux clusters VPCs sont présents, chaque charge de travail dispose d'un plus grand nombre de k8 disponibles et de quotas de service AWS
Réseautage :	Un seul VPC est utilisé par cluster, ce qui permet de simplifier la connectivité pour les applications de ce cluster	Le routage doit être établi entre le cluster EKS décentralisé VPCs
Gestion des accès Kubernetes :	Nécessité de conserver de nombreux rôles et utilisateurs différents dans le cluster afin de fournir un accès à toutes les équipes chargées de la charge de travail et de garantir que les ressources Kubernetes sont correctement séparées	Gestion des accès simplifiée car chaque cluster est dédié à une charge de travail/une équipe
Gestion des accès AWS :	Les ressources AWS sont déployées sur leur propre compte, auquel ils ne sont accessibles par défaut qu'avec les rôles IAM dans le compte de charge de travail. Les rôles IAM dans les comptes de charge de travail sont supposés être intercomptes avec IRSA ou EKS Pod Identities.	Les ressources AWS sont déployées sur leur propre compte, auquel ils ne sont accessibles par défaut qu'avec les rôles IAM dans le compte de charge de travail. Les rôles IAM dans les comptes de charge de travail sont fournis directement aux pods dotés d'identités de pod IRSA ou EKS.