À la fin de ce tutoriel, vous installerez l’EKS Pod Identity Agent, créerez un rôle IAM de confiance pods.eks.amazonaws.com, associerez un ServiceAccount via create-pod-identity-association, et prouverez l’accès S3 depuis un pod — sans annotation IRSA legacy ni clés longues dans le cluster — le tout en ca-central-1.

Niveau : Intermédiaire · Temps estimé : 50–70 min · Versions cibles : Amazon EKS 1.29+ · EKS Pod Identity Agent · AWS CLI v2 · kubectl · Dernière vérification : 2026-09-11 · Region : ca-central-1

Slug : wow-eks-pod-identity · Série : WOW Platform / DevOps · Mot-clé SEO : EKS Pod Identity

← Connexe : EKS concepts · EKS nœuds & IRSA · EKS Ingress / IRSA LB · GitHub Actions OIDC AWS · Secrets K8s · Hub : Démarrer avec AWS · Kubernetes · Cousin Azure : Workload Identity AKS

Prérequis

• Compte AWS lab (profil lab) avec droits EKS + IAM + S3 ; budget d’alerte activé
• Cluster EKS jetable ou existant (série AWS : lab-eks) en ca-central-1, kubectl context OK
• AWS CLI v2, eksctl optionnel, notions IAM / ServiceAccount (EKS nœuds & IRSA)
• Suppression obligatoire en fin de session (association, rôle, bucket, ns ; cluster si créé pour le lab)
• Aucun secret réel dans Git : placeholders lab-* uniquement

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1
export CLUSTER_NAME=lab-eks
export NAMESPACE=podid-demo
export SERVICE_ACCOUNT_NAME=sa-podid-s3
export ROLE_NAME=eks-podid-s3-lab
ACCOUNT_ID="$(aws sts get-caller-identity --query Account --output text)"
export BUCKET="lab-podid-s3-${ACCOUNT_ID}-cac1"

aws sts get-caller-identity
kubectl config current-context
kubectl get nodes

Vérifiez l’identité lab — jamais un compte de production. Région ca-central-1 (Canada Central) pour aligner data residency et coût lab.

Ce que nous allons construire

Lab EKS Pod Identity (ca-central-1)
  ├── Addon eks-pod-identity-agent (DaemonSet)
  ├── Bucket S3 lab privé + objet démo
  ├── Rôle IAM trust pods.eks.amazonaws.com + policy S3 GetObject
  ├── Association cluster ↔ namespace ↔ ServiceAccount ↔ roleArn
  ├── Namespace + SA + Deployment aws-cli (preuve S3)
  └── Nettoyage : pod → association → rôle → bucket → ns

(Schéma — alt : « Un pod EKS obtient des credentials temporaires via Pod Identity Agent et lit un objet S3 sans IRSA ni access keys ».)

Objectif : plus de clés IAM dans les pods ; liaison API EKS (pas d’annotation IRSA). Wow : une association + un SA nu → aws s3 cp depuis le pod.

Étape 1 — Pourquoi Pod Identity (vs IRSA legacy)

IRSA (IAM Roles for Service Accounts) reste supporté : issuer OIDC du cluster, annotation eks.amazonaws.com/role-arn sur le SA, trust policy sts:AssumeRoleWithWebIdentity. Ça marche — et c’est ce que beaucoup de charts (AWS LB Controller, etc.) documentent encore (Ingress EKS).

EKS Pod Identity simplifie le modèle 2026 :

Approche	Forces	Limites
Clés longues dans le pod	Simple à « faire marcher »	Fuite, rotation, anti-pattern
IRSA	Natif OIDC ; mature	Trust JSON verbeux ; annotation SA ; issuer par cluster
Pod Identity	Association API EKS ; pas d’annotation role-arn ; trust standard pods.eks.amazonaws.com	Addon agent requis ; EKS 1.24+ (ciblez 1.29+)

Même esprit que Azure Workload Identity et OIDC GitHub → AWS : federation, zero secret long. La liaison vit hors du manifeste SA (moins d’ARN hardcodés en GitOps).

Étape 2 — Installer l’addon Pod Identity Agent

