Rôles IAM pour les comptes de service (IRSA)

Lorsqu’un pod exécuté dans EKS doit appeler une API AWS — par exemple lire des données dans S3 ou écrire dans DynamoDB — il a besoin d’informations d’identification AWS. L’approche naïve consiste à créer un utilisateur IAM et à inscrire ses clés d’accès en dur dans des variables d’environnement. Cette méthode n’est pas sécurisée et enfreint le principe du moindre privilège, car tous les pods du même nœud partagent ces informations d’identification. IAM Roles for Service Accounts (IRSA) résout ce problème en associant directement des rôles IAM précis aux comptes de service Kubernetes.

IRSA repose sur la fédération OpenID Connect (OIDC). EKS crée un fournisseur OIDC pour votre cluster. Lorsqu’un pod fait référence à un compte de service associé à une annotation contenant un ARN de rôle IAM, EKS injecte dans le pod un jeton de compte de service projeté et signé. Le SDK AWS présent dans le pod échange ce jeton contre des informations d’identification AWS temporaires au moyen de l’API AssumeRoleWithWebIdentity de AWS STS — aucune clé longue durée n’est nécessaire.

Avant d’utiliser IRSA, vous devez associer l’émetteur OIDC d’EKS en tant que fournisseur d’identité approuvé dans votre compte AWS. Cela crée une ressource de fournisseur OIDC IAM que AWS STS reconnaîtra. La commande eksctl s’en charge automatiquement. Une fois la ressource créée, vous pouvez la vérifier dans la console IAM, sous Fournisseurs d’identité.

Le rôle IAM utilisé par IRSA doit disposer d’une politique d’approbation autorisant le fournisseur OIDC à l’assumer, avec une portée limitée à un espace de noms Kubernetes et à un compte de service précis. La condition utilise la revendication sub du jeton OIDC, définie sur system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME. Ainsi, seuls les pods utilisant ce compte de service précis peuvent assumer le rôle — et non n’importe quel pod du cluster.

Créez un ServiceAccount Kubernetes dans l’espace de noms cible et annotez-le avec l’ARN du rôle IAM. Lorsqu’un pod fait référence à ce compte de service, EKS injecte automatiquement le jeton OIDC et deux variables d’environnement (AWS_WEB_IDENTITY_TOKEN_FILE et AWS_ROLE_ARN). Le SDK AWS les détecte automatiquement et appelle STS pour obtenir des informations d’identification temporaires — aucune modification du code de votre application n’est nécessaire.

Dans la spécification de votre pod ou de votre déploiement, définissez serviceAccountName sur le compte de service annoté. Lorsqu’EKS planifie le pod, il monte automatiquement le jeton OIDC à l’emplacement /var/run/secrets/eks.amazonaws.com/serviceaccount/token et définit les variables d’environnement requises. Tout appel au SDK AWS effectué dans le pod utilise de manière transparente les informations d’identification du rôle IAM associé, sans configuration explicite des informations d’identification.

Avec un rôle IAM de nœud, chaque pod d’un nœud hérite des mêmes autorisations : un pod compromis peut accéder à tous les services AWS auxquels le nœud est autorisé à accéder. Avec IRSA, chaque pod, par l’intermédiaire de son compte de service, assume uniquement le rôle dont il a besoin. Cela applique le principe du moindre privilège au niveau du pod et limite l’étendue d’un éventuel incident de sécurité. AWS recommande IRSA plutôt que les rôles au niveau des nœuds pour tous les nouveaux déploiements EKS.

eksctl peut créer l’association OIDC, le rôle IAM, la politique d’approbation et l’annotation du ServiceAccount Kubernetes en une seule commande, à l’aide de create iamserviceaccount. C’est la manière la plus simple de configurer IRSA sans rédiger manuellement le JSON de la politique d’approbation. Vous indiquez l’espace de noms, le nom du compte de service et l’ARN de la politique IAM à associer ; eksctl s’occupe du reste.

De nombreux modules complémentaires et contrôleurs EKS nécessitent IRSA pour fonctionner : l’autoscaler du cluster doit pouvoir appeler l’API Auto Scaling d’EC2, le contrôleur d’équilibrage de charge AWS doit pouvoir créer et gérer des ressources ELB, external-dns doit disposer d’un accès en écriture à Route 53, et le pilote CSI EBS doit pouvoir créer et attacher des volumes EBS. Utilisez toujours IRSA pour ces composants système — n’accordez jamais ces autorisations au niveau du rôle IAM du nœud.

Les jetons IRSA ont une durée de vie courte et sont automatiquement renouvelés par le contrôleur de projection des jetons Kubernetes avant leur expiration. L’audience du jeton par défaut est sts.amazonaws.com et son expiration est fixée à 24 heures, mais le contrôleur les actualise à 80 % de leur durée de vie. Les informations d’identification AWS STS obtenues via IRSA sont elles aussi temporaires, généralement valides pendant 1 heure. Cette rotation automatique élimine la charge liée à la rotation des informations d’identification inhérente aux clés d’accès IAM de longue durée.

Chaque fois qu’un pod assume un rôle IAM via IRSA, AWS CloudTrail enregistre un événement AssumeRoleWithWebIdentity. L’événement contient l’ARN du rôle assumé, le sujet du jeton OIDC (system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT) et l’adresse IP source. Vous disposez ainsi d’une piste d’audit complète indiquant quels pods ont accédé à quels services AWS et à quel moment — un élément essentiel pour la conformité et l’analyse des incidents dans les environnements réglementés.

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Dans cette leçon, vous avez appris que : IRSA utilise la fédération OIDC pour échanger les jetons de comptes de service Kubernetes contre des informations d’identification AWS temporaires, que les politiques d’approbation des rôles IAM limitent l’accès à un espace de noms et à un compte de service précis, et qu’IRSA fournit le moindre privilège par pod, ce qui est largement supérieur aux rôles IAM au niveau des nœuds. Nous allons maintenant découvrir les métriques, les espaces de noms et les dimensions de CloudWatch pour surveiller vos ressources AWS.