EKS — Elastic Kubernetes Service en profondeur : IAM, Fargate, Karpenter et GuardDuty

⏱️

Temps de lecture estimé
~18 minutes

Cet article fait partie de la série Kubernetes Managé & Edge. Si tu cherches le guide de choix et le tableau comparatif global, commence par là.

EKS est la solution Kubernetes la plus complexe à configurer correctement et aussi la plus puissante si tu vis dans l’écosystème AWS. La richesse d’IAM est à la fois sa plus grande force et sa plus grande source de risques. Un cluster EKS parfaitement configuré côté Kubernetes mais avec des permissions IAM qui rendaient toute la sécurité Kubernetes inutile , c’est un classique….

La règle d’or avec EKS : IAM est la première et la dernière ligne de défense. Si tes permissions IAM sont trop larges, peu importe ta configuration Kubernetes, un pod compromis peut tout faire sur ton compte AWS.

Architecture EKS

Plan de contrôle managé (AWS)

AWS gère le plan de contrôle EKS, avec une particularité importante par rapport à AKS et GKE : le plan de contrôle EKS est facturé. Le cout est par heure et par cluster, un point à prendre en compte si vous gérez de nombreux clusters.

AWS gère :

kube-apiserver multi-AZ avec NLB
etcd répliqué cross-AZ
Rotation des certificats
Mises à jour du plan de contrôle

Les trois modes de worker nodes

Managed Node Groups : AWS gère l’aspect VMSS (création, mise à jour, rolling update), toi tu définis la taille et le nombre de nodes. C’est le mode le plus courant.

Fargate : chaque pod tourne dans une micro-VM AWS Fargate isolée. Pas de node à gérer, facturation à la seconde par pod. Idéal pour les workloads batch, les APIs sporadiques, et les équipes qui ne veulent pas gérer d’infrastructure.

EKS Auto Mode : AWS gère automatiquement les nodes via Karpenter. Équivalent d’AKS Automatic et GKE Autopilot.

EKS Auto Mode vs configuration manuelle

Aspect	EKS Standard (MNG)	EKS Auto Mode
Gestion nodes	Manuelle (node groups)	Automatique (Karpenter géré)
Sécurité par défaut	À configurer	Baseline enforced
Access entries	Optionnel	Activé par défaut
Pod Identity	À configurer	Recommandé par défaut
Optimisation coût	À configurer	Automatique (spot/on-demand)

IAM — La couche la plus critique d’EKS

Le mappage IAM → Kubernetes (aws-auth ConfigMap)

Pendant longtemps, la seule façon de mapper des identités AWS (Users, Roles) vers des utilisateurs Kubernetes était via le ConfigMap aws-auth dans kube-system. Ce ConfigMap est la clé de voûte des accès EKS et aussi l’une des sources de problemes les plus fréquentes.

# aws-auth ConfigMap — mapping IAM → Kubernetes
apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    # Nodes workers (obligatoire)
    - rolearn: arn:aws:iam::123456789:role/eks-node-role
      username: system:node:
      groups:
        - system:bootstrappers
        - system:nodes
    # Pipeline CI/CD
    - rolearn: arn:aws:iam::123456789:role/cicd-deploy-role
      username: cicd-deployer
      groups:
        - deployers
  mapUsers: |
    # Admin humain
    - userarn: arn:aws:iam::123456789:user/alice
      username: alice
      groups:
        - system:masters  # ⚠️ Attention : cluster-admin !

Danger !!!! system:masters : ce groupe donne des droits cluster-admin. A ne jamais affecter en production a des humains , il faut créer des roles séparés de type ClusterRoles avec des permissions granulaires à la place.

EKS Access Entries — Le successeur d’aws-auth

Depuis EKS 1.29, les Access Entries remplacent le ConfigMap aws-auth. C’est la méthode moderne à adopter.

EKS Pod Identity — La gestion d’identité moderne

IRSA (IAM Roles for Service Accounts) était l’ancienne méthode. Pod Identity est le successeur, disponible depuis EKS 1.27 et beaucoup plus simple à configurer.

