Auf dieser Seite finden Sie Best Practices zum Erstellen einer mandantenfähigen Architektur zum Hosten von nicht vertrauenswürdigem Code mit Cloud Run. Für Sie als Kunde von Google Cloud ist ein „Mandant“ einer Ihrer eigenen Kunden und „nicht vertrauenswürdiger Code“ ist Code, der von diesen Mandanten bereitgestellt wird, um auf Ihrer Plattform ausgeführt zu werden.
Anwendungsfälle
Zu den Anwendungsfällen für solche Architekturen gehören:
- App-Hosting-Plattformen: Sie stellen eine Plattform bereit, auf der Ihre Kunden ihren Code bereitstellen. Beispiel: Eine Webhosting-Plattform (Kunden stellen einen Webserver bereit) oder eine Functions-as-a-Service-Plattform (Kunden stellen eine Funktion bereit).
- Agent-Hosting-Plattformen: Ihre Kunden verwenden SDKs, um KI-Agenten zu erstellen, und Ihre Plattform führt sie im Hintergrund aus.
- Plattformen für optimierte Modelle: Sie bieten die Möglichkeit, KI-Modelle für jeden Kunden individuell anzupassen. Ihre Plattform führt sie dann bei Bedarf mit GPUs aus.
- Benutzerdefinierte Funktionen: Ihre Software ermöglicht es Kunden, benutzerdefinierte Logik mithilfe von Code zu definieren. Beispiel: Sie stellen eine Analyse-Engine bereit und möchten Kunden die Möglichkeit geben, benutzerdefinierte Funktionen zu schreiben. Oder Sie stellen ein API-Gateway bereit und möchten Kunden die Möglichkeit geben, Anfragen basierend auf ihrer eigenen benutzerdefinierten Logik zu filtern oder zu mutieren.
- Erweiterbarkeit von Software-as-a-Service (SaaS): Sie bieten möglicherweise eine SaaS-Lösung an und möchten Kunden die Möglichkeit geben, die Funktionen mithilfe von Erweiterungen zu erweitern. Diese Erweiterungen können von Kunden oder Partnern geschrieben werden.
Google Cloud -Kunden verwenden Cloud Run erfolgreich in der Produktion für diese Anwendungsfälle.
Herausforderungen von mehrmandantenfähigen Plattformen
Zu den typischen Herausforderungen beim Erstellen einer solchen Architektur gehören:
- Sicherheit: Es ist nicht möglich, den bereitgestellten Code zu scannen oder zu bereinigen. Nicht vertrauenswürdiger Code kann schädliche Aktionen oder anfällige Abhängigkeiten enthalten. Wenn nicht vertrauenswürdiger Code nicht ordnungsgemäß isoliert wird, kann er möglicherweise auf vertrauliche Daten anderer Mandanten zugreifen. Das einfache Verpacken des Codes in einem Container ist keine ausreichend starke Sicherheitsgrenze. Außerdem muss der Code durch Anwendung des Prinzips der geringsten Berechtigung eingeschränkt werden.
- Kosteneffizienz: Eine solche Architektur kann teuer werden, wenn für jeden Mandanten Fixkosten für Ihre Plattform anfallen.
- Mandantenverwaltung: Die Verwaltung von Hunderttausenden von Mandanten kann eine Herausforderung sein, insbesondere beim Löschen von Daten.
Vorteile von Cloud Run
Eine Cloud Run-basierte Architektur bietet eine Lösung für gängige Herausforderungen mit vielen Vorteilen, z. B. Sicherheit, Kosteneffizienz und Mandantenverwaltung.
Sicherheit
Cloud Run bietet die für diese Architektur relevanten Standard-Sicherheitsfunktionen:
- Computing-Isolation: Cloud Run sorgt für eine strikte Isolation zwischen Containerinstanzen, unabhängig davon, ob sie zum selben Dienst oder zu verschiedenen Diensten aus unterschiedlichen Projekten gehören. Weitere Informationen zur Containersicherheit und zu Ausführungsumgebungen finden Sie unter Sicherheitsdesign – Übersicht.
- Sicherheitsupdates: Automatische Sicherheitsupdates von Basis-Images können aktiviert werden, um das Betriebssystem und die Laufzeit der bereitgestellten Arbeitslasten auf dem neuesten Stand zu halten und zu patchen, ohne dass umfangreiche erneute Bereitstellungen erforderlich sind.
- Netzwerkisolation: Cloud Run führt nicht nur die Container in einer Sandbox aus, sondern bietet auch einen mandantenfähigen Netzwerkstack.
- Dienstidentität: Cloud Run-Arbeitslasten können so konfiguriert werden, dass sie dedizierte Identitäten mit eingeschränkten Berechtigungen haben.
Kosteneffizienz
- Skalierung auf null und nutzungsbasierte Bezahlung: Cloud Run-Instanzen werden automatisch auf null skaliert, wenn sie nicht verwendet werden. So werden gehostete Arbeitslasten nur dann in Rechnung gestellt, wenn sie ausgeführt werden müssen. Dies führt zu einer sehr effizienten Ressourcennutzung im Vergleich zu Architekturen, die „Always-on“-VMs nutzen.
- Abrechnung pro Anfrage: Neben der Skalierung auf null können Sie von einem noch detaillierteren Abrechnungsmodell profitieren, bei dem nur dann Kosten anfallen, wenn Anfragen verarbeitet werden. Das sorgt für eine noch höhere Kosteneffizienz.
- On-Demand und schneller Start: Wenn Cloud Run-Dienste herunterskaliert werden, können sie schnell wieder hochskaliert werden. Dadurch entsteht für den Endnutzer der bereitgestellten Anwendung nur eine geringe Latenz.
- Automatisierte Kostenkennzeichnung: Alle von Cloud Run gemeldeten Kosten werden mit Labels versehen, sodass Sie die Kostenzuordnung und das Tracking Ihrer Mandanten automatisieren können.
- Zusicherungen zur Senkung der Gesamtkosten: Auf Rechnungskontoebene können Sie flexible Rabatte für zugesicherte Nutzung verwenden, um die Ausgaben für die grundlegende Cloud Run-Nutzung zu optimieren.
Mandantenverwaltung
Aufgrund der On-Demand-Natur sind die Cloud Run-Kosten bei Verwendung mehrerer Google Cloud -Projekte nicht höher. Dies ermöglicht die Mandantenverwaltung, wie unter Google Cloud -Projekte organisieren beschrieben.
Zielarchitektur für mehrmandantenfähige Plattformen
Hier ist die empfohlene Architektur auf übergeordneter Ebene:
Google Cloud -Projekte organisieren
Sie müssen eine Google Cloud -Organisation und die Offlineabrechnung einrichten und Ihr Account-Management-Team darüber informieren, dass Sie als Reseller-Konto agieren.Google Cloud arbeitet möglicherweise mit Ihnen zusammen, um sicherzustellen, dass geeignete Kommunikationskanäle zur Missbrauchsminderung eingerichtet werden.
Sie müssen Ordner verwenden, um Ihre Google Cloud -Projekte zu organisieren. Insbesondere ist es wichtig, dass Sie die Projekte, in denen Ihr eigener Code ausgeführt wird, in anderen Ordnern ablegen als die Projekte, in denen nicht vertrauenswürdiger Code Ihrer Mandanten ausgeführt wird. Sie müssen das Onboarding von Mandanten automatisieren, damit für die Erstellung der Projekte und Ressourcen eines Mandanten kein Human in the Loop erforderlich ist.
Google empfiehlt, ein Google Cloud -Projekt pro Mandant zu verwenden. Es ist auch möglich, mehrere Mandanten im selben Projekt zu hosten. Dies ist jedoch mit zusätzlichen Einschränkungen verbunden:
Einzelner Mandant pro Google Cloud Projekt (empfohlen)
In dieser Architektur wird jeder Mandant Ihrer Plattform in einem dediziertenGoogle Cloud -Projekt gehostet, was viele Vorteile hat:
- Einfachere Sicherheit: Das Projekt Google Cloud ist eine strikte Grenze für alle darin enthaltenen Ressourcen. Wenn ein Mandant Zugriff auf mehrereGoogle Cloud -Ressourcen wie mehrere Cloud Run-Dienste oder einen Cloud Storage-Bucket benötigt, können Sie das Projekt als sicheren Perimeter verwenden.
- Weniger eingeschränkt:
- Die Anzahl der Ressourcen in einem bestimmten Projekt ist begrenzt. In Cloud Run können beispielsweise nur 1.000 Dienste pro Region in einem Projekt erstellt werden. Für die Anzahl der Dienstkonten und anderer zugehöriger Ressourcen gelten ähnliche Limits.
- Die Anzahl der Projekte ist selbst ein Kontingent und kann erhöht werden. Für eine Google Cloud -Organisation gibt es keine Beschränkungen für diese Anzahl. Es gibt ein weiches Limit von 100.000 Projekten pro Rechnungskonto, das nach Rücksprache mit Google erhöht werden kann. Ihre Organisation kann auch mehrere Rechnungskonten erstellen und in einer „Kontogruppe“ gruppieren (derzeit in der privaten Vorschau).
- Einfacheres Monitoring und einfachere Verwaltung:
- Die Verwendung eines Projekts pro Mandant führt zu einfacheren Datenlöschprozessen, bei denen das Löschen von Daten für einen Mandanten auf das Löschen des entsprechenden Projekts hinausläuft.
- Google Cloud Monitoring und Logging funktionieren projektübergreifend und ermöglichen es Ihnen, Ihre gesamte Flotte zu überwachen.
- Mit Kontingenten auf Projektebene können Sie die Cloud Run-Ressourcenauslastung für einen bestimmten Mandanten begrenzen und die Limits möglicherweise an Ihre eigenen Preisstufen anpassen.
- Mit benutzerdefinierten Organisationsrichtlinien können Sie auf alle Projekte eines Ordners bestimmte Einschränkungen anwenden, z. B. verfügbare Regionen oder maximale CPU-/Arbeitsspeicherzuweisung.
Das Erstellen eines Google Cloud -Projekts und das Initialisieren von APIs und Ressourcen kann zu Latenz führen. Google empfiehlt, einen Pool von vorab erstellten Projekten zu verwenden, die Sie Ihren Mandanten bei Bedarf zuweisen.
Mehrere Mandanten pro Google Cloud -Projekt (nicht empfohlen)
Es ist möglich, mehrere Mandanten im selben Google Cloud-Projekt zu hosten. Google empfiehlt diese Architektur jedoch nicht.
Viele Google Cloud -Dienste haben Ressourcenlimits pro Projekt. Cloud Run hat beispielsweise ein nicht anpassbares Limit von 1.000 Cloud Run-Diensten pro Region in einem Projekt. Wenn Sie mehrere Mandanten pro Projekt hosten, müssen Sie also weiterhin eine Flotte von Google Cloud -Projekten verwalten, was die Komplexität der Mandantenverwaltung insgesamt erhöht. Aus Sicherheitssicht sindGoogle Cloud -Projekte als Sicherheitsgrenze konzipiert. Wenn Sie zwei verschiedene Mandanten in denselben Projekten hosten, müssen Sie in Bezug auf die Sicherheit vorsichtiger sein. Beispielsweise durch die Verwendung dedizierter Dienstkonten und detaillierter Berechtigungen.
In vielen Regionen bereitstellen
Aus Gründen der Zuverlässigkeit und Skalierbarkeit empfiehlt Google, Mandantenbereitstellungen auf mehrere Google Cloud -Regionen zu verteilen. Jede Mandantenanwendung wird in einer einzelnen Region bereitgestellt. Sie können jedoch verschiedene Regionen für verschiedene Mandanten verwenden. Die Auswahl der Region kann zufällig sein oder den Standort des Mandanten berücksichtigen, um die Latenz zu optimieren.
Anfrage-Routing und benutzerdefinierte Domains
Wenn Sie die Cloud Run-Dienste Ihres Mandanten für Endnutzer verfügbar machen möchten, müssen Sie Ihre eigene Domain hinzufügen und Ihre eigene Routinglogik verwenden. Beispiel: Um eine Subdomain dem Projekt Google Cloud zuzuordnen, das den Dienst des Mandanten hostet.
Sie können einen eigenen Routingdienst implementieren. Google empfiehlt jedoch, einen globalen externen Application Load Balancer mit Service Extensions für die Routinglogik zu verwenden. Diensterweiterungen können als Plug-ins (bei denen die Logik inline mit der Anfrageverarbeitung ausgeführt wird) oder als Callouts (die Routinglogik wird an einen separaten Cloud Run-Dienst delegiert, der eine der skalierbaren multiregionalen Datenbanken vonGoogle Cloudwie Spanner aufrufen kann) implementiert werden.
Mit einem Application Load Balancer können Sie auch eine Caching-Ebene hinzufügen, indem Sie Cloud CDN und zusätzlichen Schutz vor DDoS-Angriffen (Distributed Denial of Service) für Ihre Plattform mit Cloud Armor nutzen.
Bewertung und Missbrauch
Jede Hostingplattform, auf der nicht vertrauenswürdiger Code ausgeführt werden darf, ist anfällig für Missbrauch.
Wir empfehlen, für jede von Ihnen angebotene Reputationsstufe ein anderes Cloud-Rechnungskonto zu verwenden. Beispielsweise sollten Ihre Mandanten der kostenlosen Stufe nicht mit demselben Rechnungskonto verknüpft sein wie Ihre zahlenden Kunden. Google kann diese Rechnungskonten auf verschiedenen Reputationsstufen berücksichtigen.
Wie unter Google Cloud -Projekte organisieren beschrieben, sollten Sie Projekte nicht nur nach Rechnungskonten trennen, sondern auch mithilfe von Ordnern organisieren. Google kann Ihnen dabei helfen, Kontingente auf Ordnerebene festzulegen, damit alle Ressourcen in einem Ordner nie mehr als ein festgelegtes Maximum verbrauchen. So können Sie die Kosten Ihrer Plattform besser verwalten.
Standardmäßig entfernt Google missbräuchliche Arbeitslasten gemäß den Nutzungsbedingungen vonGoogle Cloud automatisch. Google kann auch Ereignisse zur Missbrauchserkennung in Cloud Logging protokollieren, auf die Sie dann reagieren können.