Résumé
Okta Privileged Access (OPA) Workload Identity for Automation s’intègre à Google Cloud Platform (GCP) en échangeant des tokens OIDC JSON Web (JWT) signés par la plateforme contre des certificats SSH éphémères et de courte durée. Une machine virtuelle d’exécution automatisée interroge son serveur de métadonnées GCP local pour obtenir un JWT signé par Google, le soumet à OPA via l’interface CLI sft pour s’authentifier, puis reçoit un certificat SSH à durée limitée afin d’accéder aux serveurs cibles, supprimant ainsi le recours aux clés SSH statiques, aux tokens API et aux fichiers JSON de compte de service.
Chaque ingénieur ou ingénieure en automatisation a déjà connu ce moment délicat : il faut que votre script se connecte à un serveur, alors vous générez un identifiant, vous le collez dans un fichier de configuration, puis vous passez à autre chose. Quelques semaines plus tard, cette information d’identification se retrouve dans trois fichiers de configuration, deux pipelines CI/CD et un message Slack qu’une personne a envoyé « juste pour tester quelque chose rapidement ». Personne ne sait lesquelles sont encore actives. Personne ne souhaite être responsable d’une interruption en production en effectuant leur rotation.
Dans cet article de blog, nous présentons une solution complète et opérationnelle : utiliser Okta Privileged Access (OPA) Workload Identity for Automation avec Google Cloud Platform (GCP) pour permettre à un script d’automatisation d’établir une connexion SSH vers un serveur cible sans stocker le moindre identifiant sur le disque.
Comment OPA et les identités de workload GCP éliminent les identifiants statiques
Objectif principal : éliminer les identifiants statiques (clés API, clés SSH statiques et fichiers JSON de comptes de service) dans l’accès automatisé aux serveurs en s’appuyant sur des preuves d’identité signées par la plateforme.
Zéro identifiant stocké : aucun secret n’est présent sur le disque, dans les fichiers de configuration ou dans les variables CI/CD.
Certificats éphémères de courte durée : délivrance de certificats SSH valides pendant 15 minutes, éliminant le risque opérationnel lié à la rotation.
Validation cryptographique de bout en bout : Okta Privileged Access, jouant le rôle d’intermédiaire de confiance qui valide les JSON Web Tokens (JWT) émis par GCP.
Journalisation automatisée des audits : traçabilité complète de l’identité sur l’ensemble des échanges de tokens et des activités de session SSH dans l’Okta System Log.
Le problème : les identifiants statiques représentent une dette de sécurité, et non des fonctionnalités d’infrastructure
Lorsqu’une tâche automatisée — un playbook Ansible, un script de déploiement ou un runner CI/CD — doit accéder à une ressource à privilèges, elle a besoin d’un moyen de prouver son identité. L’approche traditionnelle lui attribue un identifiant statique : une clé API, une clé privée SSH ou un fichier JSON de compte de service. Cet identifiant est stocké quelque part, et cet emplacement devient alors une cible.
Les conséquences se manifestent de manière prévisible :
Les identifiants survivent à leur utilité : une clé de compte de service créée pour une tâche de déploiement ponctuelle reste valable pendant des années. L’ingénieur qui l’a créé quitte l’entreprise. La clé reste. Personne ne l’audite. Les autorisations s’accumulent au fil du temps, car il est plus simple d’ajouter des accès que d’analyser ceux qu’il serait pertinent de retirer. Ce sont des « identifiants zombies » qui subsistent dans votre environnement bien après la disparition du workload auquel ils étaient destinés.
La rotation devient un exercice de gestion de crise : lorsqu’un identifiant est intégré dans des dizaines de pipelines et de fichiers de configuration, son renouvellement implique de commencer par trouver toutes les références. Les équipes découvrent les références en constatant des dysfonctionnements après la rotation. Il ne s’agit pas d’une stratégie de rotation, mais d’une panne maîtrisée.
Le problème sous-jacent est d’ordre architectural : les identifiants statiques constituent un modèle d’identité conçu pour les personnes, et non pour les machines. Une personne peut modifier son mot de passe et mémoriser le nouveau. Une machine doit simplement savoir : « Suis-je bien celle ou celui que je prétends être ? », et une plateforme cloud peut répondre à cette question de manière cryptographique, sans aucun secret stocké.
La solution : des tokens à durée de vie limitée, une sécurité permanente
Okta Privileged Access Workload Identity for Automation résout le problème du « secret zéro », qui consiste à devoir disposer d’une clé initiale pour extraire d’autres identifiants sécurisés, en remplaçant les identifiants statiques par des preuves d’identité signées par la plateforme.
Le constat est simple : une machine virtuelle (VM) GCP dispose déjà d’une identité cryptographique. Lorsque vous associez un compte de service à une machine virtuelle, GCP peut émettre un JWT signé avec la clé privée de Google, indiquant en substance : « Je suis cette machine virtuelle, exécutée en tant que ce compte de service, et ce token m’a été délivré à ce moment précis. » Personne ne peut falsifier ce token sans la clé privée de Google. Il expire automatiquement et ne peut pas être réutilisé sur un autre système.
OPA joue le rôle d’intermédiaire de confiance. Vous le configurez une seule fois pour indiquer : « J’ai confiance dans les JWT signés par Google pour le compte de service X. » À partir de ce moment, tout workload exécuté sous ce compte de service peut prouver son identité auprès d’OPA en présentant son JWT émis par GCP, et OPA l’échangera contre un token d’accès à durée de vie limitée. Ce token est ensuite utilisé pour obtenir un certificat SSH éphémère, valable quelques minutes et non plusieurs années, afin de se connecter à un serveur cible.
Il ne s’agit pas d’un changement du fonctionnement de SSH. Il s’agit d’un changement dans la manière dont l’identité est établie avant le démarrage de SSH.
Architecture du système et cartographie des composants
Le workflow d’authentification repose sur un modèle de conception de courtier de confiance, dans lequel OPA valide les déclarations d’identité générées de manière cryptographique par GCP.
| Composant | Rôle de sécurité | Location |
|---|---|---|
Serveur de métadonnées GCP | Point de terminaison GCP interne qui émet des JWT signés à toute machine virtuelle sur demande | Infrastructure GCP (pas votre VM) |
Connexion de charge de travail | Objet de configuration OPA qui définit la relation de confiance avec GCP, en précisant quels JWT accepter et quelles déclarations vérifier | Tableau de bord OPA |
Rôle de workload | Entité d’autorisation OPA qui associe une identité de workload vérifiée à un nom d’utilisateur Linux sur les serveurs cibles | Tableau de bord OPA |
Politique et règle | Définit quels rôles de workload peuvent accéder à quels serveurs et par quelle méthode | Tableau de bord OPA |
sft (client OPA) | Binaire d’interface en ligne de commande (CLI) qui gère l’authentification des workloads et la délivrance de certificats SSH | Machine virtuelle Runner |
sftd (agent OPA) | Démon qui inscrit le serveur cible auprès d’OPA et configure SSH pour faire confiance à l’autorité de certification d’OPA | VM cible |
Architecture et flux d’authentification
Principes fondamentaux de la conception de la sécurité
Liaison d’audience OPA : le JWT GCP est demandé avec l’URL OPA comme audience. Même si elle est interceptée, elle ne peut pas être rejouée sur un autre système.
Vérification cryptographique : OPA récupère les clés publiques de Google et vérifie la signature JWT avant d’émettre tout token. Un JWT falsifié ou altéré échoue.
Expiration stricte du time-to-live (TTL) : le JWT GCP expire après une heure. Le token OPA reste valide pendant toute la durée de la session. Le certificat SSH est valide pendant la période définie. Rien ne persiste.
Comment configurer une connexion de workload Okta Privileged Access pour GCP
Exigences et prérequis
Compte GCP : la facturation doit être activée et il faut disposer des droits de propriétaire ou d’éditeur sur le projet.
gcloud CLI : installé et authentifié sur le poste de travail local.
Tenant OPA : Okta Privileged Access sous licence et accessible via l’URL de votre tenant (par exemple, [https://YOUR-TEAM.pam.okta.com]).
Rôle d’administrateur DevOps : nécessaire dans OPA pour créer la connexion de workload.
Rôle d’administrateur ou administratrice de la sécurité : nécessaire dans OPA pour activer la connexion, créer le rôle de workload et créer la politique.
Étape 1 : créer l’infrastructure GCP
Exécutez ces commandes sur votre poste de travail local.
1.1 Créer un projet et activer les API (GCP)
PROJECT_ID="VOTRE_ID_DE_PROJET"
ZONE="VM_LOCATION"
gcloud projects create "$PROJECT_ID" --name="VOTRE_ID_DE_PROJET"
gcloud config set project "$PROJECT_ID"
gcloud services enable compute.googleapis.com iam.googleapis.com
11.2 Créer un compte de service pour la VM runner (GCP)
Ce compte de service constitue l’identité machine du runner. Aucun fichier de clé n’est généré, la preuve d’identité réside dans l’association de la machine virtuelle à ce compte lors de sa création.
gcloud iam service-accounts create opa-runner-sa \
--display-name="OPA Runner Service Account" \
--project="$PROJECT_ID"
E-mail du compte de service généré : opa-runner-sa@<VOTRE_ID_DE_PROJET>.iam.gserviceaccount.com
1.3 Créer les instances de calcul runner et target (GCP)
# Runner VM
gcloud compute instances create runner-vm \
--zone="$ZONE" \
--machine-type=e2-medium \
--image-family=ubuntu-2204-lts \
--image-project=ubuntu-os-cloud \
--service-account=opa-runner-sa@${PROJECT_ID}.iam.gserviceaccount.com \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--tags=opa-runner
# Machine virtuelle cible
gcloud compute instances create target-vm \
--zone="$ZONE" \
--machine-type=e2-medium \
--image-family=ubuntu-2204-lts \
--image-project=ubuntu-os-cloud \
--tags=opa-target
Remarque : Les serveurs ci-dessus sont configurés avec « machine-type » : « e2-medium » et « image-family » : « ubuntu-2204-lts ». Vous pouvez choisir le type de machine et la famille d’images.
1.4 Configurer les règles de pare-feu (GCP)
# Autoriser l’accès SSH interne du runner vers la cible
gcloud compute firewall-rules create allow-runner-to-target \
--allow=tcp:22 \
--source-tags=opa-runner \
--target-tags=opa-target \
--project="$PROJECT_ID"
# Autoriser les connexions HTTPS sortantes depuis la cible pour la communication de l’agent OPA
gcloud compute firewall-rules create allow-egress-opa \
--direction=EGRESS \
--allow=tcp:443 \
--target-tags=opa-target \
--project="$PROJECT_ID"
Étape 2 : configurer la machine virtuelle runner (GCP)
La machine virtuelle d’exécution nécessite uniquement le binaire sft. Il n’est attribué à aucun utilisateur dans OPA.
# Se connecter en SSH à la machine virtuelle d'exécution
gcloud compute ssh runner-vm --zone="$ZONE"
# Installer les dépendances et le binaire client sft
# Installer la clé du dépôt et ajouter le dépôt Okta PAM
curl -fsSL https://dist.scaleft.com/GPG-KEY-OktaPAM-2023 | gpg --dearmor | sudo tee /usr/share/keyrings/oktapam-2023-archive-keyring.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/oktapam-2023-archive-keyring.gpg] https://dist.scaleft.com/repos/deb $(lsb_release -cs) okta" | sudo tee /etc/apt/sources.list.d/oktapam-stable.list
# Mettre à jour le référentiel et installer les outils client SFT
sudo apt-get update && sudo apt-get install -y scaleft-client-tools
# Confirmer la pièce justificative d’identité jointe
curl -sf -H "Metadata-Flavor: Google" "http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/email"
# Résultat attendu : opa-runner-sa@opa-workload-demo.iam.gserviceaccount.com
Quitter
Étape 3 : configurer la machine virtuelle cible
3.1 Configurer le tableau de bord OPA et générer un token d’enrôlement serveur (Okta)
- Accéder au Tableau de bord OPA → Administration des ressources → Gestion des ressources → Créer un groupe de ressources → Créer un projet ou Groupe de ressources existant → Enregistrer
- Nom : GCP_Servers_Proj
- Description: serveurs cibles GCP pour la démo de workload
- Accédez à GCP_Servers_Proj → Projet → Type de ressource - Serveurs → Paramètres → Token d'enrôlement → Vue → Créer token d'enrôlement
- Sélectionner le système d’exploitation : Linux
- Copier le token d'enrôlement généré
3.2 Installer et démarrer l’agent sftd sur la machine virtuelle cible (basée sur GCP)
# Se connecter en SSH à la machine virtuelle cible
gcloud compute ssh target-vm --zone="$ZONE"
# Installer les dépendances et le démon sftd
# Installer la clé du dépôt et ajouter le dépôt Okta PAM
curl -fsSL https://dist.scaleft.com/GPG-KEY-OktaPAM-2023 | gpg --dearmor | sudo tee /usr/share/keyrings/oktapam-2023-archive-keyring.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/oktapam-2023-archive-keyring.gpg] https://dist.scaleft.com/repos/deb $(lsb_release -cs) okta" | sudo tee /etc/apt/sources.list.d/oktapam-stable.list
# Mettre à jour le dépôt et installer les outils serveur SFT
sudo apt-get update && sudo apt-get install -y scaleft-server-tools
# Enregistrer le token de configuration d’inscription
sudo mkdir -p /var/lib/sftd
echo "VOTRE_TOKEN_ENROLEMENT" | sudo tee /var/lib/sftd/enrollment.token > /dev/null
# Restreindre les autorisations de fichiers pour la sécurité
sudo chmod 600 /var/lib/sftd/enrollment.token
# Activer et vérifier le statut du démon
sudo systemctl enable sftd && sudo systemctl start sftd
attendre 5
sudo systemctl status sftd --no-pager
Quitter
3.3 Vérifier l’inscription
Consultez le Tableau de bord OPA pour vérifier que le statut indique Enrôlé : Tableau de bord OPA → GCP_Servers_Proj → Serveurs → target-vm (Statut : enrôlé) ✓
Étape 4 : configurer la connexion du workload OPA et les rôles (Okta)
4.1 Créer et activer une connexion Workload (administrateur DevOps et administrateur sécurité)
Dans le tableau de bord OPA, accédez à DevOps Administration → Connexions Workload → Créer une connexion Workload.
Choisissez Google Cloud Provider.
Saisir les informations d’identification du client de l’application :
ID client de l’application : Saisissez l’ID client de votre application (le compte de service créé à l’étape précédente dans le projet GCP)
Cochez Scope to Email (l’e-mail est généré automatiquement)
Définir les paramètres :
Nom de la connexion : OKTA-OPA-Demo
Durée de vie du token: 3600 secondes
Déclarations requises : aud = [https://VOTRE-EQUIPE.pam.okta.com] et iss = [https://accounts.google.com]
Cliquez sur Créer une connexion Workload.
- Passez à l’administrateur DevOps : ouvrez OKTA-OPA-Demo → Actions → Activer.
4.2 Créer un rôle de workload (administrateur de sécurité)
Accéder à Administration de la sécurité → Rôles de workload → Créer un rôle de workload.
Configurer les attributs :
Nom: OKTA-OPA-WR
Connexion workload: OKTA-OPA-Demo
Cliquez sur Enregistrer le rôle de workload. OPA attribue automatiquement un nom d’utilisateur Linux (wl_okta_opa_wr).
4.3 Configurer la politique et les règles (administrateur de la sécurité)
Accéder à Administration de la sécurité → Politiques → Créer Politique → Par défaut
Nom: Accès NHI au serveur
Sélectionner des groupes de ressources : Tous les groupes de ressources
Sous Ajouter des principaux, ajoutez Rôle de workload OKTA-OPA-WR.
Sous Ajouter une règle à la politique, sélectionnez Règle serveur:
Nom de la règle : autorisez SSH pour le rôle de workload
Type de session: session SSH serveur
Comptes: activez la sélection de comptes par nom → Cible : target-vm / root
Important : n’activez PAS la MFA ni Access Requests (les tâches sans interface ne peuvent pas répondre aux invites interactives).
Cliquez sur Enregistrer la politique, puis accédez à Actions → Publier.
Étape 5 : vérifier et tester l’exécution (basée sur GCP)
5.1 Préparer le script d’automatisation de la vérification
Se connecter de nouveau en SSH à runner-vm et préparer le script d’automatisation :
gcloud compute ssh runner-vm --zone="$ZONE"
#!/bin/bash
#
# Script de démo Identité de workload OPA
# Basé sur : Okta Privileged Access - Introduction aux identités de workload
#
# ─── DÉFINIR LES VARIABLES D’ENVIRONNEMENT ───────────────────────────────────────────────
# Audience = votre adresse OPA (doit correspondre à la déclaration aud attendue par OPA)
AUDIENCE="https://opa-gcp.pam.okta.com"
# URL des métadonnées GCP pour obtenir le JWT
METADATA_URL="http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/identity?audience=${AUDIENCE}&format=full"
# Équipe OPA et adresse (sft lit ces informations à partir de l’environnement)
export SFT_TEAM="opa-gcp"
export OPA_ADDR="https://demo-opa-gcp-demo.pam.okta.com"
# Les noms doivent correspondre exactement à ceux que vous avez créés dans le tableau de bord OPA
CONNECTION_NAME="okta-opa-demo"
ROLE_NAME="okta_opa_wr"
# Nom du serveur cible (tel qu’enregistré dans OPA — le nom d’hôte)
TARGET_SERVER="target-vm"
# ─── ÉTAPE 1 : OBTENIR LE JWT D’IDENTITÉ GCP ────────────────────────────────────────────
echo "------------------------------------------------------------"
echo "ÉTAPE 1 : obtention du JWT depuis le serveur de métadonnées GCP"
echo "------------------------------------------------------------"
ID_TOKEN=$(curl -s -H "Metadata-Flavor: Google" "$METADATA_URL" | tr -d '\n\r')
if [[ "$ID_TOKEN" == eyJ* ]]; then
GCP_JWT="$ID_TOKEN"
# Décoder et afficher la période de validité
PAYLOAD=$(echo "$GCP_JWT" | cut -d. -f2 | base64 --decode 2>/dev/null)
EXP=$(echo "$PAYLOAD" | jq -r '.exp')
ISS=$(echo "$PAYLOAD" | jq -r '.iss')
EMAIL=$(echo "$PAYLOAD" | jq -r '.email')
NOW=$(date +%s)
DIFF=$((EXP - NOW))
echo "Émetteur : $ISS"
echo "E-mail : $EMAIL"
echo "Audience : $AUDIENCE"
echo ""
echo "VALEUR DE GCP_JWT:"
echo "${GCP_JWT:0:80}... (truncated)"
echo ""
echo "Succès : JWT obtenu."
echo "Le token est valide pendant encore $DIFF secondes (environ $((DIFF / 60)) minutes)."
Autre situation
echo "ERREUR : échec de l’extraction du JWT depuis le serveur de métadonnées."
echo "Vérifiez que ce script s’exécute sur une VM GCP avec un compte de service associé."
exit 1
fi
# Exportation pour utilisation par sft
export GCP_TOKEN="$GCP_JWT"
echo ""
# ─── ÉTAPE 2 : ÉCHANGER LE JWT GCP CONTRE UN TOKEN OPA ──────────────────────────────────
echo "------------------------------------------------------------"
echo "ÉTAPE 2 : authentification du workload avec OPA pour obtenir OPA_TOKEN"
echo "------------------------------------------------------------"
echo "Exécution :"
echo "sft wl authenticate --team $SFT_TEAM \\"
echo " --connection $CONNECTION_NAME \\"
echo " --role-hint $ROLE_NAME \\"
echo " --jwt-env GCP_TOKEN"
echo ""
OPA_TOKEN=$(sft wl authenticate \
--team "$SFT_TEAM" \
--connection "$CONNECTION_NAME" \
--role-hint "$ROLE_NAME" \
--jwt-env GCP_TOKEN 2>&1 | tr -d '\n\r')
export OPA_TOKEN
if [[ "$OPA_TOKEN" == *"error"* ]] || [[ -z "$OPA_TOKEN" ]]; then
echo "ERREUR : échec de l’obtention de OPA_TOKEN."
echo "Detail: $OPA_TOKEN"
echo ""
echo "Checklist:"
echo " 1. Le statut de la connexion Workload est-il ACTIF (et non Brouillon) ?"
echo " 2. Le nom de connexion « $CONNECTION_NAME » correspond-il exactement ?
echo " 3. La déclaration aud est-elle égale à « $AUDIENCE » ?
echo " 4. La déclaration e-mail correspond-elle au SA dans la connexion de workload ?"
exit 1
Autre situation
echo "SUCCÈS : OPA_TOKEN obtenu."
echo ""
echo "VALEUR DE OPA_TOKEN :"
echo "${OPA_TOKEN:0:80}... (tronqué)"
fi
echo ""
# ─── ÉTAPE 3 : UTILISER LE TOKEN OPA POUR ACCÉDER AU SERVEUR CIBLE ───────────────────────
echo "------------------------------------------------------------"
echo "ÉTAPE 3 : test d'OPA_TOKEN avec les commandes sft"
echo "------------------------------------------------------------"
echo ""
echo "3a. Liste des serveurs auxquels ce workload peut accéder :"
sft list-servers
echo ""
echo "3b. Connexion à $TARGET_SERVER en tant que root et exécution d’une commande :
sft ssh --command "hostname && whoami && date && echo 'Workload access SUCCESS'" \
"$TARGET_SERVER"
echo ""
echo "------------------------------------------------------------"
echo « TERMINÉ : démo d’identité de workload terminée. »
echo "Consultez Okta System Log pour deux événements :"
echo " 1. Échange de token (authentification)"
echo " 2. Connexion SSH au serveur"
echo "------------------------------------------------------------"
5.2 Exécuter le script d’automatisation
Exécuter le script d’automatisation :
$ bash ~/opa-workload-test.sh
5.3 Résultat attendu et journaux d’audit
À l’exécution, le terminal affiche :
Le résultat présente un flux complet d’authentification SSH sans identifiant en trois étapes :
Extraction d’identité GCP : la machine virtuelle d’exécution demande directement à Google Cloud metadata (accounts.google.com) un JWT signé par la plateforme pour le compte de service opa-runner-sa, établissant son identité sans secrets stockés.
Échange de SToken : le script transmet le JWT GCP à Okta Privileged Access via sft wl authenticate. OPA vérifie la signature cryptographique de Google et émet un OPA_TOKEN associé au rôle okta_opa_wr.
Exécution sans mot de passe : OPA détecte target-vm et utilise un certificat SSH éphémère temporaire pour exécuter des commandes sur le serveur distant.
La réponse du serveur cible affiche son nom d’hôte (target-vm), l’utilisateur de workload attribué par le système (wl_okta_opa_wr) et l’horodatage d’exécution. Cela confirme un accès SSH complet et traçable, entièrement piloté par des preuves de plateforme à l’exécution plutôt que par des clés statiques.
Auditabilité et journaux système
Chaque cycle d’authentification génère des événements structurés dans Okta System Log (Okta Admin Console → Rapports → Journal système).
Vous pouvez appliquer le filtre suivant pour afficher les journaux système requis :
eventType eq "pam.user_creds.issue" and actor.type eq "WorkloadPrincipal"
Éliminez les secrets statiques de votre infrastructure d’automatisation
En remplaçant les clés SSH permanentes et les fichiers de compte de service par des preuves d’identité cryptographiques signées par la plateforme, vos équipes de sécurité et d’ingénierie peuvent bénéficier d’un véritable accès aux serveurs Zero Trust sans interrompre les pipelines d’automatisation. Okta Privileged Access simplifie la gestion des identités et des accès non humains en réunissant la fédération dynamique des workloads, la délivrance de certificats éphémères et une auditabilité complète au sein d’un point de contrôle unique.
Découvrez comment Okta Privileged Access protège les identités humaines et machines sur l’ensemble de vos ressources cloud.
