Exigences et limites

L'authentification des charges de travail présente les exigences et limitations suivantes.

Exigences d'authentification

Vous pouvez authentifier les charges de travail à l'aide de l'une des deux méthodes suivantes : l'authentification basée sur JWT ou l'authentification basée sur une clé API.

Exigences en matière d'authentification avec JWT

  • Source d'identité : la charge de travail doit pouvoir s'authentifier à l'aide de jetons Web JSON (JWT).

  • Prise en charge du fournisseur : Okta Privileged Access fournit une prise en charge prête à l'emploi pour la vérification des jetons JWT provenant de fournisseurs fédérés spécifiques, notamment Google Cloud Platform, GitLab et CircleCI.

  • 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.

Exigences en matière d'authentification avec la clé d'API

  • Approvisionnement des administrateurs de la sécurité : seuls les administrateurs de sécurité peuvent créer et gérer les connexions par des clés d'API et générer des clés d'API.

  • Révélation unique : les clés d'API sont révélées une seule fois lors de leur création et doivent être copiées immédiatement. Vous ne pourrez pas récupérer la clé ultérieurement.

  • Livraison hors bande : l'administrateur de sécurité transmet la clé d'API à l'ingénieur DevOps via un canal sécurisé en dehors de l'Okta Platform.

  • Idéal pour les charges de travail hors cloud : les connexions avec clé d'API sont recommandées pour les charges de travail locales ou hors cloud qui n'ont pas accès à un fournisseur d'identité fédéré.

Exigences générales

  • Outils client requis : utilisez l'interface de ligne de commande du client Okta Privileged Access pour les tâches non interactives et l'authentification de la charge de travail. Certaines opérations d'identifiants n'ont pas de commande CLI et sont uniquement disponibles via l'API.

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 (pour les connexions avec JWT) ou une nouvelle clé d'API (pour les connexions avec clé d'API).

  • Aucune révocation d'un jeton 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. Pour les clés d'API, vous pouvez révoquer des clés d'API individuelles afin d'empêcher leur utilisation pour créer de nouveaux jetons.

  • 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.

  • 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.

  • Rotation de mot de passe Active Directory : la rotation du mot de passe d'un compte Active Directory (AD) est uniquement disponible via l'API. Le CLI client n'inclut pas de commande pour cette opération. Les charges de travail peuvent révéler les mots de passe des comptes AD en exécutant la commande sft ad reveal ou en appelant l'API. La prise en charge des comptes AD est une fonctionnalité en accès anticipé .

  • Historique des versions des identifiants Active Directory : les charges de travail ne peuvent pas répertorier les versions des identifiants des comptes Active Directory. Cette opération est disponible uniquement pour les utilisateurs.

Limitations des clés d'API

  • Pas d'auto-rotation : les charges de travail ne peuvent pas procéder à une rotation de leurs propres clés d'API. Seuls les administrateurs de sécurité peuvent initier une rotation des clés.

  • Délai de mise en cache lors de la révocation : lorsqu'une clé d'API est révoquée, l'expiration du cache de l'émetteur du jeton peut prendre jusqu'à cinq minutes, période pendant laquelle les jetons mis en cache existants peuvent toujours être acceptés.

  • Pas de stockage dans un coffre-fort (version en disponibilité générale) : les clés d'API ne sont pas stockées dans un coffre-fort de secrets. Les administrateurs de sécurité doivent distribuer les clés hors bande aux équipes chargées des charges de travail. Le stockage dans un coffre-fort et la distribution automatique des clés sont planifiés dans les versions futures.

  • Pas d'opérations en masse (version en disponibilité générale) : la création ou la rotation en masse de clés d'API n'est pas disponible dans la version en disponibilité générale. Chaque clé doit être créée individuellement. Des opérations en masse sont planifiées dans les versions futures.