L’avantage par rapport à IRSA : pas d’annotation sur le ServiceAccount. La liaison est entièrement côté AWS, ce qui évite que les développeurs puissent modifier la liaison depuis le cluster.

Réseau EKS — VPC CNI et Security Groups for Pods

Amazon VPC CNI — L’intégration réseau native

Le CNI par défaut d’EKS attribue des IPs VPC directement aux pods.

Avantage : les pods sont directement routables dans le VPC, sans overlay.
Inconvénient : consommation d’adresses IP importante sur les grands clusters (et…il parait que AWS facturerait les IPs VPC utilisées par les pods à terme…).

Azure CNI Overlay résout ce problème sur AKS. Sur EKS, la solution équivalente est VPC CNI with prefix delegation :

Security Groups for Pods

EKS supporte l’attribution de Security Groups AWS directement aux pods. C’est une capacité unique parmi les trois clouds. Les Security Groups sont un mécanisme réseau AWS natif, plus familier aux équipes AWS que les NetworkPolicies Kubernetes.

# Associer le Security Group au pod via SecurityGroupPolicy
apiVersion: vpcresources.k8s.aws/v1beta1
kind: SecurityGroupPolicy
metadata:
  name: backend-sgp
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  securityGroups:
    groupIds:
    - sg-backend-xxxxxxxx

Amazon GuardDuty pour EKS

GuardDuty EKS Protection est l’équivalent AWS de Defender for Containers (Azure) et Security Command Center (GCP). Il analyse les audit logs EKS et l’activité des nodes en temps réel.

GuardDuty détecte notamment :

Kubernetes:AnonymousAccess — accès anonyme à l’API Server
Kubernetes:RBAC.PrivilegedAccess — montée en privilège via RBAC
Kubernetes:MaliciousIPCaller — communication depuis/vers des IPs malveillantes connues
CredentialAccess:Kubernetes.MaliciousIPCaller.Custom — accès depuis des IPs suspectes
Execution:Kubernetes.ExecInPod — exécution de commandes dans des pods existants

Karpenter — L’auto-scaling intelligent

Karpenter est né dans l’écosystème EKS et c’est là qu’il est le plus mature. Sa différence avec le Cluster Autoscaler classique : il choisit intelligemment le type de node à créer en fonction des contraintes du pod.

# NodePool Karpenter — définir les contraintes de provisionnement
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
  name: production-pool
spec:
  template:
    spec:
      requirements:
      - key: kubernetes.io/arch
        operator: In
        values: ["amd64", "arm64"]
      - key: karpenter.sh/capacity-type
        operator: In
        values: ["spot", "on-demand"]
      - key: karpenter.k8s.aws/instance-family
        operator: In
        values: ["m5", "m6i", "m6a", "m7i"]
      nodeClassRef:
        group: karpenter.k8s.aws
        kind: EC2NodeClass
        name: production-class
  disruption:
    consolidationPolicy: WhenEmptyOrUnderutilized
    consolidateAfter: 1m
  limits:
    cpu: "1000"
    memory: 4000Gi
---
apiVersion: karpenter.k8s.aws/v1
kind: EC2NodeClass
metadata:
  name: production-class
spec:
  amiFamily: AL2023
  role: eks-node-role
  subnetSelectorTerms:
  - tags:
      karpenter.sh/discovery: mon-cluster
  securityGroupSelectorTerms:
  - tags:
      karpenter.sh/discovery: mon-cluster
  blockDeviceMappings:
  - deviceName: /dev/xvda
    ebs:
      volumeSize: 50Gi
      volumeType: gp3
      encrypted: true  # Chiffrement EBS activé !

Le paramètre consolidateAfter: 1m permet à Karpenter de supprimer les nodes sous-utilisés 1 minute après qu’ils soient vides, réduisant significativement les coûts.

EKS Anywhere et Hybrid Nodes

EKS Anywhere - Kubernetes managé on-premises

