IAM décentralisé et sécurité multi-cloud : Construire le Zero Trust à l'échelle

L'ère du modèle de sécurité traditionnel du château fort (castle-and-moat) est révolue. Lorsque votre infrastructure s'étend sur AWS, GCP, Azure et des environnements sur site (on-premise), il n'y a plus de périmètre. Dans cette réalité, l'IAM décentralisé et la sécurité multi-cloud ne sont pas seulement des modèles architecturaux - c'est la seule défense viable contre les déplacements latéraux et les attaques complexes de la chaîne d'approvisionnement. L'identité de l'émetteur de la requête, qu'il soit humain ou machine, constitue la nouvelle frontière.

La plupart des organisations échouent dans cette tâche. Elles tentent d'adapter des fournisseurs d'identité (IdP) centralisés traditionnels à des clusters Kubernetes multi-cloud dynamiques, ce qui entraîne des intégrations fragiles, des privilèges excessifs et des points de défaillance uniques. Dans cet article, nous analysons le problème, proposons une architecture robuste et vous montrons exactement comment la mettre en œuvre sans compromettre la vélocité des développeurs.

Le problème : Le piège de l'identité en étoile (Hub-and-Spoke)

Lorsque les entreprises adoptent pour la première fois une stratégie multi-cloud, elles acheminent généralement l'ensemble des flux d'authentification et d'autorisation via un annuaire centralisé unique (par exemple, Active Directory ou une seule instance Okta). Cela crée le piège de l'identité en étoile (Hub-and-Spoke Identity Trap).

Chaque service dans AWS tentant d'accéder à une base de données dans GCP doit s'authentifier auprès du hub central. Cette conception introduit trois failles critiques :

1. La latence : Une architecture de microservices effectuant des centaines d'appels API internes par seconde ne peut pas se permettre la latence d'un aller-retour vers un IdP central.
2. La disponibilité : Si l'IdP central tombe en panne, c'est l'ensemble de l'infrastructure multi-cloud qui s'arrête.
3. Le rayon d'impact (blast radius) : Un annuaire central compromis donne à l'attaquant les clés de tout le royaume, à travers l'ensemble des clouds.

Vous devez faire en sorte que les identités soient vérifiées localement, mais gérées globalement.

Pourquoi l'IAM décentralisé et la sécurité multi-cloud sont difficiles

Décentraliser l'identité signifie distribuer la confiance, ce qui requiert des preuves cryptographiques continuellement validées. Lorsqu'une charge de travail (workload) dans AWS EKS doit lire un objet dans un compartiment Google Cloud Storage, comment GCP sait-il qu'il peut faire confiance au pod AWS ?

L'approche naïve consiste à utiliser des identifiants statiques à longue durée de vie (par exemple, des clés d'accès AWS ou des fichiers JSON de compte de service GCP) stockés dans Vault ou dans des secrets Kubernetes. C'est un anti-pattern majeur. Les identifiants statiques fuient, ils sont rarement renouvelés et ils violent le principe fondamental du Zero Trust : un accès éphémère et limité.

Le défi consiste à établir une fédération d'identités de workloads entre des domaines de confiance disparates. Vous devez associer une identité du Domaine A (fournisseur OIDC AWS) à un rôle dans le Domaine B (IAM GCP) sans jamais échanger de secrets à longue durée de vie.

L'architecture recommandée : La fédération d'identités de workloads (Workload Identity Federation)

Nous préconisons une architecture dans laquelle chaque environnement agit comme son propre fournisseur d'identité (IdP) pour les workloads qu'il héberge. Ces IdP locaux fédèrent ensuite la confiance avec les autres environnements cloud à l'aide d'OpenID Connect (OIDC).

Notre architecture de référence utilise :

• Kubernetes (EKS v1.30) : Hébergement des workloads.
• AWS IAM OIDC Provider : L'IdP local pour EKS.
• GCP Workload Identity Federation : Faisant confiance au fournisseur OIDC AWS.
• SPIFFE/SPIRE (v1.8.0) : Pour le mTLS interne de service à service et la délivrance d'identités.

Au lieu de transmettre des secrets, le workload demande un jeton (token) à courte durée de vie à son environnement local. Ce jeton est signé cryptographiquement par l'IdP local. L'environnement cible (GCP) vérifie la signature, associe la revendication (claim) OIDC à un rôle IAM local et accorde un accès temporaire.

Implémentation : D'AWS EKS à GCP BigQuery

Voyons une implémentation concrète. Nous avons un service d'ingestion de données s'exécutant dans un cluster AWS EKS qui doit écrire dans un ensemble de données GCP BigQuery.

1. Configurer le fournisseur AWS EKS OIDC

Tout d'abord, assurez-vous que votre cluster EKS est associé à un fournisseur IAM OIDC. Cela permet aux comptes de service Kubernetes d'assumer des rôles IAM, mais surtout, cela nous donne une URL d'émetteur (issuer URL) à laquelle GCP peut faire confiance.

# Terraform v1.8.0
# AWS Provider v5.40.0

data "tls_certificate" "eks" {
  url = aws_eks_cluster.main.identity[0].oidc[0].issuer
}

resource "aws_iam_openid_connect_provider" "eks" {
  client_id_list  = ["sts.amazonaws.com"]
  thumbprint_list = [data.tls_certificate.eks.certificates[0].sha1_fingerprint]
  url             = aws_eks_cluster.main.identity[0].oidc[0].issuer
}

2. Créer le pool d'identités de workloads (Workload Identity Pool) dans GCP

Dans GCP, nous créons un Workload Identity Pool et un Provider. Le Provider pointe vers l'URL de l'émetteur OIDC AWS EKS. Nous associons la revendication sub (qui contient le namespace Kubernetes et le nom du compte de service) à un sujet IAM Google.

