Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

IRSA (IAM Roles for Service Accounts)

devsecops

Définition

IRSA (IAM Roles for Service Accounts) est un mécanisme de sécurité d'Amazon EKS (Elastic Kubernetes Service) qui permet aux pods Kubernetes d'assumer des rôles AWS IAM sans utiliser de credentials statiques (clés d'accès AWS). Cette fonctionnalité, introduite en 2019, résout l'un des problèmes de sécurité les plus critiques dans les environnements Kubernetes sur AWS : la gestion des identités et des accès aux services AWS depuis les workloads conteneurisés. Le problème fondamental qu'IRSA résout est le suivant : les applications s'exécutant dans des pods Kubernetes ont souvent besoin d'accéder à des services AWS (S3, DynamoDB, SQS, RDS, etc.). Sans IRSA, les équipes utilisaient des clés d'accès AWS statiques (Access Key ID + Secret Access Key) stockées dans des Secrets Kubernetes ou des variables d'environnement — une approche présentant des risques majeurs : rotation manuelle laborieuse, exposition potentielle dans les logs ou les dumps mémoire, et impossibilité de limiter les permissions par pod. IRSA fonctionne via le mécanisme OpenID Connect (OIDC) : EKS expose un fournisseur d'identité OIDC associé au cluster. Quand un pod utilise un Service Account annoté avec l'ARN d'un rôle IAM, le Pod Identity Webhook (webhook d'admission Kubernetes) injecte automatiquement un token OIDC signé comme variable d'environnement (AWS_WEB_IDENTITY_TOKEN_FILE). Le AWS SDK utilise ce token pour appeler l'API STS AssumeRoleWithWebIdentity et obtenir des credentials temporaires (valides 1h par défaut) limités aux permissions du rôle IAM associé. Les avantages de sécurité d'IRSA sont considérables : élimination des credentials statiques à longue durée de vie, permissions limitées au minimum nécessaire par pod (principle of least privilege), rotation automatique des credentials temporaires, traçabilité complète dans CloudTrail (chaque appel d'API inclut le Service Account et le namespace Kubernetes), et impossibilité pour un pod compromis d'accéder aux credentials d'un autre pod. AWS EKS Pod Identity, lancé en 2023, simplifie encore la configuration d'IRSA en éliminant la nécessité de configurer manuellement le fournisseur OIDC et les trust policies IAM.

Architecture et flux d'authentification IRSA

Le flux IRSA : 1) Le Service Account Kubernetes est annoté avec eks.amazonaws.com/role-arn. 2) À la création du pod, le Pod Identity Webhook injecte AWS_WEB_IDENTITY_TOKEN_FILE pointant vers un token OIDC signé par EKS. 3) Le SDK AWS appelle STS AssumeRoleWithWebIdentity avec ce token. 4) STS vérifie la signature OIDC auprès du provider EKS et valide les conditions de la trust policy (sub = system:serviceaccount:namespace:name). 5) Des credentials temporaires (15min à 12h) sont retournés au SDK.

Configuration pas-à-pas

Mise en place d'IRSA : 1) Activer le provider OIDC sur le cluster EKS (eksctl utils associate-iam-oidc-provider). 2) Créer le rôle IAM avec une trust policy autorisant le service account spécifique. 3) Créer ou annoter le Service Account Kubernetes (kubectl annotate sa nom eks.amazonaws.com/role-arn=arn:aws:iam::123:role/MonRole). 4) Référencer le Service Account dans le PodSpec. Le SDK AWS détecte automatiquement les variables d'environnement injectées.

IRSA vs EKS Pod Identity vs kube2iam

IRSA (2019) nécessite une configuration de trust policy IAM et OIDC. EKS Pod Identity (2023) simplifie la configuration via une association directe pod identity/rôle gérée par EKS, sans manipulation de trust policies. kube2iam et kiam sont des solutions communautaires antérieures qui fonctionnent via un DaemonSet interceptant les appels IMDS — moins recommandées car plus complexes et présentant des risques de timeout. La migration vers EKS Pod Identity est recommandée pour les nouveaux déploiements.

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis