L’authentification de serveurs sur site (on-premise) ou de postes de travail locaux vers les clouds (et notamment Google Cloud) repose historiquement sur l’export de clés de comptes de service (au format JSON pour Google). Pourtant, stocker des secrets statiques sur des disques durs locaux présente des risques majeurs de sécurité (fuites accidentelles, absence de rotation, traçabilité complexe).

Le “Pourquoi maintenant ?” : Google recommande aujourd’hui activement d’abandonner les clés de comptes de service (Service Account Keys) au profit de solutions d’identité fédérée comme Workload Identity Federation (WIF). Cette transition est poussée par les meilleures pratiques de sécurité de Google et facilitée par les politiques d’organisation de GCP (notamment la contrainte iam.disableServiceAccountKeyCreation) qui permettent désormais de bloquer totalement la création de nouvelles clés de comptes de service statiques.

Cet article présente une architecture permettant de supprimer totalement ces clés JSON en les remplaçant par une identité cryptographique éphémère, ancrée dans la puce physique de vos machines (TPM 2.0 ou Secure Enclave) et validée par GCP Workload Identity Federation (WIF) de manière entièrement serverless.

En résumé

Dans cet article, vous apprendrez à :

• Supprimer définitivement les clés JSON de Service Account sur vos serveurs et postes locaux.

• Utiliser la puce de sécurité physique (TPM 2.0 ou Secure Enclave) de vos machines comme racine de confiance.

• Configurer GCP Workload Identity Federation (WIF) pour valider des jetons de sécurité éphémères.

• Provisionner cette architecture à l’aide de Terraform.

• Déployer cette configuration en mode Daemonless (via les Executable Credentials de Google) ou via un émulateur local.

• Préparer une évolution future vers le standard d’identité SPIFFE/SPIRE.

La “Big Picture” (Vision Globale)¶

Comme introduit, l’idée principale est d’utiliser la clé cryptographique protégée par le matériel (TPM ou Secure Enclave) pour signer un jeton éphémère (JWT) échangeable contre un jeton GCP à durée de vie limitée.

Voici le schéma simplifié du flux d’authentification :

sequenceDiagram
    participant Machine as Machine Locale<br/>(TPM / Enclave)
    participant STS as GCP Security<br/>Token Service
    participant GCS as Bucket GCS<br/>(JWKS Public)
    participant Target as Bucket GCS<br/>(Sauvegardes)

    Machine->>Machine: Génère & Signe JWT (Clé Privée)
    Machine->>STS: Envoie le JWT signé
    STS->>GCS: Télécharge la Clé Publique (JWKS)
    GCS-->>STS: Retourne jwks.json
    STS->>STS: Vérifie la signature
    STS-->>Machine: Retourne Jeton GCP éphémère
    Machine->>Target: Écriture sécurisée (Jeton GCP)
    Target-->>Machine: Succès

En résumé, le flux fonctionne ainsi :

1. La machine cliente génère localement un jeton temporaire (JWT).

2. Elle signe ce JWT à l’aide de sa clé privée, qui reste confinée dans sa puce physique.

3. Elle transmet le JWT signé à Google Cloud (STS).

4. Google vérifie la signature en consultant la clé publique de la machine (hébergée statiquement sur un bucket public).

5. Google valide l’identité et retourne un jeton d’accès GCP éphémère.

6. La machine utilise ce jeton pour exécuter ses tâches.

Cas d’usage typique : Permettre aux administrateurs de planifier des scripts de sauvegarde automatiques vers GCS, sans jamais stocker de mots de passe ou de clés d’API sur les serveurs.

Tableau Comparatif des Méthodes d’Accès¶

Comme vous pouvez le voir dans le tableau suivant, la méthode avec la puce physique est celle qui offre le meilleur niveau de sécurité et de flexibilité :

Quand utiliser cette architecture ?¶

✅ Idéal pour :¶

• Sauvegardes automatisées on-premise : Authentifier des serveurs locaux vers un bucket Google Cloud Storage de manière sécurisée.
• Edge Computing & IoT : Identifier des machines physiques ou des passerelles industrielles isolées sur le terrain.
• Postes d’administration (Mac/Linux/Windows) : Permettre aux administrateurs de mettre en place des tâches automatisées (scripts de maintenance, synchronisation planifiée…) qui s’exécutent sans leurs identifiants personnels. Pour les opérations interactives, la bonne pratique reste de s’authentifier via gcloud auth login — cette architecture vise spécifiquement les cas où aucun humain n’est présent pour ressaisir un mot de passe.
• Environnements partiellement isolés (Air-Gap) : Les serveurs n’ont besoin d’accès sortant que vers les APIs de Google.

❌ Non adapté pour :¶

• Workloads Kubernetes (GKE / on-prem) : Utilisez plutôt l’identité native de Kubernetes (GKE Workload Identity) ou le framework SPIFFE/SPIRE pour gérer des identités à grande échelle.
• Machines virtuelles sur Google Compute Engine : Utilisez les comptes de service natifs attachés aux instances de manière transparente.
• Services cloud managés (Cloud Run, Cloud Functions) : Exploitez l’impersonation de compte de service native des runtimes GCP.

1. L’Architecture et ses Composants¶

Pour valider l’assertion JWT signée par la puce de la machine cliente, Google Cloud a besoin d’accéder à la clé publique de cette machine. Plutôt que de déployer et de maintenir un serveur d’authentification actif et coûteux (comme Okta ou un serveur Keycloak), nous utilisons un modèle entièrement serverless à coût minimal :

Elle repose notment sur :

1. Un bucket Cloud Storage Public qui contiendra deux fichiers OIDC statiques :
2. .well-known/openid-configuration : Décrit notre fournisseur d’identité minimaliste.

3. jwks.json : Contient les clés publiques (JSON Web Keys) des machines autorisées.

4. Un Workload Identity Pool & Provider (OIDC) configurés dans GCP pour faire confiance à notre bucket GCS en tant qu’émetteur d’identité (Issuer URL).

2. Configuration Terraform (Provisionnement)¶

Maintenant que le principe est clair, voici comment le mettre en place avec Terraform.

Voici le code Terraform qui configure l’émetteur OIDC statique sur GCS, le Pool WIF, compile les clés publiques des machines, et restreint l’impersonation du Service Account aux machines enregistrées.

L’arborescence du répertoire Terraform est la suivante :

terraform/
├── main.tf          # Logique principale : bucket OIDC public, bucket de backup,
│                    #   Service Account, Pool WIF, Provider OIDC,
│                    #   compilation du JWKS et liaison IAM par machine
├── variables.tf     # Variables d'entrée : project_id, project_number,
│                    #   region et jwks_dir (chemin vers les clés publiques)
├── outputs.tf       # Sorties exportées : noms des buckets, email du SA,
│                    #   ID du Pool WIF, URL de l'émetteur et machines enregistrées
└── jwks/            # Un fichier .json par machine (clé publique JWK)
    ├── macbook-pro.json
    └── srv-backup-01.json

Le point clé de cette approche : Terraform lit automatiquement tous les fichiers du répertoire jwks/, compile un jwks.json agrégé, génère le document .well-known/openid-configuration, uploade les deux sur GCS, et crée un binding IAM par machine :

# Extrait de terraform/main.tf — Compilation du JWKS et IAM multi-machines
locals {
  jwk_files = fileset(var.jwks_dir, "*.json")

  jwk_keys = [
    for f in local.jwk_files : jsondecode(file("${var.jwks_dir}/${f}"))
  ]

  jwks_json = jsonencode({ keys = local.jwk_keys })

  machine_fingerprints = {
    for f in local.jwk_files :
      trimsuffix(f, ".json") => jsondecode(file("${var.jwks_dir}/${f}")).kid
  }
}

