Auf dieser Seite finden Sie Best Practices zum Erstellen einer Mandantenarchitektur zum Hosten nicht vertrauenswürdigen Codes mit Cloud Run. Als Google Cloud -Kunde wird ein „Mandant“ als einer Ihrer eigenen Kunden definiert und „nicht vertrauenswürdiger Code“ als Code, der von diesen Mandanten bereitgestellt wird, um auf Ihrer Plattform ausgeführt zu werden.
Anwendungsfälle
Anwendungsfälle für solche Architekturen:
- App-Hosting-Plattformen: Sie stellen eine Plattform bereit, auf der Ihre Kunden ihren Code bereitstellen. Beispiele sind eine Webhostingplattform (Kunden stellen einen Webserver bereit) oder eine Functions-as-a-Service-Plattform (Kunden stellen eine Funktion bereit).
- Plattformen für das Hosten von Agents: Ihre Kunden verwenden SDKs, um KI-Agents zu erstellen, die auf Ihrer Plattform im Hintergrund ausgeführt werden.
- 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. Sie stellen beispielsweise 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 anhand ihrer eigenen benutzerdefinierten Logik zu filtern oder zu ändern.
- Erweiterbarkeit von Software-as-a-Service (SaaS): Sie bieten möglicherweise eine SaaS-Lösung an und möchten Kunden die Möglichkeit geben, ihre Funktionen mithilfe von Erweiterungen zu erweitern. Diese Erweiterungen werden möglicherweise von Kunden oder Partnern geschrieben.
Google Cloud -Kunden nutzen Cloud Run bereits erfolgreich in der Produktion für diese Anwendungsfälle.
Herausforderungen bei Mehrmandantenplattformen
Zu den typischen Herausforderungen beim Erstellen einer solchen Architektur gehören:
- Sicherheit: Der bereitgestellte Code kann nicht gescannt oder bereinigt werden. Nicht vertrauenswürdiger Code kann schädliche Aktionen oder anfällige Abhängigkeiten enthalten. Wenn nicht vertrauenswürdiger Code nicht richtig isoliert wird, kann er möglicherweise auf sensible Daten anderer Mandanten zugreifen. Das bloße Verpacken des Codes in einem Container ist keine ausreichend starke Sicherheitsgrenze. Der Code muss auch in seinen Möglichkeiten eingeschränkt werden, indem das Prinzip der geringsten Berechtigung angewendet wird.
- 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 wenn es um das Löschen von Daten geht.
Vorteile von Cloud Run
Eine auf Cloud Run basierende Architektur bietet eine Lösung für häufige Herausforderungen mit vielen Vorteilen, z. B. Sicherheit, Kosteneffizienz und Mandantenverwaltung.
Sicherheit
Cloud Run bietet die sofort einsatzbereiten Sicherheitsfunktionen, die für diese Architektur relevant sind:
- Compute-Isolation: Cloud Run sorgt für eine strikte Isolation zwischen Containerinstanzen, unabhängig davon, ob sie zum selben Dienst oder zu verschiedenen Diensten aus verschiedenen Projekten gehören. Weitere Informationen zur Containersicherheit und zu Ausführungsumgebungen finden Sie unter Übersicht über das Sicherheitsdesign.
- 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: In Cloud Run werden nicht nur die Container in einer Sandbox ausgeführt, sondern es wird auch ein Multi-Tenant-Netzwerkstack bereitgestellt.
- 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 Abrechnung: Cloud Run-Instanzen werden automatisch auf null skaliert, wenn sie nicht verwendet werden. So wird sichergestellt, dass für gehostete Arbeitslasten nur dann Kosten anfallen, 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 profitieren Sie von einem noch detaillierteren Abrechnungsmodell, bei dem nur Gebühren anfallen, wenn Anfragen verarbeitet werden. Das sorgt für noch mehr Kosteneffizienz.
- On-Demand und schneller Start: Wenn Cloud Run-Dienste herunterskaliert werden, können sie schnell wieder hochskaliert werden. Dadurch wird die Latenz für den Endnutzer der bereitgestellten Anwendung minimiert.
- Automatisierte Kostenkennzeichnung: Alle von Cloud Run gemeldeten Kosten werden mit Labels versehen. So können Sie die Kostenzuordnung und ‑verfolgung Ihrer Mandanten automatisieren.
- Zusicherungen zur Senkung der Gesamtkosten: Auf Rechnungskontoebene können Sie flexible Rabatte für zugesicherte Nutzung verwenden, um die Ausgaben für die Cloud Run-Basisauslastung zu optimieren.
Mandantenverwaltung
Da Cloud Run On-Demand-Preise bietet, sind die Kosten nicht höher, wenn Sie mehrere Google Cloud Projekte verwenden. So können Sie Mandanten wie in Google Cloud -Projekte organisieren beschrieben verwalten.
Zielarchitektur für mehrmandantenfähige Plattformen
Hier ist die empfohlene Architektur auf hoher Ebene:
Projekte organisieren Google Cloud
Sie müssen eine Google Cloud Organisation und die Offlineabrechnung einrichten und Ihr Kontoteam benachrichtigen, dass Sie als Resellerkonto fungieren. Google Cloud arbeitet möglicherweise mit Ihnen zusammen, um sicherzustellen, dass geeignete Kommunikationskanäle zur Missbrauchsbekämpfung eingerichtet werden.
Sie müssen Ordner verwenden, um Ihre Google Cloud Projekte zu organisieren. Es ist besonders wichtig, dass Sie die Projekte, in denen Ihr Erstanbietercode ausgeführt wird, in anderen Ordnern als die Projekte platzieren, in denen nicht vertrauenswürdiger Code Ihrer Mandanten ausgeführt wird. Sie müssen das Tenant-Onboarding automatisieren, damit zum Erstellen der Projekte und Ressourcen eines Tenants keine menschliche Interaktion 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 bietet:
- Einfachere Sicherheit: Das Google Cloud Projekt ist eine strikte Grenze für alle darin enthaltenen Ressourcen. Wenn ein Mandant Zugriff auf mehrereGoogle Cloud -Ressourcen wie mehrere Cloud Run-Dienste und 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. Es gibt ähnliche Limits für die Anzahl der Dienstkonten und anderer zugehöriger Ressourcen.
- 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 vorläufiges Limit von 100.000 Projekten pro Rechnungskonto, das durch Kontaktaufnahme mit Google erhöht werden kann. Ihre Organisation kann auch mehrere Rechnungskonten erstellen und sie in einer „Kontogruppe“ zusammenfassen (derzeit in der privaten Vorschau).
- Einfachere Überwachung und Verwaltung:
- Wenn Sie ein Projekt pro Mandant verwenden, wird das Löschen von Daten vereinfacht, da Sie zum Löschen von Daten für einen Mandanten nur das entsprechende Projekt löschen müssen.
- 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 Nutzung von Cloud Run-Ressourcen für einen bestimmten Mandanten begrenzen und die Limits möglicherweise an Ihre eigenen Preisstufen anpassen.
- Mit benutzerdefinierten Organisationsrichtlinien können Sie bestimmte Einschränkungen auf alle Projekte eines Ordners anwenden, z. B. verfügbare Regionen oder die 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 mit 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 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 unterschiedliche Mandanten im selben Projekt hosten, müssen Sie besonders auf die Sicherheit achten. Dazu können Sie beispielsweise dedizierte Dienstkonten und detaillierte Berechtigungen verwenden.
Anfragenrouting 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. Sie können beispielsweise eine Subdomain dem Google Cloud -Projekt zuordnen, in dem der Dienst des Mandanten gehostet wird.
Sie können Ihren benutzerdefinierten 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 (wobei die Logik inline mit der Anfrageverarbeitung ausgeführt wird) oder als Zusatzinformationen (die Routinglogik wird an einen separaten Cloud Run-Dienst delegiert, der eine der skalierbaren multiregionalen Datenbanken vonGoogle Cloudwie Spanner aufrufen kann) implementiert werden.
Wenn Sie einen Application Load Balancer verwenden, können Sie auch eine Caching-Ebene hinzufügen, indem Sie Cloud CDN nutzen. Außerdem können Sie Ihrer Plattform mit Cloud Armor zusätzlichen DDoS-Schutz (Distributed Denial of Service) hinzufügen.
Ruf 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 der angebotenen Reputationsstufen ein anderes Cloud-Rechnungskonto zu verwenden. Ihre Mandanten mit kostenlosem Kontingent sollten beispielsweise nicht mit demselben Rechnungskonto verknüpft sein wie Ihre Kunden mit hohen Ausgaben. Google kann diese Abrechnungskonten auf unterschiedlichen Reputationsstufen berücksichtigen.
Wie unter Google Cloud -Projekte organisieren beschrieben, sollten Sie Projekte nicht nur nach Rechnungskonto, sondern auch nach Ordnern organisieren. Google kann Ihnen helfen, Kontingente auf Ordner-Ebene 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 automatisch gemäß den Google Cloud Nutzungsbedingungen. Google kann auch Ereignisse zur Erkennung von Missbrauch in Cloud Logging protokollieren, auf die Sie dann reagieren können.