Feature 6: Integration mit Cloud Secret Manager #

Übersicht #

Semaphore speichert derzeit alle Anmeldedaten in seiner eigenen Datenbank. Organisationen, die Cloud-Plattformen nutzen, benötigen eine Möglichkeit, Secrets zur Laufzeit direkt aus dem Secret-Management-Dienst ihres Cloud-Anbieters abzurufen, um die Duplizierung von Anmeldedaten zu vermeiden und bestehende Rotationsrichtlinien zu nutzen. Diese Funktion fügt native Integrationen mit AWS Secrets Manager und Azure Key Vault als ausschließliche Enterprise-Funktionalitäten hinzu.

Motivation #

• Enterprise-Teams verwalten ihre Secrets bereits in AWS Secrets Manager oder Azure Key Vault mit etablierten Rotationsrichtlinien, Zugriffskontrollen und Audit-Protokollen. Das Duplizieren dieser Anmeldedaten in die Semaphore-Datenbank erzeugt eine zweite Quelle der Wahrheit, die nicht mehr synchron sein kann.
• Die Rotation von Anmeldedaten beim Cloud-Anbieter wird nicht automatisch an Semaphore weitergegeben — jemand muss nach jeder Rotation manuell jeden betroffenen Key-Store-Eintrag aktualisieren.
• Compliance- und Sicherheitsrichtlinien in regulierten Branchen verlangen oft, dass Secrets die Grenzen des Cloud-Anbieters nie verlassen oder in Datenbanken von Drittanbietern gespeichert werden.
• Der integrierte Key-Store von Semaphore verfügt nicht über die Zugriffskontrollen, die Audit-Granularität und die Rotationsautomatisierung, die Cloud Secret Manager standardmäßig bieten.

Detaillierte Spezifikation #

Enterprise #

6.1 AWS Secrets Manager Integration #

Ziel: Secrets zur Laufzeit aus AWS Secrets Manager abrufen, damit Teams ihre bestehende AWS-Secrets-Infrastruktur nutzen können, ohne Anmeldedaten in der Semaphore-Datenbank zu duplizieren.

Anforderungen:

• Neuer externer Secret-Backend-Typ: aws_secrets_manager.
• Authentifizierungsmethoden:
  • IAM-Rolle (empfohlen für EC2/ECS/EKS-Deployments) — keine Anmeldedaten werden in Semaphore gespeichert.
  • Access Key + Secret Key — im Key-Store von Semaphore gespeichert (verschlüsselt).
  • Angenommene Rolle mit externer ID — für kontoübergreifenden Zugriff.
• Secrets werden über ARN oder Name + optionale Version/Stufe referenziert.
• Unterstützung für JSON-strukturierte Secrets mit einem field-Selektor zum Extrahieren einzelner Werte (z. B. {"username": "admin", "password": "..."} → password extrahieren).
• Automatische Unterstützung der Secret-Rotation — wenn AWS ein Secret rotiert, übernimmt Semaphore den neuen Wert beim nächsten Task-Lauf.
• Konfigurationsmodell:

{
  "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"
}

• Key-Store-Eintrag-Referenz:

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

Verwandte Issues: #2248

6.2 Azure Key Vault Integration #

Ziel: Secrets zur Laufzeit aus Azure Key Vault abrufen, damit Organisationen, die Azure nutzen, Anmeldedaten zentral verwalten und rotieren können, ohne sie in Semaphore zu speichern.

Anforderungen:

• Neuer externer Secret-Backend-Typ: azure_key_vault.
• Authentifizierungsmethoden:
  • Managed Identity (empfohlen für Azure VM/AKS-Deployments) — keine Anmeldedaten werden in Semaphore gespeichert.
  • Service Principal mit Client Secret.
  • Service Principal mit Zertifikat.
• Secrets werden über Vault-URL + Secret-Name + optionale Version referenziert.
• Unterstützung für das Abrufen von Secrets, Schlüsseln und Zertifikaten aus dem Vault.
• Automatische Unterstützung der Secret-Rotation — wenn Azure ein Secret rotiert, übernimmt Semaphore den neuen Wert beim nächsten Task-Lauf.
• Konfigurationsmodell:

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

