Débuter

Configurez Okta Privileged Access pour authentifier des charges de travail automatisées afin qu'elles puissent accéder en toute sécurité à des ressources privilégiées. Choisissez la méthode d'authentification la mieux adaptée à votre environnement de charge de travail : basée sur JWT pour les charges de travail cloud natives avec identité fédérée, ou basée sur une clé API pour les environnements sur site et non cloud.

Avant de commencer, consultez les exigences et les limites pour comprendre les conditions nécessaires et les contraintes d'authentification pour votre environnement.

Workflow d'authentification JWT

Pour les connexions JWT, le processus nécessite une collaboration entre deux rôles d'administrateur :

Administrateur DevOps – Crée et teste la configuration d'identité de la machine et connaît le système source.
Administrateur de la sécurité – Gère l'accès, approuve la configuration de l'identité pour une utilisation en production et définit les politiques d'autorisation.

Pour les connexions par clé API, seuls les administrateurs de sécurité effectuent toutes les tâches de configuration, y compris la création de connexions, la génération, la rotation et la révocation des clés.

Phase	Rôle	Action
Phase 1 : Connexion	Administrateur DevOps	Crée la connexion à la charge de travail avec le statut Brouillon. En mode Brouillon, la CLI renvoie un message de validation réussi, mais elle n'émet pas de jeton utilisable. Cela vous permet de vérifier votre logique de déclaration sans accorder d'accès. Voir Configurer une connexion à la charge de travail. Teste la commande non interactive spécifique (`sft workload authenticate`) utilisée par le script d'automatisation. Cela vérifie la syntaxe de la CLI et confirme que le JWT de la charge de travail réussit la validation avec la connexion brouillon. Voir Commande CLI pour l'authentification de la charge de travail. Remarque : Si vous exécutez `sft workload authenticate` alors que l'état est Brouillon, le système nécessite environ 5 minutes pour actualiser les détails de connexion à la charge de travail après le passage à Actif avant d'émettre un jeton Okta Privileged Access infalsifiable.
Phase 2 : Gouvernance	Administrateur de sécurité	Passe en révision et fait passer la connexion de Brouillon à Actif. Voir Gérer une connexion à la charge de travail. Lors de l'activation, l'administrateur DevOps perd l'accès en écriture à la connexion à la charge de travail.
Phase 3 : Logique	Administrateur de sécurité	Crée un rôle de charge de travail, en définissant les conditions basées sur des attributs qui déterminent qui est éligible à ce rôle. Voir Configurer les rôles de charge de travail. Crée ou met à jour la politique, en sélectionnant le nouveau rôle de charge de travail comme entité principale. Consultez la section Créer ou mettre à jour une politique de sécurité.
Phase 4 : Déploiement	Administrateur DevOps	Injecte `sft wl auth` dans le pipeline CI/CD de la charge de travail. La charge de travail automatisée exécute la commande du client Okta Privileged Access améliorée, en se référant au nom de connexion à la charge de travail active. Les événements d'accès sont consignés dans le Okta System Log.

Workflow d'authentification par clé API

Pour les connexions par clé API, seuls les administrateurs de sécurité effectuent toutes les tâches de configuration. Le workflow est plus simple que le JWT, car il n'y a pas de phase de révision à double contrôle : la connexion est créée directement en statut actif et est immédiatement prête pour la génération de clés.

Phase	Rôle	Action
Phase 1 : Connexion	Administrateur de sécurité	Crée la connexion de charge de travail par clé API avec le statut Actif. Contrairement aux connexions JWT, il n'y a pas de phase de brouillon. Voir Configurer une connexion à la charge de travail.
Phase 2 : Génération	Administrateur de sécurité	Configurez éventuellement les déclarations de clé API (paires clé-valeur) incluses dans les jetons de charge de travail et utilisées pour le mappage des rôles. Génère la première clé API pour la charge de travail. La clé brute n'est révélée qu'une seule fois et vous devez la copier immédiatement. Consultez Gérer les clés API. Fournit la clé API à l'ingénieur DevOps via un canal sécurisé hors bande.
Phase 3 : Logique	Administrateur de sécurité	Crée un rôle de charge de travail, en définissant les conditions basées sur des attributs qui déterminent qui est éligible à ce rôle. Voir Configurer les rôles de charge de travail. Crée ou met à jour la politique, en sélectionnant le nouveau rôle de charge de travail comme entité principale. Consultez la section Créer ou mettre à jour une politique de sécurité.
Phase 4 : Déploiement	Administrateur DevOps	Injecte la clé API dans l'environnement de la charge de travail (en tant que variable d'environnement ; fichier de configuration ; ou gestionnaire de secrets). Injecte la commande `sft wl auth` dans le pipeline CI/CD de la charge de travail, en se référant au nom de connexion de la charge de travail active. La charge de travail utilise la clé API pour l'authentification. Voir Commande CLI pour l'authentification de la charge de travail. Les événements d'accès sont consignés dans le Okta System Log.