# Upload du JWKS compilé sur GCS
resource "google_storage_bucket_object" "jwks_json" {
  name         = "jwks.json"
  bucket       = google_storage_bucket.jwks_bucket.name
  content      = local.jwks_json
  content_type = "application/json"
}

# Un binding IAM par machine, lié à l'empreinte de sa clé
resource "google_service_account_iam_member" "wif_sa_impersonation" {
  for_each = local.machine_fingerprints

  service_account_id = google_service_account.backup_sa.name
  role               = "roles/iam.workloadIdentityUser"
  member             = "principal://iam.googleapis.com/projects/${var.project_number}/locations/global/workloadIdentityPools/${google_iam_workload_identity_pool.hardware_pool.workload_identity_pool_id}/subject/machine-${each.value}"
}

Pour ajouter une nouvelle machine, il suffit de déposer son fichier JWK dans terraform/jwks/ et de relancer terraform apply. Pour révoquer une machine, supprimez son fichier et relancez — Terraform retirera sa clé du JWKS et son binding IAM.

3. Logique de Signature Matérielle (Clients)¶

Le Pipeline de Hachage et de Signature du JWT¶

Pour s’authentifier auprès de Google WIF, le client local construira un jeton de sécurité temporaire (JWT) contenant les claims obligatoires : iss (Issuer), aud (Audience), sub (Sujet unique basé sur l’empreinte de la clé publique), iat (date d’émission) et exp (date d’expiration de 5 minutes).

Le Header et le Payload du JWT sont encodés en Base64URL et concaténés avec un point. Cette chaîne est hachée via SHA-256, et le digest de 32 octets obtenu est envoyé au processeur physique pour signature avec la clé privée interne (ECDSA P-256 / ES256).

Conversion de Format : DER (TPM) vers Raw R || S (JWT)¶

Les puces matérielles (comme les TPM) retournent généralement la signature au format normalisé ASN.1 DER. Ce format encapsule les deux entiers $R$ et $S$ de la signature ECDSA dans une structure binaire. Pour être conforme à la norme JWT (ES256), notre code client extrait ces deux entiers et les concatène sous la forme d’un bloc plat de 64 octets ($R$ complété à 32 octets || $S$ complété à 32 octets).

A. macOS : Swift & CryptoKit (Secure Enclave)¶

Sur macOS, nous utilisons CryptoKit pour générer une clé privée au sein de la Secure Enclave. Le code source complet est disponible dans client-swift/main.swift.

La clé privée n’est jamais exportable via les API logicielles publiques (elle est protégée par le processeur de sécurité physique). Pour réutiliser la même clé, le programme sauvegarde une représentation sécurisée emballée de la clé (key.wrapped). Ce fichier est chiffré par la Secure Enclave de la machine courante et s’avère inutilisable si copié sur un autre ordinateur.

B. Linux : Go & go-tpm (TPM 2.0)¶

Pour les serveurs Linux équipés d’un TPM 2.0, l’implémentation repose sur le protocole TPM standard et s’appuie sur la bibliothèque officielle go-tpm v0.3.3. Le code complet est rédigé dans client-tpm/main.go.

Afin d’éviter toute collision de clés avec d’autres logiciels locaux, le handle de stockage persistant du TPM n’est pas codé en dur mais configurable à l’aide de l’option -tpm-handle.

C. Windows : PowerShell & CNG (TPM 2.0)¶

Sur Windows, nous pouvons interagir avec le TPM 2.0 en utilisant le Microsoft Platform Crypto Provider via PowerShell et les API CNG (Cryptography Next Generation) de .NET.

La clé privée est générée et stockée directement dans le TPM. La signature retournée par l’API Windows CNG est déjà au format brut $R \parallel S$ (64 octets), ce qui évite d’avoir à effectuer une conversion DER vers RAW.

Voici le script PowerShell pour générer une clé adossée au TPM et exporter sa clé publique au format JWK :

