Gestion de l'accès aux clusters

Une gestion efficace des accès est essentielle pour garantir la sécurité et l'intégrité de vos clusters Amazon EKS. Ce guide explore les différentes options de gestion des accès EKS, en mettant l'accent sur l'utilisation d'AWS IAM Identity Center (anciennement AWS SSO). Nous comparerons différentes approches, discuterons de leurs compromis et mettrons en évidence les limites et considérations connues.

Options de gestion des accès EKS

Note

ConfigMapla gestion des accès basée sur le cluster (aws-auth ConfigMap) est obsolète et remplacée par l'API de gestion des accès au cluster (CAM). Pour les nouveaux clusters EKS, implémentez l'API CAM pour gérer l'accès aux clusters. Pour les clusters existants utilisant aws-auth ConfigMap, migrez vers l'API CAM.

Option 1 : centre d'identité AWS IAM avec API de gestion des accès aux clusters (CAM)

• Gestion centralisée des utilisateurs et des autorisations

• Intégration avec les fournisseurs d'identité existants (Microsoft AD, Okta, PingId etc.)

• L'API CAM utilise des entrées d'accès pour relier les principaux AWS IAM (utilisateurs ou rôles) au cluster EKS. Ces entrées fonctionnent avec les identités gérées par IAM Identity Center, ce qui permet aux administrateurs de contrôler l'accès au cluster pour les utilisateurs et les groupes définis dans Identity Center.

Flux d'authentification du cluster EKS :

1. Les principaux (utilisateurs humains) ou les processus automatisés s'authentifient via AWS IAM en présentant les autorisations de compte AWS appropriées. Au cours de cette étape, ils sont mappés au principal AWS IAM approprié (rôle ou utilisateur).

2. Ensuite, une entrée d'accès EKS mappe ce principal IAM à un principal Kubernetes RBAC (utilisateur ou groupe) en définissant une politique d'accès appropriée, qui contient uniquement les autorisations Kubernetes.

3. Lorsqu'un utilisateur final de Kubernetes essaie d'accéder à un cluster, sa demande d'authentification est traitée par la CLI aws-iam-authenticator AWS EKS et validée par rapport au contexte du cluster dans le fichier kubeconfig.

4. Enfin, l'autorisateur EKS vérifie les autorisations associées à l'entrée d'accès de l'utilisateur authentifié et accorde ou refuse l'accès en conséquence.

   • L'API utilise des politiques d'accès spécifiques à Amazon EKS pour définir le niveau d'autorisation pour chaque entrée d'accès. Ces politiques peuvent être associées aux rôles et aux autorisations définis dans IAM Identity Center, afin de garantir un contrôle d'accès cohérent entre les services AWS et les clusters EKS.

Avantages par rapport ConfigMap à la gestion des accès basée sur la base :

1. Réduction des risques de mauvaise configuration : la gestion directe basée sur l'API élimine les erreurs courantes associées à l'édition manuelle. ConfigMap Cela permet d'éviter les suppressions accidentelles ou les erreurs de syntaxe susceptibles d'empêcher les utilisateurs d'accéder au cluster.

2. Principe du moindre privilège amélioré : élimine le besoin d'une autorisation d'administrateur de cluster pour l'identité du créateur du cluster et permet une attribution des autorisations plus précise et plus appropriée. Vous pouvez choisir d'ajouter cette autorisation pour les cas d'utilisation de break-glass.

3. Modèle de sécurité amélioré : fournit une validation intégrée des entrées d'accès avant leur application. En outre, offre une intégration plus étroite avec AWS IAM pour l'authentification.

4. Opérations rationalisées : offre un moyen plus intuitif de gérer les autorisations grâce à des outils natifs d'AWS.

Bonnes pratiques :

1. Utilisez AWS Organizations pour gérer plusieurs comptes et appliquer des politiques de contrôle des services (SCPs).

2. Mettez en œuvre le principe du moindre privilège en créant des ensembles d'autorisations spécifiques pour différents rôles EKS (par exemple, administrateur, développeur, lecture seule).

3. Utilisez le contrôle d'accès basé sur les attributs (ABAC) pour attribuer dynamiquement des autorisations aux pods en fonction des attributs de l'utilisateur.

4. Auditez et révisez régulièrement les autorisations d'accès.

Considérations/limites :

1. ARNs Les rôles générés par Identity Center ont des suffixes aléatoires, ce qui les rend difficiles à utiliser dans des configurations statiques.