# GCP Provider v5.20.0

resource "google_iam_workload_identity_pool" "aws_pool" {
  workload_identity_pool_id = "aws-eks-pool"
  display_name              = "AWS EKS Trust Pool"
  description               = "Identity pool for EKS workloads"
}

resource "google_iam_workload_identity_pool_provider" "aws_provider" {
  workload_identity_pool_id          = google_iam_workload_identity_pool.aws_pool.workload_identity_pool_id
  workload_identity_pool_provider_id = "aws-eks-provider"
  display_name                       = "AWS EKS OIDC Provider"
  
  attribute_mapping = {
    "google.subject" = "assertion.sub"
    "attribute.namespace" = "assertion['kubernetes.io']['namespace']"
  }
  
  oidc {
    issuer_uri = aws_eks_cluster.main.identity[0].oidc[0].issuer
  }
}

3. Lier le compte de service GCP

Nous créons maintenant un compte de service GCP doté des autorisations nécessaires pour écrire dans BigQuery, et nous permettons au compte de service Kubernetes spécifique (via l'Identity Pool) de l'usurper (impersonation).

resource "google_service_account" "bq_writer" {
  account_id   = "bq-writer-sa"
  display_name = "BigQuery Writer Service Account"
}

resource "google_project_iam_member" "bq_data_editor" {
  project = var.project_id
  role    = "roles/bigquery.dataEditor"
  member  = "serviceAccount:${google_service_account.bq_writer.email}"
}

resource "google_service_account_iam_member" "workload_identity_user" {
  service_account_id = google_service_account.bq_writer.name
  role               = "roles/iam.workloadIdentityUser"
  
  # La chaîne de caractères correspond à l'association de sujet Google configurée sur le fournisseur
  # format: principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/POOL_ID/subject/SUBJECT
  member = "principal://iam.googleapis.com/${google_iam_workload_identity_pool.aws_pool.name}/subject/system:serviceaccount:data-ingest:bq-writer"
}

4. Le code applicatif

L'application s'exécutant dans EKS utilise le SDK Google Cloud. Le SDK détecte automatiquement le jeton de compte de service projeté fourni par EKS, l'utilise pour s'authentifier auprès du pool d'identités de workloads GCP et récupère un jeton d'accès temporaire pour le compte bq-writer-sa. Aucune clé statique n'est requise.

# Définition du Service Account et du Pod Kubernetes
apiVersion: v1
kind: ServiceAccount
metadata:
  name: bq-writer
  namespace: data-ingest
  annotations:
    # Optionnel : Si vous avez également besoin d'autorisations AWS
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/bq-writer-role

---
apiVersion: v1
kind: Pod
metadata:
  name: bq-writer-app
  namespace: data-ingest
spec:
  serviceAccountName: bq-writer
  containers:
  - name: app
    image: my-registry/bq-writer:v1.2.0
    env:
    # Indiquer au SDK Google où trouver la configuration des identifiants
    - name: GOOGLE_APPLICATION_CREDENTIALS
      value: /var/run/secrets/google/credentials.json
    volumeMounts:
    - name: google-cloud-key
      mountPath: /var/run/secrets/google
    - name: k8s-token
      mountPath: /var/run/secrets/tokens
  volumes:
  - name: google-cloud-key
    configMap:
      name: workload-identity-config
  - name: k8s-token
    projected:
      sources:
      - serviceAccountToken:
          path: oidc-token
          expirationSeconds: 3600
          audience: sts.amazonaws.com # Ou votre audience GCP

Pièges à éviter

L'implémentation de cette architecture comporte des risques. Voici les modes de défaillance les plus courants que nous observons lorsque les équipes adoptent l'IAM décentralisé :

1. Association de revendications (claims) trop large

Lors de la configuration de l'association d'attributs du fournisseur d'identités de workloads, n'associez pas de revendications trop larges. Si vous mappez "google.subject" = "assertion.aud", vous permettez à n'importe quel workload du cluster EKS d'usurper l'identité du compte de service GCP. Limitez toujours l'accès au sub (sujet) spécifique, qui comprend le namespace et le nom du compte de service (system:serviceaccount:namespace:sa-name).

2. Ignorer l'expiration des jetons

Les jetons de compte de service projetés dans Kubernetes expirent. Votre application doit être capable de recharger dynamiquement les identifiants. La plupart des SDK modernes gèrent cela automatiquement, mais les logiques d'authentification personnalisées mettent souvent en cache les jetons indéfiniment, ce qui entraîne des pannes difficiles à déboguer lorsque le jeton expire après une heure.

3. Négliger les journaux d'audit

La décentralisation peut masquer la visibilité. Vous devez regrouper les journaux d'audit d'AWS CloudTrail, de GCP Cloud Logging et de votre serveur d'API Kubernetes au sein d'un SIEM centralisé. Si une identité de workload est compromise, vous devez être en mesure de retracer ses actions à travers les frontières des différents clouds. Veillez à corréler la revendication sub du jeton OIDC avec les appels d'API correspondants dans l'environnement cible.

Le résultat : La sécurité comme accélérateur

Le passage à une architecture IAM fédérée et décentralisée modifie fondamentalement la posture de sécurité d'une équipe d'ingénierie.

En éliminant les identifiants statiques, vous éradiquez le principal vecteur d'attaques sur la chaîne d'approvisionnement. Lorsqu'un développeur a besoin qu'un nouveau service accède à une ressource sur un autre cloud, il ne demande pas de clé à l'équipe de sécurité. Il écrit un module Terraform pour établir la relation de confiance et définir la politique.

La sécurité devient du code. La confiance devient éphémère. L'infrastructure devient résiliente. C'est la seule voie possible pour les équipes d'ingénierie sérieuses opérant à grande échelle.