# Créer une clé ECDsa P-256 adossée au TPM
$keyName = "gcp-wif-backup-key"
$keyParams = New-Object System.Security.Cryptography.CngKeyCreationParameters
$keyParams.Provider = "Microsoft Platform Crypto Provider"
$keyParams.KeyCreationOptions = [System.Security.Cryptography.CngKeyCreationOptions]::OverwriteExistingKey

$cngKey = [System.Security.Cryptography.CngKey]::Create(
    [System.Security.Cryptography.CngAlgorithm]::ECDsaP256,
    $keyName,
    $keyParams
)

# Exporter la clé publique (format CNG ECC Public Blob)
$pubBlob = $cngKey.Export([System.Security.Cryptography.CngKeyBlobFormat]::EccPublicBlob)

# Extraire les coordonnées X et Y (32 octets chacune, après l'en-tête de 8 octets)
$xBytes = $pubBlob[8..39]
$yBytes = $pubBlob[40..71]

# Fonction d'encodage Base64URL
function Safe-Base64Url([byte[]]$bytes) {
    [Convert]::ToBase64String($bytes).Replace('+', '-').Replace('/', '_').TrimEnd('=')
}

# Générer l'ID de clé (kid) basé sur l'empreinte SHA-256 des coordonnées de la clé publique
$sha256 = [System.Security.Cryptography.SHA256]::Create()
$fingerprint = $sha256.ComputeHash($xBytes + $yBytes)
$kid = (Safe-Base64Url $fingerprint).Substring(0, 16)

# Construire le JWK
$jwk = @{
    kty = "EC"
    crv = "P-256"
    x   = Safe-Base64Url $xBytes
    y   = Safe-Base64Url $yBytes
    kid = $kid
} | ConvertTo-Json -Compress

Write-Output "JWK Public :"
Write-Output $jwk

Pour signer le JWT avec la clé TPM en PowerShell :

# Charger la clé depuis le fournisseur TPM
$cngKey = [System.Security.Cryptography.CngKey]::Open($keyName)
$ecdsa = New-Object System.Security.Cryptography.ECDsaCng($cngKey)

# Hacher l'en-tête et le payload du JWT
$jwtBytes = [System.Text.Encoding]::UTF8.GetBytes("$header.$payload")
$sha256 = [System.Security.Cryptography.SHA256]::Create()
$hashBytes = $sha256.ComputeHash($jwtBytes)

# Signer directement le hash (retourne la signature brute R || S)
$sigBytes = $ecdsa.SignHash($hashBytes)
$signature = Safe-Base64Url $sigBytes

$jwt = "$header.$payload.$signature"

4. Guide de Déploiement et de Configuration¶

Étape 1 : Initialisation de la Configuration Client¶

Créez ou mettez à jour votre fichier client-swift/config.json avec vos identifiants réels GCP.

Étape 2 : Compilation du Client Swift¶

Compilez le client Swift sur votre macOS à l’aide du compilateur natif :

swiftc -O client-swift/main.swift -o client-swift/backup-auth

Étape 3 : Génération de la Clé Matérielle et Enregistrement¶

Exécutez le binaire en lui indiquant le répertoire d’enregistrement terraform/jwks pour générer la clé privée cryptographique dans la Secure Enclave, afficher le JWK public associé, et l’enregistrer directement au bon format :

./client-swift/backup-auth generate \
  --config client-swift/config.json \
  --key-out client-swift/key.wrapped \
  --jwks-dir ./terraform/jwks

Cette commande produit : 1. Le jeton de clé physique emballé client-swift/key.wrapped (utilisé pour la signature des JWT). 2. Le fichier de clé publique JWK individuel enregistré directement dans terraform/jwks/<nom-de-votre-machine>.json. 3. Le JWK public correspondant affiché sur la sortie standard.

(Pour les serveurs Linux avec TPM 2.0, l’appel équivalent avec le client Go supporte également l’option --jwks-dir).

