Déploiements durcis

Un déploiement durci est un déploiement qui restreint l'enregistrement des workflows aux utilisateurs et aux comptes de service autorisés. Une entrée d'autorisation est appelée épingle. Utilisez le durcissement pour contrôler quels workers peuvent enregistrer des workflows de production, en particulier les workflows on-behalf-of (OBO), qui agissent au nom de l'utilisateur qui déclenche une exécution.

Le durcissement est un paramètre explicite, indépendant du nombre d'épingles. La suppression de la dernière épingle laisse un déploiement durci fermé : elle ne réouvre pas l'enregistrement. Ce comportement évite que la suppression d'un accès n'accorde accidentellement l'accès à tout le monde.

Si des workers d'un même déploiement enregistrent des implémentations différentes sous le même nom de workflow, vous ne pouvez pas prédire quelle implémentation traite une exécution. Un enregistrement accidentel ou non autorisé peut donc perturber les workflows de production.

Les workflows OBO peuvent utiliser l'accès délégué aux ressources de l'utilisateur qui déclenche l'exécution, comme des fichiers ou des connecteurs. Ils nécessitent un déploiement durci afin que seuls les principaux autorisés puissent enregistrer ces workflows.

Les épingles autorisent une identité plutôt qu'un processus worker particulier :

• Utilisateur : autorise les clés API éligibles appartenant à cet utilisateur. Renouveler la clé d'un utilisateur ne nécessite pas de modifier l'épingle utilisateur.
• Compte de service : autorise les charges de travail qui s'authentifient en tant que ce compte de service, y compris via la fédération d'identité de charge de travail. Ses identifiants peuvent être renouvelés sans modifier l'épingle.
• Épingle existante de clé API utilisateur : reste visible et supprimable pour des raisons de compatibilité, mais n'autorise que cette clé précise. Les autres clés appartenant au même utilisateur ne correspondent pas à une épingle de clé API ; utilisez une épingle utilisateur pour éviter les mises à jour lors du renouvellement des clés.

Les clés API de compte de service ne peuvent pas être sélectionnées comme épingles. Épinglez le principal du compte de service à la place, afin que l'autorisation suive l'identité du runtime plutôt qu'un identifiant remplaçable.

Les propriétaires de déploiement et les administrateurs d'espace de travail peuvent gérer le durcissement et les épingles dans l'onglet Paramètres du déploiement dans Studio. La propriété permet à la personne qui exploite un déploiement d'apporter des changements courants sans intervention d'un administrateur ; les administrateurs conservent les capacités de récupération et de réattribution de la propriété. La propriété est distincte d'une épingle : être propriétaire n'autorise pas à lui seul l'enregistrement de workers.

Un utilisateur doit disposer de la permission AccessWorkflows dans l'espace de travail cible pour posséder un déploiement, être épinglé ou revendiquer automatiquement un déploiement OBO local. Un utilisateur qui ne peut pas utiliser les Workflows ne doit pas acquérir d'accès indirect via la propriété ou une épingle. Si vous ne disposez pas de cette permission, demandez à un administrateur d'espace de travail un rôle donnant accès aux Workflows.

Pour un utilisateur éligible, le premier enregistrement OBO local sous un nouveau nom de déploiement réussit sans qu'un administrateur ait préparé le déploiement :

1. Utilisez une clé API appartenant à un utilisateur disposant de AccessWorkflows dans l'espace de travail cible.
2. Configurez un workflow OBO et démarrez son worker avec un nouveau nom de déploiement.
3. L'enregistrement crée le déploiement de manière atomique, vous désigne comme propriétaire, épingle votre principal utilisateur et active le durcissement.
4. Ouvrez l'onglet Paramètres du déploiement dans Studio pour vérifier ou ajouter des principaux autorisés avant que vos collègues ne le rejoignent.

C'est le principal utilisateur qui est épinglé, et non la clé API ; les clés éligibles du même utilisateur continuent donc de fonctionner après leur renouvellement. Cette revendication automatique ne s'applique qu'aux enregistrements OBO effectués par des utilisateurs : durcir chaque déploiement local partagé classique pourrait permettre au premier worker d'exclure ses collègues.

