Tout savoir (ou presque) sur la fédération d'identité sur GCP !

La gestion des identités et des accès constitue un enjeu majeur lors du déploiement d'une infrastructure cloud d'entreprise. Traditionnellement, les organisations s'appuient sur Google Cloud Identity pour gérer leurs utilisateurs et sur des comptes de service avec clés JSON pour authentifier leurs applications. Bien que fonctionnelles, ces approches présentent des limitations importantes : Google Cloud Platform répond à ces problématiques avec Workforce Identity Federation et Workload Identity Federation, deux services complémentaires qui révolutionnent la gestion des identités dans le cloud.

Cet article détaille l'implémentation pratique de ces deux fédérations, depuis la configuration d'un Identity Provider jusqu'à l'attribution des rôles IAM via des principalSets, en passant par le mapping d'attributs et la mise en place du SSO. Ces technologies permettent aux organisations de conserver leur infrastructure d'identité existante tout en bénéficiant pleinement des services Google Cloud, dans une approche sécurisée et standardisée.

Le cas classique

Quand une landing-zone GCP est démarrée dans une organisation, il est courant de raccorder dans un premier temps la solution d'identity-as-a-service (IDaaS) Google Cloud Identity. Cette solution, en tant que sous-produit de la suite de gestion des services Google Workspace, permet d'administrer les utilisateurs des services de terminaux mobiles, de mail ou d'applications Google. L'avantage premier est d'avoir une console unifiée et simple pour gérer ses utilisateurs dans un annuaire, mettre en place du SSO et gérer sa politique de sécurisation des identités.

Pour authentifier les "utilisateurs" non-humains, on passe par la création et l'utilisation de comptes de service - ou service accounts - qui vont permettre une authentification limitée aux droits positionnés sur le gestionnaire d'accès de GCP (IAM). L'intérêt est de gérer les accès entre nos applications internes de notre landing-zone vers les APIs Google ou vers l'extérieur de GCP (application sur un autre cloud provider, un service SaaS, une application on-premises, etc...).

Ces méthodes permettant de sécuriser les accès des humains (utilisateurs) et des non-humains (workloads) ont aussi leurs limites et posent certains challenges :

Cloud Identity est un produit purement Google : une entreprise dispose généralement déjà de sa solution d'annuaire et de fournisseur d'identité (un Active Directory ou autre solution LDAP libre ou propriétaire). On peut donc mettre en place une synchronisation avec Cloud Identity pour gérer le provisioning des identités - via GCDS par exemple - en complément d'une gestion interne déjà en place, avec ses propres process. Par ailleurs, il faudra fédérer Cloud Identity avec GCP pour gérer les droits IAM : cette double configuration implique potentiellement une lourdeur en termes d'exploitation.
Les service accounts nécessitent une authentification via des credentials sous forme de clé JSON, contenant une clé privée liée au compte qui est une information sensible. Bien que cette solution soit pratique, il existe une problématique sécurité de gestion de ce secret de connexion : où le stocker, comment le révoquer, comment en effectuer la rotation périodique ?

WIF... & WIF

Pour répondre à ces problématiques, GCP propose la fédération d'identités au sens large au travers de Workforce Identity Federation (pour les humains) et Workload Identity Federation (pour les machines). Ces deux services bien intégrés à GCP ont l'avantage de reposer sur les standards SAML et OIDC qui assurent une interopérabilité entre les applications, les fournisseurs d'identité et les clients.

Les standards SAML 2.0 et OIDC

SAML (Security Assertion Markup Language) est un standard éprouvé qui existe depuis 2005, fonctionnant sur une architecture basée sur la confiance mutuelle : il repose sur le principe d'échange d'assertions d'authentification entre domaines.

*Etapes de l'authentification au travers de SAML 2.0*

Le flux typique SAML est le suivant :

L'utilisateur accède à l'application (ou le Service Provider - SP)
Le SP génère une requête SAML
Redirection vers l'IdP (Identity Provider) pour authentification
L'IdP parse la requête et authentifie l'utilisateur
... puis génère la réponse SAML
... qui est retransmise au SP
Le SP valide l'assertion et autorise l'accès
L'utilisateur est connecté

Très sécurisé, mature et constituant un standard natif implémenté dans la plupart des solutions d'entreprise, il est cependant plus complexe et lourd à configurer que son homologue OpenID Connect (OIDC). Son usage est couramment réservé à l'authentification d'utilisateurs humains et moins adapté à l'authentification d'applications notamment mobiles ou SPA.