Répétez cette opération pour chaque machine à enregistrer. Chaque machine génère son propre fichier dans terraform/jwks/.

Étape 4 : Provisionnement Terraform¶

Initialisez et appliquez la configuration Terraform. Celle-ci va automatiquement compiler les clés de toutes les machines en un jwks.json agrégé, l’uploader sur GCS avec le document de découverte OIDC, configurer le pool WIF, et créer un binding IAM par machine :

cd terraform
terraform init
terraform apply \
  -var="project_id=mon-projet-gcp" \
  -var="project_number=123456789012"

5. Choix d’Intégration Locale : Agentless vs Émulateur¶

Pour connecter l’authentification locale de vos machines aux outils GCP, deux options s’offrent à vous :

Option A : L’approche recommandée “Agentless” (Executable Credentials)¶

C’est la solution recommandée par Google, car elle correspond au modèle standard de WIF et évite d’ouvrir des ports réseau en arrière-plan.

Le SDK de Google exécute directement notre binaire local en tant que sous-processus éphémère pour récupérer le JWT signé et s’occupe de l’échanger auprès de Google STS. Vous configurez un fichier de crédentiels local (ex: credentials-config.json) :

{
  "type": "external_account",
  "audience": "//iam.googleapis.com/projects/YOUR_PROJECT_NUMBER/locations/global/workloadIdentityPools/hardware-auth-pool/providers/hardware-oidc-provider",
  "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
  "token_url": "https://sts.googleapis.com/v1/token",
  "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/backup-agent-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com:generateAccessToken",
  "credential_source": {
    "executable": {
      "command": "/Users/username/gcp-workload-identification/client-swift/backup-auth credential --config /Users/username/gcp-workload-identification/client-swift/config.json --key-in /Users/username/gcp-workload-identification/client-swift/key.wrapped",
      "timeout_millis": 5000,
      "output_filesize_limit_bytes": 1048576
    }
  }
}

Pour Windows, vous pouvez configurer le fichier de crédentiels pour appeler PowerShell avec le script de signature :

{
  "type": "external_account",
  "audience": "//iam.googleapis.com/projects/YOUR_PROJECT_NUMBER/locations/global/workloadIdentityPools/hardware-auth-pool/providers/hardware-oidc-provider",
  "subject_token_type": "urn:ietf:params:oauth:token-type:jwt",
  "token_url": "https://sts.googleapis.com/v1/token",
  "service_account_impersonation_url": "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/backup-agent-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com:generateAccessToken",
  "credential_source": {
    "executable": {
      "command": "powershell.exe -NoProfile -ExecutionPolicy Bypass -File C:\\path\\to\\backup-auth.ps1 -GetToken",
      "timeout_millis": 5000,
      "output_filesize_limit_bytes": 1048576
    }
  }
}

Pour utiliser ce fichier avec vos applications (via les bibliothèques clientes Google), définissez la variable d’environnement GOOGLE_APPLICATION_CREDENTIALS ainsi que la variable de sécurité GOOGLE_EXTERNAL_ACCOUNT_ALLOW_EXECUTABLES qui autorise l’exécution du binaire :

export GOOGLE_APPLICATION_CREDENTIALS="/Users/username/gcp-workload-identification/credentials-config.json"
export GOOGLE_EXTERNAL_ACCOUNT_ALLOW_EXECUTABLES=1

Pour la CLI gcloud (qui n’utilise pas nativement les variables d’environnement ADC pour ses commandes courantes), authentifiez explicitement la CLI à l’aide de ce fichier :

gcloud auth login --cred-file=/Users/username/gcp-workload-identification/credentials-config.json

Puis, exécutez vos commandes en activant l’autorisation des executables :

GOOGLE_EXTERNAL_ACCOUNT_ALLOW_EXECUTABLES=1 gcloud storage cp /data/backup.tar.gz gs://secure-backup-nom-unique/

Option B : L’émulateur de Métadonnées (Daemon local)¶

