Informationen zur Architektur und Workloadisolation von Code Engine

IBM Cloud® Code Engine ist die IBM Cloud-Plattform zur Vereinheitlichung von Container-Images, 12-Faktor-Apps, Funktionen und Stapeljobs als One-Stop-Shop. Es handelt sich um ein Multi-Tenant-System, das aus drei Hauptbausteinen besteht: Eine Steuerebene, mindestens ein Shard und eine Routing-Ebene. Die Steuerebene und die Shards werden als separate Kubernetes-Cluster mit mehreren Zonen realisiert. Das folgende Diagramm bietet einen grafischen Überblick über die Architektur:

Code Engine architekturschema Architekturschema Architekturschema
Code Engine

Code Engine basiert auf IBM Cloud Kubernetes Service-Clustern und es besteht eine Abhängigkeit von den Komponenten und der Workloadisolation von IBM Cloud Kubernetes Service. Weitere Informationen finden Sie unter Architektur von IBM Cloud Kubernetes Service-VPC-Clustern.

Alle Komponenten werden von IBM verwaltet, sind Eigentum von IBM und werden unter Verwendung des IBM Cloud-Kontos ausgeführt. Jeder Cluster wird in einer eigenen VPC-Instanz ausgeführt und ist von anderen Clustern getrennt.

Von der Code Engine-Steuerebene werden die Komponenten ausgeführt, die gemeinsam von allen Code Engine-Benutzern genutzt werden und den Kubernetes-Cluster zu einem echten Multi-Tenant-System machen. Die Steuerebene besteht aus vier Mikroservices, die auf der Steuerebene bereitgestellt werden.

Code Engine microservices auf der Steuerungsebene
Komponente Zweck
Ressourcenbroker Erstellt und löscht Code Engine-Projektressourcen im IBM Cloud-Ressourcencontroller und fordert die Platzierung des Projekts auf einem Shard an.
Verteilungscontroller für Projekte Wählt ein Shard aus und fordert die Erstellung, Löschung und Isolation des Projekts auf dem Shard an.
API-Server Stellt die Zielinformationen (Datei KUBECONFIG) für das ausgewählte Projekt bereit. Führt auch die Überprüfungen der IAM-Zugriffsrichtlinie durch und schreibt Prüfsätze.
Kube API proxy Leitet jede API-Anforderung an den entsprechenden Shard-Cluster weiter, führt Überprüfungen der IAM-Richtlinien durch und schreibt Prüfsätze.

Von den Shards wird die Kundenworkload ausgeführt, zum Beispiel Builds, Stapeljobs oder Apps. Deswegen werden vom Shard-Cluster die folgenden Mikroservices zum Steuern der Kundenworkloads ausgeführt.

Shard-Cluster-Mikrodienste
Komponente Zweck
Controller für Projektisolation Verwaltet und isoliert den Kubernetes-Namensbereich, der der Code Engine-Projektressource entspricht. Überwacht alle Aspekte der Isolation und stellt sicher, dass Isolationsaspekte wie rollenbasierte Zugriffssteuerung (RBAC), Podsicherheitsrichtlinien, Ressourcenkontingente und Netzrichtlinien durchgesetzt werden.
Controller für Projektdomäne und -zertifikate Verwaltet die Domäne und die Zertifikate für den Routenendpunkt des Projekts. Der Endpunkt besteht aus einem DNS-Eintrag und einem Platzhalterzertifikat.
Knative und Istio Verwalten den Lebenszyklus der Anwendungen. Von Knative wird die Skalierung der Anwendung durchgeführt. Istio dient zum Weiterleiten des Datenverkehrs zur richtigen Revision und zum richtigen Container der Anwendung.
Stapelcontroller Verwaltet den Lebenszyklus und die Container für Jobs und Jobausführungen.
Build-Controller Verwaltet den Lebenszyklus und die Container für Builds und Buildausführungen.
Servicebindung und IBM Cloud-Operator Verwaltet den Lebenszyklus von geheimen Schlüsseln, die Bindungen von IBM Cloud-Services zu Anwendungen und Jobs zugeordnet sind.
Controller für IBM Cloud Object Storage-Ereignisquellen Verwaltet den Lebenszyklus von Ereignisabonnements über den IBM Cloud Object Storage-Service.
Autoscaler für Clusterknoten Skaliert das Shard durch das Hinzufügen bzw. Entfernen von Workerknoten abhängig von der Kapazitätsanforderung.
IBM Cloud Monitoring Sendet Servicemetriken an IBM Cloud Monitoring. Weitere Informationen zu diesen Metriken finden Sie unter Überwachung für Code Engine.
IBM® Cloud Logs Leitet Plattformprotokolle und -metriken an IBM Cloud Logs weiter. Weitere Informationen finden Sie unter Audit von Ereignissen für Code Engine.

