Exigences et limites
L'authentification des charges de travail présente les exigences et limitations suivantes.
Exigences d'authentification
-
Source d'identité : la charge de travail doit pouvoir s'authentifier à l'aide de jetons Web JSON (JWT).
-
Prise en charge du fournisseur : l'authentification est limitée aux JWT. Okta Privileged Access fournit une prise en charge prête à l'emploi pour la vérification des JWT provenant de fournisseurs fédérés spécifiques, notamment Google Cloud Platform, GitLab et CircleCI.
-
Outils client requis : vous devez utiliser la CLI du client Okta Privileged Access pour les tâches non interactives et les types d'authentification de la charge de travail.
-
Identité non fédérée : les machines non hébergées dans le cloud (sans fournisseur de confiance comme une plateforme cloud) ont besoin d'un mécanisme d'amorçage défini par le client pour fournir en toute sécurité la preuve JWT requise. Ce mécanisme résout le problème du zéro secret pour ces environnements.
Politique et limitations d'accès
-
Aucun rafraîchissement de jeton : le jeton Okta Privileged Access ne peut pas être rafraîchi. Si le jeton d'accès expire, la charge de travail doit procéder à une réauthentification complète en soumettant un nouveau JWT.
-
Aucune révocation spécifique : vous ne pouvez pas révoquer un jeton d'accès individuel. Définir une connexion à la charge de travail sur inactif empêche l'émission de nouveaux jetons. Si la connexion est réactivée, les jetons précédemment émis resteront valides.
-
Conception des politiques : les clients doivent concevoir des politiques Okta Privileged Access à l'aide de rôles de charge de travail.
-
Échec de l'accès utilisateur : lorsqu'une politique identifie à la fois des méthodes d'accès utilisateur (UAMs) valides et non valides, elle ne renvoie que l'option valide. Si une charge de travail reçoit plusieurs UAM valides, la politique fournit toutes les options possibles parmi lesquelles la charge de travail peut choisir. Okta recommande de définir clairement les rôle de charge de travail afin d'éviter toute ambiguïté des politiques.
Remarque :Un UAM non valide se produit lorsqu'une politique de sécurité accorde à une charge de travail l'accès à une ressource mais inclut des contraintes interactives, telles que la MFA, Demandes d'accès ou des réservations de ressources au niveau du projet. Étant donné que les charges de travail sont autonomes et ne peuvent pas effectuer ces actions nécessitant une intervention humaine, toute requête déclenchant ces exigences est automatiquement annulée.
-
Visibilité des identités de charge de travail : vous ne pouvez pas répertorier ni récupérer les identités de charge de travail directement via l'API publique ; les utilisateurs ne peuvent les voir que via les événements d'audit.
Rubriques connexes