Sicheres Speichern und Verwalten von API-Keys, Passwörtern, Zertifikaten und anderen sensiblen Daten mit automatischer Verschlüsselung und Versionierung.
Was ist Google Cloud Secret Manager?
Secret Manager ist ein vollständig verwalteter Service zum Speichern und Verwalten sensibler Daten. Anstatt Credentials in Umgebungsvariablen, Config-Dateien oder Source Code zu speichern, zentralisiert Secret Manager alle Secrets mit automatischer Verschlüsselung, Versionierung und Audit-Logging. Der Service integriert sich nahtlos mit Google Cloud Diensten wie Cloud Run, Cloud Functions, GKE und Compute Engine über APIs, Client-Libraries oder direkte Secret-Injection.
Ein zentrales Feature ist die automatische Versionierung. Jede Änderung an einem Secret erstellt eine neue Version, während alte Versionen für Rollbacks erhalten bleiben. Dies ermöglicht sichere Secret-Rotation ohne Downtime: neue Versionen werden deployed, alte Versionen bleiben temporär aktiv für laufende Prozesse, und nach erfolgreicher Migration werden alte Versionen deaktiviert. Audit-Logging über Cloud Audit Logs protokolliert jeden Secret-Access mit Timestamp, User und Service Account für Compliance und Security Monitoring.
Secret Manager bietet flexible Replication-Optionen: Automatic Replication verteilt Secrets über alle Google Cloud Regionen für hohe Verfügbarkeit, während User-Managed Replication explizite Region-Auswahl für Data Residency ermöglicht. IAM-Integration erlaubt granulare Berechtigungen pro Secret oder Secret-Version: ein Service kann nur Lesezugriff auf spezifische Secrets haben, während Secret-Rotation separate Berechtigungen erfordert. Dies implementiert das Principle of Least Privilege auf Secret-Ebene.
Typische Anwendungsfälle
API-Keys für externe Services
Speichern Sie API-Keys für Services wie Stripe, SendGrid, Twilio oder AWS in Secret Manager statt in Environment Variables. Cloud Run oder Cloud Functions können Secrets beim Start laden. Bei Key-Rotation erstellen Sie eine neue Secret-Version, deployen die Anwendung, und deaktivieren die alte Version. Beispiel: Eine E-Commerce-App speichert Stripe API-Keys in Secret Manager, sodass Key-Leaks in Logs oder Git vermieden werden.
Datenbank-Credentials für Cloud SQL
Cloud SQL Proxy nutzt IAM-Authentifizierung, aber für externe Datenbanken oder Legacy-Systeme sind Passwörter notwendig. Secret Manager speichert DB-Credentials sicher. Anwendungen laden Credentials beim Start über die Secret Manager API. Passwort-Rotation erfolgt durch Generierung neuer Credentials in der DB, Update des Secrets und Neustart der Anwendung.
TLS-Zertifikate und Private Keys
Speichern Sie TLS-Zertifikate und Private Keys für Load Balancer, Reverse Proxies oder Custom-Anwendungen. Secret Manager unterstützt Binary-Secrets für Zertifikat-Dateien. Bei Zertifikat-Renewal wird eine neue Secret-Version erstellt. Beispiel: Ein GKE-Ingress lädt TLS-Secrets aus Secret Manager statt aus Kubernetes Secrets für zentralisierte Verwaltung.
Environment Variables für Cloud Run und Cloud Functions
Cloud Run und Cloud Functions können Secrets als Environment Variables oder Volume Mounts einbinden. Volume Mounts sind sicherer, da Secrets nicht in Logs erscheinen. Secrets werden automatisch aktualisiert beim Container-Start, sodass Secret-Rotation ohne Code-Änderungen funktioniert. Beispiel: Eine Cloud Function lädt OAuth-Tokens aus Secret Manager für API-Zugriff.
OAuth-Tokens und Service Account Keys
Speichern Sie OAuth Refresh Tokens, Service Account Keys oder API-Credentials für externe Cloud-Provider. Anwendungen rufen Tokens aus Secret Manager ab statt sie lokal zu speichern. Bei Compromise eines Tokens kann dieser sofort in Secret Manager deaktiviert werden, ohne Code-Deployment.
Best Practices
Nutzen Sie IAM für granulare Zugriffskontrolle
Vergeben Sie Secret Manager Permissions auf Secret-Ebene, nicht auf Projekt-Ebene. Ein Service sollte nur Lesezugriff auf die Secrets haben, die er benötigt. Nutzen Sie Service Accounts mit minimalen Berechtigungen. Beispiel: Eine Cloud Function bekommt “roles/secretmanager.secretAccessor” nur für ihr spezifisches Secret, nicht für alle Secrets im Projekt.
Implementieren Sie Secret-Rotation
Planen Sie Secret-Rotation von Anfang an. Nutzen Sie Cloud Scheduler + Cloud Function für automatische Rotation von DB-Passwörtern oder API-Keys. Best Practice ist 90-Tage-Rotation für kritische Credentials. Alte Versionen sollten nach erfolgreicher Migration deaktiviert, aber nicht sofort gelöscht werden für Rollback-Optionen.
Verwenden Sie User-Managed Replication für Compliance
Für DSGVO oder andere Data-Residency-Anforderungen nutzen Sie User-Managed Replication, um Secrets explizit nur in EU-Regionen zu speichern. Automatic Replication repliziert global, was für manche Compliance-Anforderungen problematisch ist. User-Managed Replication bietet volle Kontrolle über Secret-Locations.
Monitoren Sie Secret-Access mit Audit Logs
Aktivieren Sie Cloud Audit Logs für Secret Manager und setzen Sie Alerts für abnormale Access-Patterns. Unerwartete Secret-Zugriffe von neuen Service Accounts oder aus unbekannten Regionen können auf Compromises hinweisen. Nutzen Sie Log Analytics für Trend-Analysis über Secret-Usage.
Vermeiden Sie Plain-Text-Secrets in Logs
Konfigurieren Sie Applications so, dass Secrets nie in Logs erscheinen. Nutzen Sie Volume Mounts statt Environment Variables für Cloud Run, da Environment Variables in “gcloud run describe” sichtbar sind. Implementieren Sie Secret-Redaction in Application-Logs.
Nutzen Sie Labels für Organization
Taggen Sie Secrets mit Labels wie “env=prod”, “service=api”, “type=db-password”. Dies erleichtert IAM-Policies über Label-Selektoren und ermöglicht Batch-Operationen. Labels helfen auch bei Cost-Tracking und Secret-Inventory-Management.
Google Cloud Secret Manager im Vergleich
vs. AWS Secrets Manager: Beide bieten ähnliche Features (Versionierung, Rotation, Encryption). AWS Secrets Manager hat native Rotation-Support für RDS-Datenbanken, während GCP Rotation manuell implementiert werden muss. Pricing ist ähnlich, AWS berechnet etwas mehr pro Secret. GCP hat einfachere IAM-Integration mit Google Cloud Services.
vs. Azure Key Vault: Key Vault bietet Secrets, Keys und Certificates in einem Service. Secret Manager fokussiert nur auf Secrets, während Key Management Service separate Keys verwaltet. Azure bietet Hardware Security Modules (HSM) für Premium-Tier, GCP nutzt standardmäßig Software-Encryption. Beide erfüllen Enterprise-Compliance-Anforderungen.
vs. HashiCorp Vault: Vault ist selbst-hosted mit mehr Features (Dynamic Secrets, PKI, Encryption-as-a-Service), aber erfordert Cluster-Management. Secret Manager ist vollständig serverless ohne Betriebsaufwand. Vault eignet sich für Multi-Cloud oder On-Premises, Secret Manager für Google Cloud-native Workloads.
Integration mit innFactory
Als Google Cloud Partner unterstützt innFactory Sie bei der Migration von Hard-Coded Secrets zu Secret Manager, der Implementierung von Secret-Rotation-Strategien und der Integration mit CI/CD-Pipelines. Wir helfen bei IAM-Setup, Compliance-Audits und Secret-Lifecycle-Management für Ihre Google Cloud Workloads.
Kontaktieren Sie uns für eine Beratung zu Google Cloud Secret Manager und Security-Best-Practices.
Verfügbare Varianten & Optionen
Standard
- Vollständig verwaltet
- Automatische Replikation
- Audit-Logging integriert
- Kosten pro Secret und Access
- Keine On-Premises-Option
Typische Anwendungsfälle
Technische Spezifikationen
Häufig gestellte Fragen
Was ist Google Cloud Secret Manager?
Secret Manager ist ein vollständig verwalteter Service zum sicheren Speichern, Verwalten und Zugreifen auf sensible Daten wie API-Keys, Passwörter und Zertifikate. Der Service bietet automatische Versionierung, Audit-Logging und Integration mit Google Cloud IAM für granulare Zugriffskontrollen.
Wie unterscheidet sich Secret Manager von Environment Variables?
Environment Variables sind in Plain-Text gespeichert und in Logs sichtbar. Secret Manager verschlüsselt Secrets automatisch, bietet Versionierung, Audit-Trails und granulare Berechtigungen. Secrets können zentral rotiert werden, ohne Anwendungen neu zu deployen. Für Produktionsumgebungen ist Secret Manager der sichere Standard.
Wie funktioniert Secret-Versionierung?
Jede Änderung an einem Secret erstellt eine neue Version. Alte Versionen bleiben verfügbar für Rollbacks. Anwendungen können auf spezifische Versionen oder "latest" zugreifen. Deaktivierte Versionen können nicht mehr abgerufen werden, bleiben aber für Audit-Zwecke erhalten.
Was kostet Secret Manager?
Secret Manager berechnet pro aktivem Secret-Version (ca. 0,06 USD pro Monat) und pro 10.000 Access-Operationen (ca. 0,03 USD). Ein Secret mit 5 aktiven Versionen kostet also etwa 0,30 USD pro Monat. Deleted Secrets werden nach 30 Tagen automatisch gelöscht und verursachen dann keine Kosten mehr.
Wie rotiere ich Secrets automatisch?
Secret Manager selbst rotiert Secrets nicht automatisch. Sie müssen Rotation über Cloud Functions, Cloud Scheduler oder externe Tools implementieren. Best Practice ist ein Cloud Scheduler Job, der periodisch neue Secrets generiert, in Secret Manager speichert und die alten Versionen deaktiviert.
Kann ich Secrets zwischen Regionen replizieren?
Ja, Secret Manager bietet automatische Replikation (über alle Regionen) oder User-Managed Replication (explizite Regions-Auswahl). User-Managed Replication ermöglicht Data Residency für Compliance. Automatische Replikation ist einfacher, User-Managed bietet mehr Kontrolle.
Wie integriere ich Secret Manager mit Cloud Run?
Cloud Run kann Secrets als Environment Variables oder als Volume Mounts einbinden. Volume Mounts sind sicherer, da Secrets nicht in Logs erscheinen. Definieren Sie Secrets im Cloud Run Service YAML oder in der Console, und Secret Manager liefert die aktuellen Werte beim Container-Start.
Was sind Best Practices für Secret Naming?
Nutzen Sie konsistente Naming Conventions wie "project-env-service-secrettype" (z.B. "myapp-prod-api-stripe-key"). Vermeiden Sie sensible Informationen im Secret-Namen selbst. Nutzen Sie Labels für Kategorisierung (env=prod, service=api). Dies erleichtert IAM-Policies und Auditing.
Ist Secret Manager DSGVO-konform?
Ja, Secret Manager ist in EU-Regionen verfügbar und erfüllt alle DSGVO-Anforderungen. Mit User-Managed Replication können Sie sicherstellen, dass Secrets nur in EU-Regionen gespeichert werden. Google Cloud bietet umfassende Datenschutzkontrollen und Compliance-Zertifizierungen.
