In dieser Anleitung werden einige Best Practices für die Verwendung von Secret Manager vorgestellt. Der Leitfaden ist nicht als abschließende Liste von Empfehlungen zu betrachten. Wir empfehlen Ihnen, die Plattformübersicht zum Verständnis der allgemeinen Google Cloud-Landschaft sowie die Secret Manager-Übersicht zu lesen, bevor Sie diesen Leitfaden lesen.
Zugriffssteuerung
Der Zugriff auf die Secret Manager API ist durch IAM geschützt. Beachten Sie beim Gewähren von Berechtigungen für Secrets das Prinzip der geringsten Berechtigung.
- Beschränken Sie die Inhaberschaft der Organisation auf ein gesichertes Super Admin-Konto.
- Anwendungen und Umgebungen (Staging/Produktion) in separate wie unter Ressourcenhierarchie für Ihr Projekt festlegen Google Cloud Landing Zone. Dies kann helfen, die mit IAM-Bindung auf Projektebene und stellt sicher, Kontingente werden unabhängig durchgesetzt.
- Wählen Sie eine vorkonfigurierte Rolle mit den minimal erforderlichen Berechtigungen aus oder erstellen Sie bei Bedarf eine benutzerdefinierte Rolle.
- Wenn sich Secrets für viele Dienste in einem einzelnen Projekt befinden, verwenden Sie IAM-Bindungen auf Secret-Ebene oder IAM-Bedingungen, um den Zugriff auf die erforderliche Teilmenge von Secrets einzuschränken.
- IAM Recommender kann bei der Identifizierung IAM-Bindungen mit übermäßigen Berechtigungen helfen.
Für die Authentifizierung bei der Secret Manager API sind Anmeldedaten erforderlich. Die Clientbibliotheken verfolgen alle eine ähnliche Strategie, um nach Anmeldedaten zu suchen, die als Standardanmeldedaten für Anwendungen bezeichnet werden.
- Verwenden Sie für eine lokale Entwicklung
gcloud auth application-default login. Dadurch wird eine Datei mit Anmeldedaten erstellt, die automatisch von Clientbibliotheken übernommen werden. - In Compute Engine und anderen Google Cloud-Computing-Plattformen wie Cloud Run-Funktionen erhalten die Clientbibliotheken Anmeldedaten über den Instanzmetadatenserver.
- In GKE stellt Workload Identity auch Anmeldedaten über einen Metadatendienst bereit.
- Auf anderen Plattformen wie Amazon Web Services oder Microsoft Azure sollten Sie die Workload Identity-Föderation einrichten, die vorhandene Identitätsmechanismen verwendet, um sich bei Google Cloud APIs zu authentifizieren.
Alle diese Methoden werden dem Export von Anmeldedaten für Dienstkonten vorgezogen, da sie keine sichere Speicherung und den Zugriff auf ein zusätzliches Secret außerhalb der Secret Manager API erfordern.
Coding-Praktiken
Secrets über das Dateisystem oder die Umgebung an Ihre Anwendung übergeben Variablen sind üblich, sollten jedoch aus folgenden Gründen nach Möglichkeit vermieden werden:
- Wenn im Dateisystem auf ein Secret zugegriffen werden kann, können Sicherheitslücken in Anwendungen durch Directory-Traversal-Angriffe einen höheren Schweregrad bekommen, da der Angreifer möglicherweise das Secret-Material lesen kann.
- Wenn ein Secret über Umgebungsvariablen genutzt wird, können Fehlkonfigurationen wie das Aktivieren von Debug-Endpunkten oder das Einbeziehen von Abhängigkeiten, die Logprozess-Umgebungsdetails protokollieren, Secrets offenlegen.
- Berücksichtigen Sie beim Synchronisieren von Secret-Material mit einem anderen Datenspeicher (z. B. Kubernetes Secrets) die Zugriffssteuerungen dieses Datenspeichers. Beispiel:
- Erweitert der Datenspeicher den Zugriff des Secrets?
- Ist es möglich, den Zugriff des Secrets zu prüfen?
- Entspricht der Datenspeicher Ihren Anforderungen hinsichtlich der Verschlüsselung ruhender Daten und der Regionalisierung?
Wir empfehlen, die Secret Manager API direkt zu verwenden. Verwenden Sie dazu eine der bereitgestellten Clientbibliotheken oder folgen Sie der REST- oder GRPC-Dokumentation.
Bei einigen Produktintegrationen, z. B. bei serverlosen Integrationen, können Sie über das Dateisystem oder die Umgebungsvariablen übergeben. Weitere Informationen finden Sie unter Secret Manager mit anderen Produkten verwenden.
Verwaltung
Wählen Sie beim Erstellen von Secrets die Richtlinie für die automatische Replikation aus, es sei denn, Ihre Arbeitslast hat bestimmte Standortanforderungen (durchsetzbar mit der Einschränkung constraints/gcp.resourceLocations).
Verweisen Sie auf Secrets über ihre Versionsnummer, anstatt den neuesten Alias zu verwenden. Stellen Sie mithilfe der vorhandenen Releaseprozesse Aktualisierungen von Versionsnummern bereit. Dies bedeutet in der Regel, dass Sie Ihre Anwendung mit einer bestimmten Secret-Version konfigurieren, die beim Start gelesen wird. Die Verwendung des neuesten Alias kann zwar praktisch sein, aber wenn ein Problem mit der neuen Version des Secrets auftritt, kann die Arbeitslast die Secret-Version möglicherweise nicht verwenden. Durch das Anpinnen an eine Versionsnummer kann die Konfiguration validiert und mit den vorhandenen Releaseprozessen ein Rollback durchgeführt werden.
Deaktivieren Sie Secret-Versionen vor dem Zerstören oder Löschen von Secrets Dadurch werden Ausfälle vermieden, in einem Zustand, der wie Zerstören aussieht, aber umkehrbar ist. Das heißt: können Sie eine Woche warten, um sicherzustellen, Abhängigkeiten, bevor Daten endgültig gelöscht werden.
Legen Sie keine Ablaufzeit für Produktions-Secrets fest, es sei denn, Sie sind sicher, dass sie unwiderruflich gelöscht werden sollen. Das Ablauffeature eignet sich am besten für die automatische Bereinigung temporärer Umgebungen. Als Alternative zu ablaufenden Secrets sollten Sie zeitbasierte IAM-Bedingungen in Betracht ziehen.
Rotieren Sie Ihre Secrets regelmäßig, um Folgendes zu tun:
- Auswirkungen im Fall eines gehackten Secrets begrenzen
- Sicherstellen, dass Personen, die keinen Zugriff mehr auf ein Secret benötigen, ein zuvor aufgerufenes Secret nicht mehr verwenden können
- Kontinuierlich den Rotationsworkflow ausführen, um die Wahrscheinlichkeit eines Ausfalls zu reduzieren
Überwachen Sie Secrets in Ihrer Organisation mithilfe von Cloud Asset Inventory, um Folgendes zu erreichen:
- Secrets in Ihrer Organisation identifizieren
- Nichtkonformität mit Organisationsanforderungen wie Rotation, Verschlüsselungskonfiguration und Standort identifizieren
Aktivieren Sie Datenzugriffslogs, um AccessSecretVersion-Anfrageinformationen abzurufen und zu analysieren. Aktivieren Sie diese Option auf Ordner- oder Organisationsebene, um das Logging zu erzwingen, ohne sie für jedes Secret oder Projekt konfigurieren zu müssen.
Zusätzlich zu IAM-Steuerungen können Sie den Zugriff auf die Secret Manager API mit netzwerkbasierten Steuerungen beschränken, indem Sie einen VPC Service Controls-Perimeter für Ihre Organisation einrichten.
Mit der Organisationsrichtlinie constraints/iam.allowedPolicyMemberDomains können Sie die Identitäten begrenzen, die den IAM-Richtlinien für Secrets hinzugefügt werden können.
Kalkulieren Sie die maximale Nutzung von Secrets (berücksichtigen Sie dabei eine Thundering Herd von Anfragen aufgrund von gleichzeitigen Bereitstellungen von Anwendungen oder des Autoscaling Ihres Dienstes) und stellen Sie sicher, dass Ihr Projekt ein ausreichendes Kontingent zur Verarbeitung eines solchen Ereignisses hat. Fordern Sie ggf. eine Erhöhung des Kontingents an.