Déploiements sécurisés

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 une é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 existantes. La suppression de la dernière épingle laisse un déploiement durci fermé : elle ne rouvre pas l'enregistrement. Cela évite que la suppression d'un accès n'accorde par erreur l'accès à tout le monde.

Si des workers d'un même déploiement enregistrent différentes implémentations 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 et des connecteurs. Ils nécessitent un déploiement durci pour que seuls les principaux autorisés puissent enregistrer ces workflows.

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

• Utilisateur : autorise les clés API éligibles appartenant à cet utilisateur. Le renouvellement de la clé d'un utilisateur ne nécessite pas de modifier l'épingle d'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 de clé API d'utilisateur existante : 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 d'utilisateur pour éviter des 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 plutôt le principal du compte de service, pour 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'effectuer des modifications courantes sans intervention d'un administrateur ; les administrateurs conservent les fonctions de récupération et de réattribution de la propriété. La propriété est distincte d'une épingle : être propriétaire ne suffit pas à autoriser l'enregistrement de workers.

Un utilisateur doit disposer de la permission AccessWorkflows dans l'espace de travail cible pour être propriétaire d'un déploiement, être épinglé ou revendiquer automatiquement un déploiement OBO local. Un utilisateur qui ne peut pas utiliser Workflows ne doit pas obtenir d'accès indirect par la propriété ou une épingle. Demandez à un administrateur d'espace de travail un rôle avec accès à Workflows si vous ne disposez pas de cette permission.

Pour un utilisateur éligible, le premier enregistrement OBO local sous un nouveau nom de déploiement réussit sans qu'un administrateur prépare 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 d'utilisateur et active le durcissement.
4. Ouvrez l'onglet Paramètres du déploiement dans Studio pour examiner ou ajouter des principaux autorisés avant que les membres de votre équipe ne le rejoignent.

C'est le principal d'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 d'utilisateur : durcir chaque déploiement local partagé ordinaire pourrait permettre au premier worker d'exclure les membres de l'équipe.

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, s'il n'est pas durci et ne comporte aucune épingle, et si 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 avec un compte de service ne bénéficient pas de la revendication automatique 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 de désabonnement explicite 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 modifie pas celle de chaque client. Si vous vous désabonnez ou créez 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'épingle initiale : 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 d'espace de travail de désigner un utilisateur éligible.

Le durcissement nécessite que le déploiement soit inactif, car modifier l'autorisation d'enregistrement n'arrête pas les workers qui y sont déjà actifs.

Ajouter ou supprimer 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 retire 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 façon inattendue plus tard.

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. L'arrêt des workers ne suffit pas : supprimez les enregistrements OBO avant de réessayer.

Rapprochement automatique des épingles

Les épingles d'utilisateur et de compte de service invalides font l'objet d'un rapprochement périodique. Une épingle n'est supprimée que lorsque la validation montre de façon concluante que le principal n'est plus éligible. Les défaillances de dépendances ou l'absence de contexte préservent l'épingle pour une tentative ultérieure, afin qu'un échec de validation temporaire ne révoque 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. Ce lien sélectionne l'organisation, l'espace de travail et le déploiement concernés, afin que la personne qui corrige l'accès accède aux bons contrôles.

Pour le code des workflows et les identifiants délégués, poursuivez avec Workflows on-behalf-of.