Alternative de repli : Si vous utilisez des conteneurs Docker ou des scripts historiques avec des commandes HTTP directes, vous pouvez lancer notre démon Go (metadata-emulator/main.go) en arrière-plan sur la boucle locale.

En configurant export GCLOUD_METADATA_HOST=127.0.0.1:8080, les requêtes réseau sont redirigées vers l’émulateur qui mime le comportement d’une VM Google Compute Engine. Note : GCLOUD_METADATA_HOST est une variable d’environnement de test interne du SDK et ne doit pas être considérée comme un point d’intégration de production pérenne.

6. Passage à l’Échelle (GitOps & Limites)¶

Enrôlement Automatisé (GitOps)¶

Sur une flotte importante de machines, le pipeline CI/CD qui créera les serveurs (onprem) peut être configuré pour consolider automatiquement les clés publiques : 1. Chaque nouvelle machine génère sa clé au boot et le job de postprovising soumet sa clé publique JWK (ici sous forme de fichier jwks/machine-01.json) via une Pull Request vers un dépôt Git. 2. Le pipeline CI/CD (ex: Terraform) valide le format, fusionne les clés individuelles dans un fichier jwks.json global comme ci dessus. 3. Le pipeline déploie automatiquement le fichier mis à jour vers le bucket Cloud Storage de confiance.

Limites de Scalabilité du JWKS statique¶

Google ne publie pas de limites strictes quant à la taille du fichier JWKS importé par Google STS. Néanmoins, un fichier contenant plus de 1000 clés de signature (environ 400 Ko de données textuelles) dégrade les performances réseau d’authentification lors de la résolution de jetons. Pour de très grands parcs, il convient de segmenter les machines sur plusieurs fichiers JWKS distincts (un par département ou environnement) ou de faire pointer le Provider OIDC WIF vers une API dynamique (ex: Cloud Function + base Firestore) qui recherche la clé publique individuellement à la demande grâce au claim kid (Key ID).

7. Perspectives et Souveraineté (SPIFFE / S3NS)¶

L’architecture WIF matérielle serverless constitue la première étape logique vers l’adoption de normes d’identité cloud-native standardisées, comme le projet SPIFFE/SPIRE de la CNCF.

Dans un déploiement SPIFFE, les charges de travail locales n’ont plus besoin de fichiers de clés emballées locaux ; elles récupèrent dynamiquement des jetons d’identité cryptographiques à courte durée de vie (les JWT-SVID) en interrogeant localement l’API SPIFFE via un socket UNIX. Le serveur central SPIRE expose son JWKS public qui est alors fédéré avec le service WIF de Google Cloud.

Souveraineté Opérationnelle et “Cloud de Confiance”¶

Cette architecture s’intègre naturellement avec les fournisseurs de Cloud de Confiance européens tels que S3NS (la joint-venture de Thales et Google Cloud qualifiée SecNumCloud par l’ANSSI en France).

Dans ce cas de figure, l’ancrage matériel (TPM 2.0) permet de conserver la clé privée d’authentification sur le sol national, au sein de vos datacenters locaux, tandis que les fichiers de configuration OIDC de confiance sont hébergés de manière sécurisée et isolée dans la zone souveraine de S3NS. Vous assurez ainsi une séparation des pouvoirs totale et une protection robuste contre les lois extraterritoriales.

Conclusion¶

Pendant longtemps, sécuriser une machine on-premise vers les fournisseurs de Cloud signifiait stocker une clé de Service Account statique sur le disque local, au prix d’un risque persistant de fuite. Avec Workload Identity Federation et les modules de sécurité matériels modernes (TPM 2.0 et Secure Enclave), il est désormais possible de supprimer totalement ces secrets statiques. En s’appuyant sur l’alternative native Executable Credentials, cette approche rapproche les infrastructures hybrides des principes du Zero Trust, tout en ouvrant la voie à des architectures d’identités universelles comme SPIFFE/SPIRE.