OpenID Connect est quant à lui plus récent 2014 et est une extension d'OAuth 2.0 pour l'authentification. Il repose sur le principe d'échange d'un code d'autorisation fourni par le client, ou Relying Party - RP, avec un token JWT (JSON Web Token) fourni par l'OpenID Connect Provider - OP .

Dans le cas d'OIDC, on a le flux suivant :

Application redirige vers l'OP
Utilisateur s'authentifie
Retour avec un code d'autorisation
Échange du code contre un ID Token (JWT)

L'utilisation de chaque standard dépend du contexte dans lequel la gestion d'identités est mise en place :

Contexte	Recommandation
Applications d'entreprise traditionnelles	SAML
Applications web modernes / SPA	OIDC
Applications mobiles	OIDC
Intégration avec Active Directory	SAML (ou OIDC via ADFS)
Écosystème cloud (Google, AWS...)	OIDC
APIs REST	OIDC + OAuth 2.0

Les deux peuvent coexister dans une architecture hybride selon les besoins !

Authentifier les utilisateurs d'une landing-zone via Workforce Identity Federation

Workforce Identity Federation permet de gérer les utilisateurs GCP en les authentifiant directement auprès de l'Identity Provider interne de l'entreprise, sans synchronisation et utilisant les standards SAML ou OIDC. Il est donc compatible avec n'importe quel IdP externe supportant ces protocoles sur le marché : Microsoft Entra ID, Active Directory Federation Services (AD FS), Okta, PingIdentity, Keycloak, etc... Par ailleurs, il n'engendre pas de coût supplémentaire dans l'utilisation des services GCP : pourquoi s'en priver ?

*Introducing Workforce Identity Federation for more secure Google Cloud access | Google Cloud Blog*

Une première partie de la configuration consiste à définir un client sur l'Identity Provider : dans la plupart des cas, SAML reste privilégié par rapport à OIDC pour ce cas d'usage.

Pour mettre en place une fédération d'identité simple pour un POC, nous utilisons ici l'IdP open-source Keycloak, qui peut s'installer sur une VM simple, un conteneur docker standalone ou sur un pod kubernetes.

En quelques commandes seulement, on peut déployer Keycloak sur une VM et exposer sa console web :

#!/bin/bash
# Simple Keycloak Setup Script

KEYCLOAK_VERSION="23.0.1"
KEYCLOAK_URL="https://github.com/keycloak/keycloak/releases/download/${KEYCLOAK_VERSION}/keycloak-${KEYCLOAK_VERSION}.zip"

echo "Downloading Keycloak..."
curl -L "$KEYCLOAK_URL" -o "keycloak-${KEYCLOAK_VERSION}.zip"

echo "Extracting Keycloak..."
unzip "keycloak-${KEYCLOAK_VERSION}.zip"

echo "Starting Keycloak..."
cd "keycloak-${KEYCLOAK_VERSION}"
chmod +x bin/kc.sh
./bin/kc.sh start-dev

Ne pas oublier d'ouvrir l'accès au port d'administration (8080 par défaut), et nous pouvons nous connecter et créer nos groupes d'utilisateurs !

Ensuite, nous définissons un client qui représentera l'instance Workforce Identity Federation de notre landing-zone GCP. Dans cette configuration, nous spécifions le nom de notre pool (keycloak-test), le nom de notre provider (saml) ainsi que l'url de callback qui permettra de rediriger les utilisateurs vers la page de connexion keycloak :

*Configuration du client Workforce Identity Federation sur Keycloak*

Côté GCP, la configuration consiste à définir un Workforce Identity Pool et un Provider pour associer notre IDP Keycloak (à noter le mapping des attributs pouvant être configurés au niveau des Client Scopes et qui permettra de définir des attributs de nos utilisateurs à récupérer dans GCP) :

# Create Workforce Identity Pool
resource "google_iam_workforce_pool" "main" {
  workforce_pool_id = "keycloak-test"
  parent            = "organizations/${var.organization_id}"
  display_name      = "Keycloak Workforce Pool"
  description       = "Workforce pool for Keycloak OIDC authentication"
  location          = "global"
}

