Geben Sie hier eine kurze Beschreibung Ihres Konzepts ein (optional).

Eine internetorientierte Cluster-Bereitstellung macht die SystemLink Enterprise Anwendung über das öffentliche Internet zugänglich, wobei die Kubernetes-Cluster-Infrastruktur in privaten Subnetzen verbleibt. Diese Architektur eignet sich für Organisationen, die:

  • Remote-Zugriff auf verteilte Teams
  • Verwaltung geografisch verteilter Testsysteme

Was ist eine internetorientierte Bereitstellung?

Bei einer internetorientierten Bereitstellung greifen Benutzer über HTTPS über das öffentliche Internet auf die SystemLink Web-UI und API zu. Der Begriff "internet-facing" bezieht sich auf die Zugänglichkeit der Anwendung, nicht auf die Cluster-Infrastruktur selbst. Die Kubernetes-Cluster-Knoten, Datenbanken und internen Dienste verbleiben in privaten Subnetzen ohne direkte Internetanbindung.

Architekturüberblick

Eine typische internetorientierte SystemLink-Bereitstellung verwendet die folgende Netzwerkarchitektur:

  • Öffentliche Subnetze: Host-Load-Balancer (Application Gateway auf Azure, Application Load Balancer auf AWS), die HTTPS-Verkehr aus dem Internet akzeptieren
  • Private Subnetze: Host Kubernetes-Cluster-Knoten, Datenbanken und alle SystemLink Dienste ohne direkten Internetzugang
  • NAT-Gateway: Bietet ausgehende Internetverbindung für Cluster-Knoten, um Updates herunterzuladen, Containerabbilder abzurufen und mit externen Diensten zu kommunizieren
  • Ingress-Controller: Wird im Kubernetes-Cluster ausgeführt und leitet den Datenverkehr vom Load Balancer zu SystemLink Diensten
Hinweis Im Folgenden wird eine Referenzarchitektur dargestellt. Ihr Unternehmen kann den internetorientierten Zugriff basierend auf Ihren spezifischen Anforderungen und Ihrer spezifischen Cloud-Plattform mit verschiedenen Komponenten oder Konfigurationen implementieren.

Phasen eines typischen Datenverkehrsflusses:

  1. Benutzer stellt über HTTPS eine Verbindung mit öffentlichem DNS-Namen (z. B. systemlink.example.com) her
  2. DNS löst die öffentliche IP-Adresse des Load Balancers in einem öffentlichen Subnetz auf
  3. Load Balancer führt TLS-Termination durch und leitet den Datenverkehr an den Kubernetes-Ingress-Controller in einem privaten Subnetz weiter
  4. Ingress-Controller leitet Anfragen an die entsprechenden SystemLink-Service-Pods im privaten Subnetz
  5. Dienste antworten über denselben Pfad zurück

Detaillierte Informationen zur Subnetzarchitektur und -konfiguration finden Sie unter AWS VPC oder Azure VNet.

Sicherheitsvorgaben

NI empfiehlt zusätzliche Sicherheitsmaßnahmen für internetorientierte Bereitstellungen über die für private Bereitstellungen hinaus.

NI empfiehlt dringend, dass der gesamte Internetverkehr zu SystemLink HTTPS mit gültigen TLS-Zertifikaten verwendet. NI empfiehlt, HTTP-Endpunkte nicht dem öffentlichen Internet zugänglich zu machen.

  • Zertifikatserwerb: Verwenden Sie die verwalteten Zertifikate Ihres Cloud-Anbieters (AWS Certificate Manager, Azure Key Vault Certificates) oder erhalten Sie Zertifikate von einer vertrauenswürdigen Zertifizierungsstelle
  • TLS-Beendigung: NI empfiehlt, die TLS-Beendigung am Load Balancer zu konfigurieren, um das Zertifikatsmanagement zu vereinfachen

NI empfiehlt die Bereitstellung einer Web Application Firewall zum Schutz vor gängigen Web-Exploits und Angriffen. Sie können WAF-Dienste des Cloud-Anbieters (AWS WAF, Azure Web Application Firewall) oder WAF-Lösungen von Drittanbietern verwenden.

DNS-Konfiguration

Erstellen Sie DNS-Einträge in Ihrer öffentlichen DNS-Zone für SystemLink-Endpunkte. Siehe Layer 7 (Application) Ingress für Web-UI- und API-Konfiguration und Layer 4 (TCP) Ingress für Salt Master Konfiguration. Informationen zur OIDC-Umleitungs-URI-Konfiguration finden Sie unter Identitäts- und Zugriffsmanagement.