Feature 6 : Intégration avec Cloud Secret Manager #

Aperçu #

Semaphore stocke actuellement toutes les informations d’identification dans sa propre base de données. Les organisations utilisant des plateformes cloud ont besoin d’un moyen de récupérer les secrets directement depuis le service de gestion des secrets de leur fournisseur cloud au moment de l’exécution, évitant ainsi la duplication des informations d’identification et tirant parti des politiques de rotation existantes. Cette fonctionnalité ajoute des intégrations natives avec AWS Secrets Manager et Azure Key Vault en tant que capacités exclusives Enterprise.

Motivation #

• Les équipes Enterprise gèrent déjà leurs secrets dans AWS Secrets Manager ou Azure Key Vault avec des politiques de rotation établies, des contrôles d’accès et des pistes d’audit. Dupliquer ces informations d’identification dans la base de données de Semaphore crée une deuxième source de vérité qui peut se désynchroniser.
• La rotation des informations d’identification chez le fournisseur cloud ne se propage pas automatiquement à Semaphore — quelqu’un doit manuellement mettre à jour chaque entrée du key store affectée après chaque rotation.
• Les politiques de conformité et de sécurité dans les industries réglementées exigent souvent que les secrets ne quittent jamais le périmètre du fournisseur cloud et ne soient pas stockés dans des bases de données tierces.
• Le key store intégré de Semaphore manque des contrôles d’accès, de la granularité d’audit et de l’automatisation de rotation que les cloud secret managers fournissent nativement.

Spécification détaillée #

Enterprise #

6.1 Intégration AWS Secrets Manager #

Objectif : Récupérer les secrets au moment de l’exécution depuis AWS Secrets Manager, permettant aux équipes de tirer parti de leur infrastructure AWS de secrets existante sans dupliquer les informations d’identification dans la base de données de Semaphore.

Exigences :

• Nouveau type de backend de secrets externe : aws_secrets_manager.
• Méthodes d’authentification :
  • Rôle IAM (recommandé pour les déploiements EC2/ECS/EKS) — aucune information d’identification stockée dans Semaphore.
  • Access key + secret key — stockés dans le key store de Semaphore (chiffrés).
  • Rôle assumé avec ID externe — pour l’accès inter-comptes.
• Les secrets sont référencés par ARN ou nom + version/étape optionnelle.
• Prise en charge des secrets structurés en JSON avec un sélecteur field pour extraire des valeurs individuelles (p. ex., {"username": "admin", "password": "..."} → extraire password).
• Prise en charge automatique de la rotation des secrets — lorsque AWS effectue la rotation d’un secret, Semaphore récupère la nouvelle valeur lors de la prochaine exécution de tâche.
• Modèle de configuration :

{
  "name": "Production AWS",
  "type": "aws_secrets_manager",
  "region": "us-east-1",
  "auth_method": "iam_role",
  "role_arn": "arn:aws:iam::123456789:role/semaphore-secrets",
  "external_id": "optional-external-id"
}

• Référence d’entrée du key store :

{
  "type": "external",
  "backend": "aws_secrets_manager",
  "secret_name": "production/db_password",
  "field": "password",
  "aws_config_id": 1
}

Issues associés : #2248

6.2 Intégration Azure Key Vault #

Objectif : Récupérer les secrets au moment de l’exécution depuis Azure Key Vault, permettant aux organisations utilisant Azure de gérer et faire la rotation des informations d’identification de manière centralisée sans les stocker dans Semaphore.

Exigences :

• Nouveau type de backend de secrets externe : azure_key_vault.
• Méthodes d’authentification :
  • Managed identity (recommandé pour les déploiements Azure VM/AKS) — aucune information d’identification stockée dans Semaphore.
  • Service principal avec client secret.
  • Service principal avec certificat.
• Les secrets sont référencés par URL du vault + nom du secret + version optionnelle.
• Prise en charge de la récupération de secrets, clés et certificats depuis le vault.
• Prise en charge automatique de la rotation des secrets — lorsque Azure effectue la rotation d’un secret, Semaphore récupère la nouvelle valeur lors de la prochaine exécution de tâche.
• Modèle de configuration :

