Tresorstruktur für DevOps
Warum Struktur für die Automatisierung wichtig ist
Wenn ein Mensch Passwork verwendet, kann er nach Namen suchen und visuell navigieren. Automatisierung kann das nicht. Eine CI/CD-Pipeline oder ein Skript muss Secrets über einen vorhersehbaren Identifikator abrufen — eine Ordner-ID oder Tresor-ID — und erwartet, dass sich alle benötigten Secrets an diesem Ort befinden.
Eine gut gestaltete Struktur bedeutet:
- Ein einzelnes
--folder-idruft alle Secrets ab, die eine Pipeline benötigt, ohne manuelles Zusammenstellen - Das Hinzufügen eines neuen Secrets zu einer Pipeline erfordert nur das Hinzufügen eines Datensatzes zum richtigen Ordner — keine Codeänderung
- Die Zugriffskontrolle bildet die Teamgrenzen sauber ab
Empfohlene Hierarchie
Organisieren Sie Infrastruktur-Secrets zuerst nach Umgebung, dann nach Diensttyp:
Infrastructure (vault)
├── production/
│ ├── databases/
│ │ ├── postgres-order-service
│ │ ├── postgres-analytics
│ │ └── redis-sessions
│ ├── cloud/
│ │ ├── aws-credentials
│ │ └── gcp-service-account
│ ├── message-brokers/
│ │ └── rabbitmq-backend
│ └── external-apis/
│ ├── stripe-secret-key
│ └── twilio-auth-token
├── staging/
│ ├── databases/
│ ├── cloud/
│ └── external-apis/
└── development/
├── databases/
└── local/
Dieses Layout bedeutet:
- Eine Produktions-Deploy-Pipeline verwendet
--folder-id <production folder ID>, um alle Produktions-Secrets zu erhalten - Die Zugriffskontrolle erfolgt pro Umgebung: der Account
svc-deploy-staginghat nur Lesezugriff aufstaging/, nicht aufproduction/ - Ein Skript auf dem Laptop eines Entwicklers verwendet
--folder-id <development folder ID>, ohne die Produktion zu berühren
Namenskonventionen
Verwenden Sie Namen, die beschreibend und maschinenlesbar sind. Wenn passwork-cli exec Secrets in Umgebungsvariablen einschleust, verwendet es den Elementnamen (und die Namen der benutzerdefinierten Felder) als Variablennamen, wobei Leerzeichen und Sonderzeichen zu Unterstrichen normalisiert werden.
| Elementname | Eingeschleuste Variable |
|---|---|
POSTGRES_PASSWORD | POSTGRES_PASSWORD |
postgres order service | POSTGRES_ORDER_SERVICE |
AWS_SECRET_ACCESS_KEY | AWS_SECRET_ACCESS_KEY |
Stripe Secret Key | STRIPE_SECRET_KEY |
Empfohlenes Muster: verwenden Sie SCREAMING_SNAKE_CASE für Infrastruktur-Elemente, die als Umgebungsvariablen eingeschleust werden. Dies macht die Zuordnung explizit und vermeidet Überraschungen.
Was in welches Feld gehört
Passwork-Passwortdatensätze verfügen über mehrere Felder. Verwenden Sie sie gezielt:
| Feld | Was gespeichert werden soll |
|---|---|
| Login | Benutzername, Name des Service-Accounts, Key-ID (z. B. AKIAIOSFODNN7EXAMPLE) |
| Passwort | Der primäre Secret-Wert (Passwort, Token, privater Schlüssel) |
| URL | Dienst-Endpunkt oder Konsolen-URL (nützlich als menschliche Referenz) |
| Benutzerdefinierte Felder | Benannte zusätzliche Secrets: AWS_SECRET_ACCESS_KEY, DB_HOST, DB_PORT, Verbindungszeichenfolgen |
| Beschreibung | Konfigurationshinweise, Rotationsprozedur, verantwortliches Team |
| Tags | Umgebung, Diensttyp (production, k8s, db) |
Datensätze mit mehreren Secrets
Wenn ein Dienst mehrere zusammengehörige Anmeldedaten benötigt, speichern Sie sie in einem Datensatz mithilfe benutzerdefinierter Felder:
Record: "AWS production credentials"
Login: AKIAIOSFODNN7EXAMPLE
Password: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Custom fields:
AWS_REGION: eu-central-1
S3_BUCKET: company-backups-prod
ROLE_ARN: arn:aws:iam::123456789:role/deploy-role
passwork-cli exec --password-id <id> schleust all diese als separate Umgebungsvariablen ein.
Speichern von SSH-Schlüsseln und Zertifikaten
Verwenden Sie für mehrzeilige Secrets (private SSH-Schlüssel, TLS-Zertifikate, kubeconfig-Dateien) ein benutzerdefiniertes Feld mit dem vollständigen Inhalt. Die CLI verarbeitet mehrzeilige Werte korrekt. Alternativ können Sie Anhänge für Binärdateien verwenden.
TOTP-Codes
Wenn ein Service-Account 2FA erfordert, kann Passwork TOTP-Codes generieren. Fügen Sie ein benutzerdefiniertes Feld vom Typ TOTP hinzu und fügen Sie den Authenticator-Seed ein. Die CLI und das Python SDK können den aktuellen TOTP-Code programmatisch abrufen.
Tags zur Umgebungsfilterung
Wenden Sie Tags auf jeden Infrastruktur-Datensatz an:
- Umgebungs-Tag:
production,staging,development - Diensttyp-Tag:
db,cloud,k8s,messaging,external-api - Status-Tag:
active,deprecated,rotation-pending
passwork-cli exec --tags "production,db" ruft alle Datensätze ab, die beiden Tags entsprechen. Dies ist nützlich für Skripte, die über mehrere Dienste desselben Typs hinweg operieren.
CSE-Überlegungen
Wenn die client-seitige Verschlüsselung aktiviert ist:
- Das Passwortfeld und die Werte der benutzerdefinierten Felder werden vor der Speicherung auf dem Client verschlüsselt
- Der Elementname, das Login, die URL, die Tags und die Beschreibung werden NICHT auf dem Client verschlüsselt — sie sind auf dem Server durchsuchbar
Das bedeutet, dass Sie keine sensiblen Daten in den Elementnamen, die Beschreibung oder die Tags eintragen sollten. Bewahren Sie Secrets im Passwort- und in den benutzerdefinierten Feldern auf.
Die CLI und das Python SDK verarbeiten CSE transparent, wenn PASSWORK_MASTER_KEY gesetzt ist. Beim Wechsel zwischen Passwork-Instanzen mit aktiviertem und deaktiviertem CSE sind keine Codeänderungen erforderlich — es ändert sich nur das Vorhandensein oder Fehlen des Master-Key-Parameters.
Infrastruktur-Tresore von Business-Tresoren trennen
Bewahren Sie Infrastruktur-Secrets in einem dedizierten Tresor auf (z. B. Infrastructure oder DevOps). Vermischen Sie sie nicht mit Business-Anmeldedaten (CRM-Logins, Marketing-Tools). Dies macht:
- Die Zugriffskontrolle sauberer: geben Sie CI/CD-Service-Accounts nur Zugriff auf den Infrastruktur-Tresor
- Sicherheitsüberprüfungen einfacher: das Sicherheitsteam weiß genau, wo es nach privilegierten Anmeldedaten suchen muss
- Den Rotationsumfang klarer: Infrastruktur-Rotationsskripte operieren auf einem bekannten Tresor
Best Practices für das Secret-Management finden Sie unter Secret-Management: Konzepte.