L’agent tourne en DaemonSet et injecte les credentials temporaires dans le pod associé.

# État des addons
aws eks list-addons --cluster-name "$CLUSTER_NAME" --region "$AWS_DEFAULT_REGION"

# Installer (ou mettre à jour) l’agent
aws eks create-addon 
  --cluster-name "$CLUSTER_NAME" 
  --addon-name eks-pod-identity-agent 
  --region "$AWS_DEFAULT_REGION" 
  || aws eks update-addon 
       --cluster-name "$CLUSTER_NAME" 
       --addon-name eks-pod-identity-agent 
       --region "$AWS_DEFAULT_REGION"

aws eks describe-addon 
  --cluster-name "$CLUSTER_NAME" 
  --addon-name eks-pod-identity-agent 
  --region "$AWS_DEFAULT_REGION" 
  --query 'addon.status' --output text

kubectl -n kube-system get daemonset -l app.kubernetes.io/name=eks-pod-identity-agent
kubectl -n kube-system get pods -l app.kubernetes.io/name=eks-pod-identity-agent

Attendu : addon ACTIVE, pods agent Running sur les nœuds. Sans agent, l’association IAM existe mais le pod ne reçoit pas de credentials.

Prod : pinnez une version d’addon (--addon-version), surveillez le DaemonSet, et restreignez les associations au moindre privilège (un rôle = un namespace/SA).

Étape 3 — Bucket S3 lab (preuve d’accès)

aws s3api create-bucket 
  --bucket "$BUCKET" 
  --region "$AWS_DEFAULT_REGION" 
  --create-bucket-configuration LocationConstraint="$AWS_DEFAULT_REGION"

aws s3api put-public-access-block 
  --bucket "$BUCKET" 
  --public-access-block-configuration 
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

echo "hello-pod-identity-lab" | aws s3 cp - "s3://${BUCKET}/lab/hello.txt"
aws s3 ls "s3://${BUCKET}/lab/"

Bucket privé + BPA. L’objet lab/hello.txt servira de preuve depuis le pod.

Étape 4 — Rôle IAM trust Pod Identity + policy S3

Trust policy standard Pod Identity (plus le JSON OIDC issuer/sub IRSA) :

cat > /tmp/podid-trust.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "pods.eks.amazonaws.com" },
      "Action": [ "sts:AssumeRole", "sts:TagSession" ],
      "Condition": {
        "StringEquals": {
          "aws:SourceAccount": "${ACCOUNT_ID}"
        },
        "ArnEquals": {
          "aws:SourceArn": "arn:aws:eks:${AWS_DEFAULT_REGION}:${ACCOUNT_ID}:cluster/${CLUSTER_NAME}"
        }
      }
    }
  ]
}
EOF