{
  "name": "Production Azure",
  "type": "azure_key_vault",
  "vault_url": "https://my-vault.vault.azure.net",
  "auth_method": "managed_identity",
  "tenant_id": "...",
  "client_id": "..."
}

• Référence d’entrée du key store :

{
  "type": "external",
  "backend": "azure_key_vault",
  "secret_name": "db-password",
  "version": "latest",
  "azure_config_id": 1
}

Issues associés : #2248, #3170

6.3 Référence externe unifiée de secrets #

Objectif : Fournir un type d’entrée de key store commun qui pointe vers un secret chez n’importe quel fournisseur cloud pris en charge.

Exigences :

• Nouveau type de key store : « External Reference » qui stocke un pointeur vers le secret (p. ex., AWS ARN, URL du vault Azure + nom du secret) au lieu du secret lui-même.
• Au moment de l’exécution de la tâche, Semaphore résout la référence en appelant l’API du fournisseur cloud et récupère la valeur actuelle.
• La valeur résolue n’est jamais stockée dans la base de données de Semaphore — elle n’existe qu’en mémoire pendant l’exécution de la tâche.
• La connexion au cloud secret manager est configurée au niveau du projet ou du système (URL, méthode d’authentification, namespace/préfixe).
• L’interface utilisateur affiche les références externes avec un badge/icône distinctif et le type de backend (AWS/Azure).
• Validation lors de l’enregistrement : Semaphore tente de résoudre la référence et affiche un avertissement si le secret n’est pas accessible (sans bloquer l’enregistrement).

6.4 Mise en cache des secrets #

Objectif : Réduire les appels API aux fournisseurs cloud en mettant en cache les secrets résolus en mémoire.

Exigences :

• Cache en mémoire optionnel de courte durée (TTL configurable, par défaut 5 minutes) pour réduire les appels API au fournisseur cloud.
• Le cache est uniquement en mémoire et est invalidé au redémarrage de Semaphore.
• Le cache est indexé par ID de configuration du backend + référence du secret, de sorte que le même secret utilisé par plusieurs templates n’est récupéré qu’une seule fois par fenêtre de TTL.
• Le cache peut être désactivé par configuration de backend (définir le TTL à 0) pour les secrets qui doivent toujours être récupérés à jour (p. ex., pendant une rotation active).
• Configuration : champ cache_ttl dans la configuration du backend (p. ex., "cache_ttl": "5m").

Modifications du schéma de base de données #

Nouvelles tables :

• secret_backend — stocke les configurations du fournisseur cloud (project_id, type, name, config JSON, created_at, updated_at)

Tables modifiées :

• access_key — ajouter les colonnes :
  • external_backend_id (integer, nullable, FK vers secret_backend) — lien vers la configuration du fournisseur cloud
  • external_reference (JSON, nullable) — stocke le pointeur vers le secret (ARN, URL du vault, nom du secret, field, version)

API Endpoints #

• GET/POST /api/project/{id}/secret-backends — lister/créer des configurations de backend
• PUT/DELETE /api/project/{id}/secret-backends/{backend_id} — mettre à jour/supprimer un backend
• POST /api/project/{id}/secret-backends/{backend_id}/test — tester la connectivité et l’authentification
• POST /api/project/{id}/secret-backends/{backend_id}/resolve — résoudre une référence de secret (pour validation)

Configuration #

Nouvelles options de configuration :

Key	Env Var	Default	Description
secret_cache_ttl	SEMAPHORE_SECRET_CACHE_TTL	5m	TTL par défaut du cache en mémoire pour les secrets externes résolus
secret_resolve_timeout	SEMAPHORE_SECRET_RESOLVE_TIMEOUT	10s	Temps maximum d’attente d’une réponse de l’API du fournisseur cloud lors de la résolution d’un secret

You might also like