2. Support limité pour les autorisations détaillées au niveau des ressources Kubernetes. Une configuration supplémentaire est requise pour les rôles Kubernetes RBAC personnalisés. Outre le RBAC natif de Kubernetes, envisagez d'utiliser Kyverno pour une gestion avancée des autorisations dans les clusters EKS.

Option 2 : AWS IAM Users/Roles mappé aux groupes Kubernetes

Avantages :

1. Contrôle précis des autorisations IAM.

2. Rôle prévisible et statique ARNs

Inconvénients :

1. Frais de gestion accrus pour les comptes utilisateurs

2. Absence de gestion centralisée des identités

3. Potentiel de prolifération des entités IAM

Bonnes pratiques :

1. Utilisez des rôles IAM plutôt que des utilisateurs IAM pour améliorer la sécurité et la gérabilité

2. Implémenter une convention de dénomination pour les rôles afin de garantir la cohérence et la facilité de gestion

3. Utilisez les conditions de la politique IAM pour restreindre l'accès en fonction de balises ou d'autres attributs.

4. Faites régulièrement pivoter les clés d'accès et vérifiez les autorisations.

Considérations/limites :

1. Problèmes d'évolutivité lors de la gestion d'un grand nombre d'utilisateurs ou de rôles

2. Aucune fonctionnalité d'authentification unique intégrée

Option 3 : Fournisseurs OIDC

Avantages :

1. Intégration aux systèmes de gestion des identités existants

2. Réduction des frais de gestion pour les comptes utilisateurs

Inconvénients :

1. Complexité de configuration supplémentaire

2. Possibilité d'augmentation de la latence lors de l'authentification

3. Dépendance vis-à-vis d'un fournisseur d'identité externe

Meilleures pratiques :

1. Configurez soigneusement le fournisseur OIDC pour garantir une validation sécurisée des jetons.

2. Utilisez des jetons de courte durée et implémentez des mécanismes d'actualisation des jetons.

3. Auditez et mettez à jour régulièrement les configurations OIDC.

Consultez ce guide pour découvrir une implémentation de référence de l'intégration de fournisseurs d'authentification unique externes à Amazon EKS

Considérations/limites :

1. Intégration native limitée avec les services AWS par rapport à IAM.

2. L'URL de l'émetteur du fournisseur OIDC doit être accessible au public pour qu'EKS puisse découvrir les clés de signature.

AWS EKS Pod Identity par rapport à IRSA pour les charges de travail

Amazon EKS propose deux méthodes pour accorder des autorisations AWS IAM aux charges de travail qui s'exécutent dans des clusters Amazon EKS : les rôles IAM pour les comptes de service (IRSA) et les identités EKS Pod.

Bien que les identités IRSA et EKS Pod offrent les avantages de l'accès par le moindre privilège, de l'isolation des informations d'identification et de l'auditabilité, EKS Pod Identity est la méthode recommandée pour accorder des autorisations aux charges de travail.

Pour obtenir des conseils détaillés sur l'identité et les informations d'identification des modules EKS, reportez-vous à la section Identités et informations d'identification des meilleures pratiques en matière de sécurité.

Recommandation

Combinez IAM Identity Center avec l'API CAM

• Gestion simplifiée : en utilisant l'API de gestion des accès aux clusters conjointement avec IAM Identity Center, les administrateurs peuvent gérer l'accès au cluster EKS parallèlement aux autres services AWS, ce qui réduit le besoin de passer d'une interface à l'autre ou de procéder à des modifications ConfigMaps manuelles.

• Utilisez les entrées d'accès pour gérer les autorisations Kubernetes des principaux IAM depuis l'extérieur du cluster. Vous pouvez ajouter et gérer l'accès au cluster à l'aide de l'API EKS, de l'interface de ligne de commande AWS, d'AWS SDKs, d'AWS CloudFormation et de la console de gestion AWS. Cela signifie que vous pouvez gérer les utilisateurs avec les mêmes outils que ceux avec lesquels vous avez créé le cluster.

• Les autorisations Kubernetes granulaires peuvent être appliquées en mappant les utilisateurs ou les groupes Kubernetes aux principaux IAM associés aux identités SSO via des entrées d'accès et des politiques d'accès.

• Pour commencer, suivez Changer le mode d'authentification pour utiliser les entrées d'accès, puis Migration des entrées aws-auth existantes pour accéder aux ConfigMap entrées.