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 zu lesen, um sich mit der gesamten Google Cloud-Landschaft und der Secret Manager-Übersicht vertraut zu machen, 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.
- Segmentieren Sie Anwendungen und Umgebungen (Staging/Produktion) in separate Projekte, wie unter Ressourcenhierarchie für die Google Cloud Landing Zone auswählen beschrieben. Auf diese Weise können Sie Umgebungen mit IAM-Bindungen auf Projektebene isolieren und dafür sorgen, dass Kontingente unabhängig voneinander erzwungen werden.
- 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 Functions 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
Die Übergabe von Secrets an Ihre Anwendung über das Dateisystem oder über die Umgebungsvariablen ist üblich, sollte jedoch aus folgenden Gründen 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 Dokumentation für REST oder gRPC.
Bei einigen Produktintegrationen wie serverlosen Integrationen können Sie Secrets jedoch über das Dateisystem oder über 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, bevor Sie sie löschen oder Secrets löschen. Dies trägt zur Vermeidung von Ausfällen bei, indem das Secret in einen Status versetzt wird, der wie „Löschen“ aussieht, aber umkehrbar ist. Sie können sie also deaktivieren und eine Woche warten, damit Sie sicher sein können, dass keine vorhandenen Abhängigkeiten vorhanden sind, bevor Sie Daten endgültig löschen.
Legen Sie keine expiration 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 erreichen:
- 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.