# Create Workforce Identity Pool Provider for Keycloak
resource "google_iam_workforce_pool_provider" "keycloak" {
  workforce_pool_id          = google_iam_workforce_pool.main.workforce_pool_id
  workforce_pool_provider_id = "saml"
  parent                     = google_iam_workforce_pool.main.name
  display_name               = "Keycloak OIDC Provider"
  description                = "Keycloak OIDC identity provider"
  location                   = "global"

  # OIDC configuration for Keycloak
  oidc {
    issuer_uri        = var.keycloak_issuer_uri
    client_id         = var.keycloak_client_id
    client_secret {
      value = var.keycloak_client_secret
    }
    web_sso_config {
      response_type             = "code"
      assertion_claims_behavior = "MERGE_USER_INFO_OVER_ID_TOKEN_CLAIMS"
    }
  }

  # Attribute mapping from Keycloak to Google Cloud
  attribute_mapping = {
    "google.subject"       = "assertion.sub"
    "google.display_name"  = "assertion.name"
    "google.groups"        = "assertion.groups"
    "attribute.email"      = "assertion.email"
    "attribute.username"   = "assertion.preferred_username"
  }

  # Attribute condition (optional - for additional access control)
  attribute_condition = "assertion.email_verified == true"
}

Une fois tout ce paramétrage en place, nous pouvons donner des droits dans l'IAM de GCP via l'affectation de rôles, en spécifiant le principalSet correspondant à un utilisateur ou un groupe Keycloak. Par exemple, pour affecter un rôle "Organization Administrator" sur un groupe d'admins défini dans keycloak, on utilisera le principalSet suivant dans l'IAM GCP :

principalSet://iam.googleapis.com/locations/global/workforcePools/keycloak-test/group/admins => rôle Organization Administrator

Il est également possible d'utiliser d'autres principalSets en suivant le format particulier (extrait de la doc GCP) :

Identités	Format d'identifiant
Identité unique d'un pool d'identités de personnel	`principal://iam.googleapis.com/locations/global/workforcePools/POOL_ID/subject/SUBJECT_ATTRIBUTE_VALUE`
Toutes les identités de personnel d'un groupe	`principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/group/GROUP_ID`
Toutes les identités de personnel porteuses d'une valeur d'attribut spécifique	`principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/attribute.ATTRIBUTE_NAME/ATTRIBUTE_VALUE`
Toutes les identités d'un pool d'identités de personnel	`principalSet://iam.googleapis.com/locations/global/workforcePools/POOL_ID/*`

Enfin, pour s'authentifier en SSO, nos utilisateurs pourront se connecter au travers de l'URL dédiée à notre provider externe, par exemple https://auth.cloud.google/signin/locations/global/workforcePools/keycloak-test/providers/saml.

Workforce Identity Federation redirigera la requête vers la page de login de notre IDP qui, une fois authentifié, dirigera l'utilisateur vers la console GCP

Sécuriser les workloads via Workload Identity Federation

Workload Identity Federation permet d'authentifier des applications tierces pour utiliser les services GCP sur le même principe que Workforce Identity Federation.

Au lieu d'utiliser des service accounts avec des clés générées à renseigner dans notre application, on construit une relation d'approbation entre l'application tierce et notre projet GCP, toujours avec les standards SAML ou OIDC. L'avantage est de ne plus avoir à gérer de clés : on se base sur des tokens avec une courte durée de vie pour s'authentifier, ce qui améliore la sécurité de la connexion aux APIs.

*Enable keyless access to GCP with workload Identity Federation | Google Cloud Blog*

Et en guise d'exemple, je vous conseille l'excellent article de Thomas Gruson sur la configuration de Workload Identity Federation pour authentifier vos workloads sur un Gitlab privé !

En conclusion

Workforce Identity Federation et Workload Identity Federation constituent une réponse moderne et robuste aux limitations des approches traditionnelles basées sur Google Cloud Identity et les comptes de service avec clés JSON.

L'implémentation de ces deux services de fédération d'identités offre des avantages considérables : elle permet aux entreprises de conserver leur infrastructure d'identité existante tout en bénéficiant d'une intégration native avec GCP, élimine les problématiques de gestion des secrets grâce à l'utilisation de tokens à durée de vie limitée, et s'appuie sur des standards éprouvés comme SAML 2.0 et OIDC pour garantir l'interopérabilité. La flexibilité des principalSets et du mapping d'attributs offre par ailleurs une granularité fine dans la gestion des droits IAM, adaptée aux besoins spécifiques de chaque organisation.

Au-delà des aspects techniques, cette approche fédérée représente un changement de paradigme vers une architecture Zero Trust, où l'authentification et l'autorisation sont découplées de l'infrastructure sous-jacente. Elle simplifie également les processus opérationnels en centralisant la gestion des identités au niveau de l'Identity Provider existant de l'entreprise.

Alors que les organisations accélèrent leur transformation numérique et adoptent des architectures multi-cloud de plus en plus complexes, une question stratégique se pose : comment cette approche de fédération d'identités peut-elle s'étendre pour créer un véritable écosystème d'identités unifié, capable de gérer de manière transparente et sécurisée les accès entre différents fournisseurs de cloud et environnements hybrides ?