Choisir le bon accès Git
- Personal account : Agent utilise votre compte autorisé pour l’inspection interactive du code, les push de branches et les pull requests ou merge requests.
- Workspace connection(s) : les builds d’environnement en arrière-plan utilisent les autorisations de dépôt de l’espace de travail sans dépendre de votre session de chat personnelle. Seuls les administrateurs de l’espace de travail peuvent les configurer.
Les ressources externes nécessitent une identité distincte
L’accès Git seul ne donne pas accès à AWS, à un gestionnaire de secrets ou à des paquets privés. Pour un environnement qui a besoin de manière répétée d’un service externe, privilégiez la fédération d’identité de charge de travail lorsque le fournisseur la prend en charge : un administrateur établit une relation de confiance chez le fournisseur, puis le sandbox en cours d’exécution présente un JWT de charge de travail Replit de courte durée pour l’échange d’identifiants. Limitez l’audience, les claims, les rôles et les autorisations sur les ressources côté fournisseur. La confiance peut être plus large qu’un seul sandbox si la politique du fournisseur utilise un claim à l’échelle de l’espace de travail. Les guides pas à pas AWS et Infisical présentent des modèles de fédération concrets et leurs limites de confiance. Pour un identifiant ponctuel nécessaire uniquement dans votre chat privé, utilisez plutôt les secrets de chat. Vous pouvez valider des scripts utilitaires révisés et une configuration non secrète ; les valeurs d’identifiants, les JWT émis et les jetons échangés n’ont leur place ni dans Git ni dans une image préconstruite.Ces workflows en accès anticipé et ces recettes de fournisseurs doivent être vérifiés par rapport aux paramètres actuels de votre organisation. Les exemples AWS et Infisical sont des recettes de documentation, et non une affirmation que votre compte cloud ou un échange de fédération en direct a été testé.