EKS Anywhere permet de déployer des clusters EKS sur ton infrastructure on-premises avec le même plan de contrôle managé qu’en cloud. Le plan de contrôle peut fonctionner localement ou être géré depuis AWS.

EKS Hybrid Nodes

EKS Hybrid Nodes permet d’ajouter des machines on-premises comme workers dans un cluster EKS cloud. La connexion se fait via AWS Systems Manager ou Direct Connect.

Attention sécurité EKS Hybrid Nodes : la surface d’attaque s’étend considérablement. Les nodes on-premises doivent être dans un réseau correctement segmenté, avec des Security Groups et des NetworkPolicies qui tiennent compte des IPs du réseau local.

L’endpoint public par défaut — Le piège classique

L’API Server EKS est accessible publiquement par défaut. Il est protégé par IAM, mais une IAM misconfiguration peut exposer l’API Server à Internet.

# Restreindre l'accès à l'API Server à des CIDR connus
aws eks update-cluster-config \
  --name mon-cluster \
  --resources-vpc-config \
    endpointPublicAccess=true,\
    publicAccessCidrs="203.0.113.0/24,198.51.100.0/24"

# Ou passer entièrement en mode private (nécessite VPN/Direct Connect)
aws eks update-cluster-config \
  --name mon-cluster \
  --resources-vpc-config \
    endpointPublicAccess=false,\
    endpointPrivateAccess=true

Exemple concret — SSRF + Metadata AWS = escalade de privilèges

Voici un scénario d’attaque et d’escalade de privilgèe concret via SSRF.

Contexte : Un cluster EKS avec une application web contenant une vulnérabilité SSRF (Server-Side Request Forgery). Les nodes utilisent des EC2 Instance Profiles avec des permissions IAM larges.

Scénario d’attaque :

L’attaquant découvre un endpoint SSRF dans l’application : https://app.example.com/fetch?url=<URL>.
Il envoie une requête vers le metadata service AWS : https://app.example.com/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/.
Le service retourne le nom du rôle IAM de l’EC2 node.
Une deuxième requête récupère les credentials temporaires du rôle : http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>.
Avec ces credentials (AccessKeyId + SecretAccessKey + Token), l’attaquant peut appeler l’API AWS avec les permissions du rôle node.
Si le rôle node a des permissions trop larges (ex: S3:* ou EC2:*), l’attaquant peut exfiltrer des données ou créer des ressources AWS.

Ce qui aurait évité cette attaque :

IMDSv2 obligatoire : le metadata service v2 nécessite un token PUT avant tout GET, cela bloque les requêtes SSRF classiques.
Permissions IAM minimales sur les nodes : les nodes ont besoin de très peu de permissions (ECR pull, autoscaling describe)
Pod Identity plutôt qu’Instance Profile : les pods ont leurs propres permissions minimales, pas celles du node
NetworkPolicy : le pod ne devrait pas pouvoir contacter 169.254.169.254

Quelques références pour aller plus loin

✓ À retenir 📌

✓ IAM est la première et dernière défense d'EKS : des permissions trop larges sur un rôle pod rendent toute la sécurité Kubernetes inutile. Applique le principe du moindre privilège sur chaque rôle, teste-le avec aws iam simulate-principal-policy.

✓ Migre d'IRSA vers Pod Identity : plus simple à gérer, pas d'annotation sur le ServiceAccount (moins de risques d'erreurs), et le binding est côté AWS (non modifiable depuis le cluster).

✓ L'endpoint public est activé par défaut — restreins les CIDR autorisés ou passe en private endpoint dès le provisionnement. Ne laisse pas l'API Server accessible depuis 0.0.0.0/0.

✓ IMDSv2 obligatoire sur tous les nodes : empêche les attaques SSRF classiques qui visent le metadata service. C'est une protection simple à activer qui bloque toute une classe d'attaques.

✓ GuardDuty EKS est ton SOC intégré : il analyse les audit logs Kubernetes et l'activité runtime en temps réel. Active-le systématiquement — le coût est marginal par rapport à la visibilité apportée.

EKS