• Key-Store-Eintrag-Referenz:

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

Verwandte Issues: #2248, #3170

6.3 Einheitliche externe Secret-Referenz #

Ziel: Einen gemeinsamen Key-Store-Eintragstyp bereitstellen, der auf ein Secret bei einem beliebigen unterstützten Cloud-Anbieter verweist.

Anforderungen:

• Neuer Key-Store-Typ: „External Reference", der einen Verweis auf das Secret speichert (z. B. AWS ARN, Azure Vault-URL + Secret-Name) anstelle des Secrets selbst.
• Zum Zeitpunkt der Task-Ausführung löst Semaphore die Referenz auf, indem es die API des Cloud-Anbieters aufruft und den aktuellen Wert abruft.
• Der aufgelöste Wert wird niemals in der Semaphore-Datenbank gespeichert — er existiert nur im Speicher während der Task-Ausführung.
• Die Verbindung zum Cloud Secret Manager wird auf Projekt- oder Systemebene konfiguriert (URL, Authentifizierungsmethode, Namespace/Präfix).
• Die Benutzeroberfläche zeigt externe Referenzen mit einem eigenen Badge/Symbol und dem Backend-Typ (AWS/Azure) an.
• Validierung beim Speichern: Semaphore versucht, die Referenz aufzulösen, und zeigt eine Warnung an, wenn das Secret nicht zugänglich ist (ohne das Speichern zu blockieren).

6.4 Secret-Caching #

Ziel: API-Aufrufe an Cloud-Anbieter durch Zwischenspeicherung aufgelöster Secrets im Speicher reduzieren.

Anforderungen:

• Optionaler kurzlebiger In-Memory-Cache (konfigurierbares TTL, Standard 5 Minuten) zur Reduzierung der API-Aufrufe an den Cloud-Anbieter.
• Der Cache befindet sich nur im Speicher und wird bei einem Neustart von Semaphore ungültig.
• Der Cache wird nach Backend-Konfigurations-ID + Secret-Referenz geschlüsselt, sodass dasselbe Secret, das von mehreren Templates verwendet wird, nur einmal pro TTL-Fenster abgerufen wird.
• Der Cache kann pro Backend-Konfiguration deaktiviert werden (TTL auf 0 setzen) für Secrets, die immer frisch abgerufen werden müssen (z. B. während einer aktiven Rotation).
• Konfiguration: cache_ttl-Feld in der Backend-Konfiguration (z. B. "cache_ttl": "5m").

Datenbankschema-Änderungen #

Neue Tabellen:

• secret_backend — speichert Cloud-Anbieter-Konfigurationen (project_id, type, name, config JSON, created_at, updated_at)

Geänderte Tabellen:

• access_key — neue Spalten:
  • external_backend_id (integer, nullable, FK zu secret_backend) — Verknüpfung zur Cloud-Anbieter-Konfiguration
  • external_reference (JSON, nullable) — speichert den Secret-Verweis (ARN, Vault-URL, Secret-Name, Field, Version)

API Endpoints #

• GET/POST /api/project/{id}/secret-backends — Backend-Konfigurationen auflisten/erstellen
• PUT/DELETE /api/project/{id}/secret-backends/{backend_id} — Backend aktualisieren/löschen
• POST /api/project/{id}/secret-backends/{backend_id}/test — Konnektivität und Authentifizierung testen
• POST /api/project/{id}/secret-backends/{backend_id}/resolve — eine Secret-Referenz auflösen (zur Validierung)

Konfiguration #

Neue Konfigurationsoptionen:

Key	Env Var	Default	Beschreibung
secret_cache_ttl	SEMAPHORE_SECRET_CACHE_TTL	5m	Standard-In-Memory-Cache-TTL für aufgelöste externe Secrets
secret_resolve_timeout	SEMAPHORE_SECRET_RESOLVE_TIMEOUT	10s	Maximale Wartezeit auf eine API-Antwort des Cloud-Anbieters beim Auflösen eines Secrets

You might also like