cat > /tmp/podid-s3-policy.json <<EOF
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListLabPrefix",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::${BUCKET}",
      "Condition": {
        "StringLike": { "s3:prefix": ["lab/*"] }
      }
    },
    {
      "Sid": "GetLabObjects",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::${BUCKET}/lab/*"
    }
  ]
}
EOF

aws iam create-role 
  --role-name "$ROLE_NAME" 
  --assume-role-policy-document file:///tmp/podid-trust.json 
  --description "Lab EKS Pod Identity S3 read ca-central-1" 
  --tags Key=Environment,Value=lab Key=ManagedBy,Value=wow-eks-pod-identity

aws iam put-role-policy 
  --role-name "$ROLE_NAME" 
  --policy-name s3-lab-get 
  --policy-document file:///tmp/podid-s3-policy.json

ROLE_ARN="$(aws iam get-role --role-name "$ROLE_NAME" --query Role.Arn --output text)"
echo "ROLE_ARN=$ROLE_ARN"

Le principal pods.eks.amazonaws.com + conditions SourceAccount / SourceArn limite l’assumption au votre cluster lab.

Étape 5 — Association Pod Identity (cluster ↔ SA ↔ rôle)

aws eks create-pod-identity-association 
  --cluster-name "$CLUSTER_NAME" 
  --namespace "$NAMESPACE" 
  --service-account "$SERVICE_ACCOUNT_NAME" 
  --role-arn "$ROLE_ARN" 
  --region "$AWS_DEFAULT_REGION"

aws eks list-pod-identity-associations 
  --cluster-name "$CLUSTER_NAME" 
  --region "$AWS_DEFAULT_REGION" 
  --query "associations[?namespace=='$NAMESPACE']" --output table

Pas besoin d’annoter le ServiceAccount avec eks.amazonaws.com/role-arn. L’association vit dans l’API EKS (auditable, centralisée). Note : le namespace et le SA doivent exister ensuite avec exactement ces noms.

Étape 6 — Namespace, ServiceAccount, preuve pod

kubectl create namespace "$NAMESPACE"
kubectl -n "$NAMESPACE" create serviceaccount "$SERVICE_ACCOUNT_NAME"

cat <<YAML | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: podid-s3-proof
  namespace: ${NAMESPACE}
  labels:
    app: podid-demo
spec:
  serviceAccountName: ${SERVICE_ACCOUNT_NAME}
  containers:
    - name: aws-cli
      image: public.ecr.aws/aws-cli/aws-cli:2.17.0
      command: ["sleep", "3600"]
  restartPolicy: Never
YAML

kubectl -n "$NAMESPACE" wait --for=condition=Ready pod/podid-s3-proof --timeout=120s

# Preuve : credentials temporaires + lecture S3
kubectl -n "$NAMESPACE" exec podid-s3-proof -- aws sts get-caller-identity
kubectl -n "$NAMESPACE" exec podid-s3-proof -- aws s3 cp "s3://${BUCKET}/lab/hello.txt" -

Attendu : get-caller-identity montre le rôle $ROLE_NAME (AssumedRole), et hello-pod-identity-lab s’affiche. Si AccessDenied : vérifiez association (ns/SA), policy S3, addon Running, et relancez le pod après création de l’association.

Étape 7 — Migration IRSA → Pod Identity (aperçu)

1. Inventaire des annotations eks.amazonaws.com/role-arn (nœuds & IRSA).
2. Nouveau trust pods.eks.amazonaws.com + create-pod-identity-association par ns/SA.
3. Preuve pod, puis retrait de l’annotation IRSA (évite double chemin).
4. Charts tiers (ex. LB Controller) : garder IRSA tant que le chart n’est pas migré.
5. IaC : Terraform aws_eks_pod_identity_association plutôt que CLI one-shot.

Migrez une app lab d’abord, puis élargissez.

Nettoyage

kubectl -n "$NAMESPACE" delete pod podid-s3-proof --ignore-not-found
kubectl delete namespace "$NAMESPACE" --ignore-not-found

ASSOC_ID="$(aws eks list-pod-identity-associations 
  --cluster-name "$CLUSTER_NAME" --region "$AWS_DEFAULT_REGION" 
  --query "associations[?namespace=='$NAMESPACE' && serviceAccount=='$SERVICE_ACCOUNT_NAME'].associationId" 
  --output text)"
if [ -n "$ASSOC_ID" ] && [ "$ASSOC_ID" != "None" ]; then
  aws eks delete-pod-identity-association 
    --cluster-name "$CLUSTER_NAME" 
    --association-id "$ASSOC_ID" 
    --region "$AWS_DEFAULT_REGION"
fi

aws iam delete-role-policy --role-name "$ROLE_NAME" --policy-name s3-lab-get
aws iam delete-role --role-name "$ROLE_NAME"

aws s3 rm "s3://${BUCKET}" --recursive
aws s3api delete-bucket --bucket "$BUCKET" --region "$AWS_DEFAULT_REGION"

Cluster créé uniquement pour ce lab : eksctl delete cluster -n "$CLUSTER_NAME" --region "$AWS_DEFAULT_REGION" (~0,10 USD/h control plane — pas overnight).

Coût approximatif lab

Ressource	Ordre de grandeur
EKS control plane	≈ 0,10 USD/h
Nœuds / Fargate	Selon votre cluster lab existant
S3 objets lab	Cents
IAM / associations	Gratuit

Alerte budget AWS ; jamais d’EKS overnight oublié.

Erreurs fréquentes

Symptôme	Cause	Correction
AccessDenied S3 dans le pod	Association absente / mauvais ns-SA / policy	Relister associations ; vérifier noms exacts ; policy lab/*
get-caller-identity = node role	Agent absent ou pod créé avant association	Addon ACTIVE ; delete/recreate pod
AssumeRole denied	Trust sans pods.eks.amazonaws.com ou mauvais SourceArn	Recréer trust + conditions Account/cluster
Addon CREATE_FAILED	Droits IAM cluster / CNI	Logs addon ; rôle cluster ; retry update-addon
Confusion IRSA + Pod Identity	Annotation role-arn encore présente	Retirer annotation après preuve Pod Identity
Bucket 404 / WrongRegion	Bucket hors ca-central-1	Recréer avec LocationConstraint Canada

FAQ

Pod Identity remplace-t-il totalement IRSA ?
Pour les nouveaux workloads 2026, privilégiez Pod Identity. IRSA reste valide ; migration progressive (addons encore documentés en IRSA).

Faut-il un issuer OIDC pour Pod Identity ?
Pas le flux IRSA (annotation + OIDC IAM). Ici : agent + associations API. L’OIDC cluster peut rester pour d’autres usages.

Le ServiceAccount doit-il être annoté ?
Non pour role-arn. SA « nu » + association API suffisent.

Pourquoi ca-central-1 ?
Data residency Canada, cohérence série AWS. Cluster et S3 dans la même région.

Différence avec Azure Workload Identity ?
Même idée federation. Azure : FIC Entra. AWS : association EKS + pods.eks.amazonaws.com. Voir Workload Identity AKS.

Quiz (3 questions)

1. Quel service principal apparaît dans le trust IAM Pod Identity ?
– A. ec2.amazonaws.com uniquement
– B. pods.eks.amazonaws.com
– C. lambda.amazonaws.com

2. Où lie-t-on namespace + ServiceAccount + rôle IAM ?
– A. Un ConfigMap kube-system
– B. aws eks create-pod-identity-association
– C. Une annotation obligatoire eks.amazonaws.com/role-arn

3. Pourquoi installer eks-pod-identity-agent ?
– A. Pour remplacer kube-proxy
– B. Pour délivrer les credentials temporaires aux pods associés
– C. Pour facturer S3

Réponses : 1‑B · 2‑B · 3‑B

Pour aller plus loin

• Documenter les associations en Terraform / CloudFormation (IaC, pas CLI one-shot)
• EKS Ingress : comparer IRSA du LB Controller vs roadmap Pod Identity
• GitHub Actions OIDC AWS · Crossplane AWS · Karpenter (wow-karpenter-eks)
• Docs AWS : EKS Pod Identities (User Guide)

Maillage WOW / Platform

Série	WOW ×50 — Platform Engineering & GitOps
Voisins	wow-karpenter-eks · wow-azure-workload-identity · wow-crossplane-aws · wow-ecs-fargate-prod
Hubs live	AWS · Kubernetes · DevOps (menus du site)

---

Meta publication (SEO) — Publish HOLD

• Title SEO : EKS Pod Identity : lab sans IRSA legacy (2026)
• Meta description (≤ 160) : Installez l’agent Pod Identity sur EKS, associez un ServiceAccount à un rôle IAM et lisez un objet S3 en ca-central-1 sans annotation IRSA ni access keys.
• Image mise en avant : assets/web/devopelastichayway/cover-wow-eks-pod-identity-1200x630.webp
• Cover alt : Pod EKS authentifié à S3 via EKS Pod Identity Agent
• Catégorie : DevOps / Platform · Niveau : Intermédiaire
• KW principal : EKS Pod Identity · Secondaires : IRSA legacy, pods.eks.amazonaws.com, create-pod-identity-association, eks-pod-identity-agent, IAM ServiceAccount EKS
• Schema : HowTo + FAQPage + Article
• URL cible : https://devopelastichayway.com/tutoriels/wow-eks-pod-identity/
• Statut : Publish HOLD — draft only, pas de Rank Math live sans feu vert
• Region lab : ca-central-1