Isolation von Code Engine-Workloads

Code Engine ist ein regionaler Multi-Tenant-Service, bei dem Tenants dieselbe Netz- und Recheninfrastruktur gemeinsam nutzen. Insbesondere handelt es sich bei der Netz- und Recheninfrastruktur um gemeinsam genutzte Ressourcen und einige Managementkomponenten sind allen Tenants gemeinsam. Code Engine implementiert die folgenden Steuerelemente, um Tenants zu trennen:

  • Code Engine-Projektressourcen werden in einer geschützten Kubernetes-Umgebung, die in einer IBM Cloud-Region mit mehreren Zonen ausgeführt wird, von anderen getrennt.
  • Code Engine-Projekte und die zugehörigen Ressourcen, wie zum Beispiel Anwendungen, Builds und Jobs, die in gemeinsame genutzten Clustern ausgeführt werden, von denen gemeinsam genutzte Managementkomponenten verwendet werden.
  • Um den Zugriff auf Projektressourcen abzugrenzen, führt Code Engine mehrstufige Authentifizierungs- und Autorisierungsprüfungen innerhalb der Komponenten apiserver und kube-api-proxy aus (siehe obige Tabelle).
    • Die Überprüfungen der IAM-Authentifizierung und der Zugriffsrichtlinien werden auf Projektebene durchgeführt.
    • Zur Verwaltung des Multi-Tenant-Zugriffs auf die zugrunde liegende Kubernetes-API ist kein direkter Zugriff auf den API-Server zulässig. Verwenden Sie stattdessen für den Zugriff die angepasste API Kube-api-proxy von Code Engine.
    • Die Überprüfungen der rollenbasierten Zugriffssteuerung werden auf der Ressourcenebene durchgeführt, damit nur berechtigte Benutzer bestimmte Operationen an den Projektressourcen vornehmen können.
  • Die Autorisierung wird vom Kunden durch das Zuweisen der Rollen manager, reader oder writer an Benutzer für eine Code Engine-Projektressource in IAM gesteuert.
  • Zur Beschränkung der Kundenworkload setzt Code Engine die folgenden Konzepte durch:
    • Containerisolation durch verschiedene Linux-Isolationsverfahren. Diese Verfahren sorgen für mehrere Sicherheitsebenen, um die Rechteausweitung von Containern zu verhindern und um Container auf die Verwendung einer begrenzten Gruppe von Systemberechtigungen zu beschränken.
    • Ressourcenkontingente und LimitRange zum Vermeiden einer übermäßigen Ressourcenauslastung.
    • Netzrichtlinien zur Steuerung der Netzflüsse in der Umgebung.
  • Gemeinsam genutzte Multi-Tenant-Komponenten werden gesichert, beispielsweise durch Inaktivierung von Reverse Lookup in KubeDNS.
  • Zur Beschränkung der Auswirkungen wird jeder Shard-Cluster in einer eigenen Virtual Private Cloud (VPC) ausgeführt, die von den anderen VPCs des Shards isoliert ist.
  • Der DDOS-Schutz wird automatisch für alle Endpunkte, einschließlich Kundenanwendungen, über Cloud Internet Services (CIS) aktiviert, ohne dass zusätzliche Kosten für Sie anfallen. DDoS der Schutz deckt Angriffe auf das OSI-Protokoll der Schichten 3 und 4 (TCP/IP) ab, nicht aber Angriffe auf Schicht 7 ( HTTP ). Siehe DDoS Schutz.
  • Wenn Sie Regeln für die Web Application Firewall (WAF) benötigen, konfigurieren Sie Ihre eigene IBM Cloud Internet Services ( CIS ) Instanz oder einen Gateway-Dienst eines Drittanbieters mit einer benutzerdefinierten Domäne vor Ihren Code Engine Endpunkten und aktivieren Sie eine Web Application Firewall in dieser Instanz.