Si le nom existe déjà, l'enregistrement ne prend pas le contrôle d'un déploiement sans propriétaire ni d'un déploiement appartenant à un autre utilisateur. Le durcissement automatique ne peut s'appliquer à un déploiement local existant que si vous en êtes déjà propriétaire, que le déploiement n'est pas durci et ne comporte aucune épingle, et qu'aucun autre worker n'est actif. Un second utilisateur ne peut pas revendiquer un déploiement durci existant ; son propriétaire ou un administrateur d'espace de travail doit l'autoriser à le rejoindre.

Les appelants s'authentifiant en tant que compte de service ne sont pas revendiqués automatiquement et ne peuvent pas devenir propriétaires via ce flux. Un compte de service épinglé peut toujours exécuter des workflows OBO : l'identité du runtime autorise l'enregistrement, tandis que l'identité de l'utilisateur qui déclenche l'exécution fournit l'accès délégué.

Durcissement initial des déploiements gérés

Les nouveaux déploiements gérés créés dans Studio sont durcis par défaut, avec une option explicite pour se désabonner lors de la création. La plateforme épingle automatiquement le compte de service du runtime géré, ce qui permet de renouveler les identifiants du runtime sans modifier l'autorisation d'enregistrement.

La valeur par défaut de Studio ne change pas les valeurs par défaut des autres clients. Si vous avez opté pour la désactivation ou créé un déploiement géré non durci via un autre client, activez le durcissement avant d'enregistrer des workflows OBO.

Ouvrez le déploiement dans Studio et sélectionnez son onglet Paramètres. Vous devez en être le propriétaire ou être administrateur d'espace de travail pour modifier le durcissement ou gérer les épingles.

Activer le durcissement

1. Arrêtez les workers du déploiement. Pour un déploiement géré, arrêtez également le service géré.
2. Attendez que le déploiement soit inactif.
3. Activez le durcissement dans Paramètres.

La plateforme sélectionne automatiquement l'identité épinglée initialement : le propriétaire pour un déploiement local, ou le compte de service du runtime géré pour un déploiement géré. Si un déploiement local n'a pas de propriétaire, demandez d'abord à un administrateur de l'espace de travail de désigner un utilisateur éligible.

Le durcissement exige l'inactivité du déploiement, car modifier l'autorisation d'enregistrement n'arrête pas les workers déjà actifs sur le déploiement.

Ajouter ou retirer des épingles

Utilisez Paramètres pour autoriser des utilisateurs ou des comptes de service sur un déploiement durci. Plusieurs épingles permettent à plusieurs principaux autorisés d'enregistrer des workers sur le même déploiement. La suppression d'une épingle supprime cette entrée d'autorisation ; la suppression de la dernière épingle laisse le durcissement activé et l'enregistrement fermé.

Désactiver le durcissement

Désactivez le durcissement dans Paramètres uniquement lorsque vous souhaitez rouvrir l'enregistrement. Une requête réussie désactive le durcissement de manière atomique et supprime toutes les épingles, y compris celle du runtime géré, afin qu'un déploiement ouvert ne conserve aucun état d'autorisation obsolète susceptible de s'appliquer de manière inattendue ultérieurement.

La désactivation du durcissement est refusée tant qu'un workflow OBO est enregistré sur le déploiement. Ces workflows nécessitent un enregistrement contrôlé pour protéger l'accès délégué de l'utilisateur. Arrêter les workers ne suffit pas : supprimez les enregistrements OBO avant de réessayer.

Réconciliation automatique des épingles

Les épingles d'utilisateur et de compte de service invalides sont réconciliées périodiquement. Une épingle n'est supprimée que lorsque la validation établit de manière concluante que le principal n'est plus éligible. Les échecs de dépendances ou un contexte manquant préservent l'épingle pour une tentative ultérieure ; un échec de validation temporaire ne révoque donc pas un accès de production fonctionnel.

Le durcissement limite l'enregistrement des workflows aux principaux que vous autorisez. Il ne valide pas le code soumis par un principal autorisé et ne remplace pas la protection des identifiants de ce principal.

Résoudre les problèmes d'enregistrement

Les refus d'autorisation de déploiement incluent un lien direct vers l'onglet Paramètres du déploiement dans Studio. Le lien sélectionne l'organisation, l'espace de travail et le déploiement concernés afin que la personne qui corrige l'accès arrive aux bons contrôles.

Pour le code de workflow et les identifiants délégués, continuez avec Workflows on-behalf-of.