Studio Mitte: Mit 1Password CLI und DDEV keine geheimen Umgebungsvariablen mehr im Dateisystem

Eine .env-Datei ist oft nur ein git add . davon entfernt, Datenbank-Passwörter preiszugeben.
Klassische .env-Dateien landen schnell in Backups, Screenshots, IDE-Indizes oder versehentlich in Git-Repositories – selbst wenn sie eigentlich nie geteilt werden sollten.
Die 1Password CLI löst dieses Problem ohne zusätzliche Infrastruktur. Durch das Ersetzen von Zugangsdaten mit Referenzen injiziert op run die echten Geheimnisse erst beim Container-Start. Auf diese Weise werden sensible Daten niemals als Klartext-Dateien im Repository oder lokalen Projektordner liegen.

Voraussetzungen

Ein 1Password-Konto (Einzelpersonen oder Teams)
Installierte 1Password CLI
Ein DDEV-Projekt mit Zugangsdaten in einer .env-Datei

1Password CLI verbinden

Konto hinzufügen und anmelden:


				
					op account add
				
					eval $(op signin)

eval $(op signin) setzt Sitzungs-Token in der aktuellen Shell. Dies muss pro Sitzung einmal ausgeführt werden, sofern keine biometrische Entsperrung für die automatische Authentifizierung konfiguriert ist.

Geheimnis-Referenzen finden

1Password-Referenzen verwenden das Format op://vault-name/item-name/field-name. Um die genauen Feldnamen für ein Element zu ermitteln, kann es als JSON abgerufen werden:


				
					op item get "My Database" --format json

Der reference-Schlüssel innerhalb jedes Feld-Objekts liefert den exakten String zum Kopieren. Alternativ kann in der 1Password-Desktop-App per Rechtsklick auf ein beliebiges Feld die Geheimnis-Referenz direkt kopiert werden.

Werte in der .env ersetzen

Die Werte der Zugangsdaten werden gegen die entsprechenden op://-Referenzen ausgetauscht:


				
					# vorher
				
					DB_PASSWORD=supersecret123
				
					STRIPE_SECRET=sk-live-abcdef123456
				
					SMTP_PASSWORD=mailpassword  
				
					
				
					# nachher
				
					DB_PASSWORD="op://Private/My Database/password" 
				
					STRIPE_SECRET="op://Private/Stripe/secret key"  
				
					SMTP_PASSWORD="op://Private/Mailgun/password"

Die .env kann nun sicher committet oder synchronisiert werden, sie enthält lediglich Pfade, keine Geheimnisse.

DDEV anweisen, injizierte Variablen zu akzeptieren

DDEV leitet Umgebungsvariablen des Hosts nicht automatisch an den Web-Container weiter. Dadurch wird verhindert, dass unbeabsichtigt sensible oder systembezogene Variablen in den Container gelangen. Jeder Variablenname muss daher zu web_environment in der Datei .ddev/config.yaml hinzugefügt werden:


				
					web_environment:
				
					  - DB_PASSWORD
				
					  - STRIPE_SECRET
				
					  - SMTP_PASSWORD

Ohne diesen Schritt werden die Geheimnisse zwar im Host-Prozess durch op run aufgelöst, erreichen aber niemals den Container.

DDEV mit aufgelösten Geheimnissen starten


				
					op run --env-file=".env" -- ddev start

op run liest die .env-Datei, löst jede op://-Referenz gegenüber 1Password auf, injiziert die echten Werte in die Prozessumgebung und übergibt die Kontrolle an ddev start. Die Geheimnisse existieren nur im Arbeitsspeicher dieses Prozesses und werden niemals permanent gespeichert.

Fazit und Trade-offs

Der größte Vorteil besteht in der Sicherheit durch Design, ohne lokale Entwicklungsworkflows komplizierter zu machen. Selbst bei einem Diebstahl der Hardware oder einem versehentlichen Upload des Projektverzeichnisses sind keine Zugangsdaten gefährdet. Statt zusätzliche Secret-Management-Infrastruktur zu betreiben, nutzt der Workflow bestehende 1Password-Vaults und integriert sich direkt in DDEV.

Ein wesentlicher Aspekt: Alle Personen, die am Projekt arbeiten, benötigen die 1Password CLI sowie Zugriff auf den entsprechenden Vault. Für Einzelentwickler ist dies kein Mehraufwand; in Teams sollte sichergestellt sein, dass die relevanten Items in einem geteilten Vault liegen.