Après avoir couvert la supervision des secrets d’App Registrations sur Azure et les clés de Service Accounts & Workload Identity Federation sur GCP, bouclons notre triptyque multi-cloud avec Amazon Web Services (AWS).

Sur AWS, la première cause historique de compromission d’un compte Cloud est la fuite d’une clé d’accès statique (AWS_ACCESS_KEY_ID commençant par AKIA...) oubliée dans un pipeline CI/CD, un fichier .env ou un dépôt Git. Contrairement aux jetons temporaires émis par AWS STS (ASIA...), une clé AKIA n’expire jamais tant qu’un administrateur ou une politique automatisée ne la révoque pas.

1. L’approche 2021 : audit automatisé du Credential Report et règle AWS Config

Pour détecter les clés d’accès âgées de plus de 90 jours sur l’ensemble d’une organisation AWS, deux leviers complémentaires s’imposent :

1. La règle managée AWS Config access-keys-rotated (couplée à iam-user-unused-credentials-check) ;
2. L’extraction quotidienne du Rapport d’identifiants IAM (generate-credential-report) pour alimenter CloudWatch et Grafana :

# Générer et filtrer toutes les clés AWS IAM actives de plus de 90 jours
aws iam generate-credential-report >/dev/null
aws iam get-credential-report --query 'Content' --output text | base64 -d | \
  awk -F, 'NR==1 || $9=="true" || $14=="true" {print $1, "Key1_Active:"$9, "Key1_Rotated:"$10, "Key2_Active:"$14}'

Pour couper court à toute clé dormante avant suppression, la commande aws iam get-access-key-last-used --access-key-id AKIA... indique la date exacte, le service AWS et la région du dernier appel signé par cette clé.

2. MàJ 2026 Zéro clé AKIA grâce à OIDC, EKS Pod Identity et IAM Roles Anywhere

En 2026, créer un IAM User doté d’une clé statique AKIA pour une application ou un pipeline CI/CD est formellement proscrit par une Service Control Policy (SCP) au niveau d’AWS Organizations (Deny sur iam:CreateAccessKey). Trois mécanismes natifs couvrent désormais 100 % des cas d’usage sans aucun secret statique :

A. CI/CD sans secret via OpenID Connect (sts:AssumeRoleWithWebIdentity)

Une politique de confiance (Trust Policy) IAM vérifie cryptographiquement le jeton OIDC émis par GitHub Actions ou GitLab et restreint l’accès au seul dépôt et à la seule branche autorisés via l’opérateur StringEquals sur le claim sub :

resource "aws_iam_openid_connect_provider" "github" {
  url             = "https://token.actions.githubusercontent.com"
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = ["6938fd4d98bab03faadb97b34396831e3780aea1"]
}

data "aws_iam_policy_document" "github_oidc_trust" {
  statement {
    actions = ["sts:AssumeRoleWithWebIdentity"]
    principals {
      type        = "Federated"
      identifiers = [aws_iam_openid_connect_provider.github.arn]
    }
    condition {
      test     = "StringEquals"
      variable = "token.actions.githubusercontent.com:aud"
      values   = ["sts.amazonaws.com"]
    }
    condition {
      test     = "StringLike"
      variable = "token.actions.githubusercontent.com:sub"
      values   = ["repo:mon-org/infra-terraform:ref:refs/heads/main"]
    }
  }
}

B. Kubernetes : d’IRSA vers EKS Pod Identity

Sur Amazon EKS, EKS Pod Identity remplace désormais la mécanique complexe d’IAM Roles for Service Accounts (IRSA) : plus besoin de gérer un fournisseur OIDC par cluster ni d’annoter chaque compte de service avec un ARN en dur. Le démon local eks-pod-identity-agent fournit directement les jetons STS aux pods selon leur namespace et leur ServiceAccount.

C. Charges On-Premise & Multi-Cloud : AWS IAM Roles Anywhere

Pour un serveur Bare-Metal, un nœud Proxmox/Docker en Homelab ou une VM hébergée sur GCP/Azure qui doit pousser des sauvegardes chiffrées vers S3, IAM Roles Anywhere remplace les clés AKIA par une authentification mutuelle X.509 (PKI interne ou ACM Private CA) via l’outil open-source aws_signing_helper.

3. Matrice de synthèse Multi-Cloud (IAM Secretless 2026)