Centraliser les identifiants

Utilisez des identifiants nommés du Key Store pour dépôts privés, hôtes gérés et mots de passe Ansible Vault. Gardez code et configuration non sensible dans Git, tandis que le modèle référence les identifiants nécessaires. Une référence facilite réutilisation et rotation par rapport aux valeurs intégrées aux scripts. Elle ne remplace pas la protection du droit de modifier le code exécutable, puisque ce code utilise les accès fournis.

Non. Ansible Vault protège le contenu Ansible chiffré ; un Task Template peut utiliser un mot de passe Vault du Key Store Semaphore pour le déverrouiller. HashiCorp Vault est une option distincte de stockage externe Pro pour les secrets du Key Store. La vérification enregistrée de cette page montre le parcours du mot de passe Ansible Vault, pas une connexion à HashiCorp Vault. Évaluez ce stockage séparément avec un identifiant temporaire avant un usage opérationnel.

Les valeurs locales du Key Store utilisent le mécanisme de chiffrement des clés d’accès configuré pour leur stockage en base. Configurez et protégez correctement ce chiffrement et incluez ses conditions de récupération dans votre procédure de sauvegarde. Le chiffrement au repos est un élément de la conception : l’exécution autorisée doit encore utiliser l’identifiant. Protégez serveur, environnement d’exécution, accès administratif et journaux plutôt que de considérer une valeur chiffrée en base comme inaccessible à tout code ou ingénieur.

Les sources d’environnement et de fichiers documentées sont résolues par le serveur Semaphore lorsque la tâche a besoin de la clé, y compris avec un runner distant. Les fichiers doivent respecter le répertoire de secrets autorisé et le format documenté. Une tâche ultérieure peut récupérer une valeur renouvelée sans réécrire son modèle. Placer un fichier de clé brut sur le runner ne met pas en œuvre ce mécanisme serveur.

Oui. Pro prend en charge HashiCorp Vault et OpenBao comme sources externes. Enterprise ajoute d’autres intégrations de gestionnaires de secrets. Configurez le fournisseur et référencez les identifiants via le Key Store plutôt que d’enregistrer la valeur dans Git. Suivez le guide pour authentification et chemins, puis testez le travail avec les identifiants prévus.

Les modèles référencent des identifiants nommés plutôt que d’intégrer un mot de passe ou une clé dans chaque travail. Mettez à jour l’identifiant ou sa source, puis vérifiez les dépôts et inventaires qui le référencent. Testez une tâche représentative après rotation pour détecter les erreurs avant la prochaine exécution planifiée de production.

Ne comptez pas sur une garantie universelle de masquage. Un playbook ou script peut afficher des variables sensibles, arguments de commande ou réponses API. Choisissez délibérément les informations journalisées, utilisez les options de protection des secrets de l’outil et examinez des sorties d’échec représentatives aussi bien que les réussites. Restreignez l’accès aux journaux et exports selon leur contenu. Stocker une valeur de façon sûre ne contrôle pas à lui seul tout ce qu’affiche le code exécuté.

Oui. Nommez l’identifiant dans le Key Store et sélectionnez-le partout où dépôt, inventaire ou modèle nécessitent ce type. Les travaux référencent l’entrée configurée plutôt qu’une copie dans Git. Utilisez des identifiants séparés si les cibles nécessitent différentes identités. Voir les Task Templates.