Netzwerkisolierte Azure Kubernetes Service (AKS)-Cluster (Vorschau)
Organisationen verfügen in der Regel über strenge Sicherheits- und Complianceanforderungen, um den von einem Cluster ausgehenden (Egress-) Netzwerkdatenverkehr zu regulieren, um das Risiko der Datenexfiltration auszuschließen. Standardmäßig haben Azure Kubernetes Service (AKS)-Cluster uneingeschränkten ausgehenden Internetzugriff. Diese Ebene des Netzwerkzugriffs ermöglicht, dass ausgeführte Knoten und Dienste nach Bedarf auf externe Ressourcen zugreifen können. Wenn Sie den ausgehenden Datenverkehr einschränken möchten, muss eine begrenzte Anzahl von Ports und Adressen zugänglich sein, um fehlerfreie Clusterwartungsaufgaben verwalten zu können. Das konzeptionelle Dokument für ausgehenden Netzwerk- und FQDN-Regeln für AKS-Cluster stellt eine Liste der erforderlichen Endpunkte für den AKS-Cluster und seine optionalen Add-Ons und Features bereit.
Eine Lösung zum Einschränken ausgehender Datenverkehr aus dem Cluster besteht darin, ein Firewallgerät zu verwenden, um den Datenverkehr basierend auf Domänennamen einzuschränken. Es ist umständlich und kompliziert, eine Firewall manuell mit erforderlichen Regeln für ausgehenden Datenverkehr und FQDNs zu konfigurieren.
Eine andere Lösung, ein vom Netzwerk isolierter AKS-Cluster (Vorschau), vereinfacht das Einrichten ausgehender Einschränkungen für einen Cluster, da keine zusätzliche Konfiguration erforderlich. Der Clusteroperator kann dann inkrementell zulässigen ausgehenden Datenverkehr für jedes Szenario einrichten, das aktiviert werden soll. Ein netzwerkisolierter AKS-Cluster reduziert somit das Risiko einer Datenexfiltration.
Wichtig
AKS-Previewfunktionen stehen gemäß dem Self-Service- und Aktivierungsprinzip zur Verfügung. Vorschauversionen werden „wie besehen“ und „wie verfügbar“ bereitgestellt und sind von Service Level Agreements und der Herstellergarantie ausgeschlossen. AKS-Vorschauversionen werden teilweise vom Kundensupport auf Grundlage der bestmöglichen Leistung abgedeckt. Daher sind diese Funktionen nicht für die Verwendung in der Produktion vorgesehen. Weitere Informationen finden Sie in den folgenden Supportartikeln:
Funktionsweise eines vom Netzwerk isolierten Clusters
Das folgende Diagramm veranschaulicht die Netzwerkkommunikation zwischen Abhängigkeiten für einen vom Netzwerk isolierten AKS-Cluster.
AKS-Cluster rufen Images ab, die für den Cluster und seine Features oder Add-Ons aus der Microsoft Artifact Registry (MAR) erforderlich sind. Mit diesem Image-Pull kann AKS neuere Versionen der Clusterkomponenten bereitstellen und auch kritische Sicherheitsrisiken beheben. Ein vom Netzwerk isolierter Cluster versucht dagegen, diese Images aus einer privaten Azure Container Registry (ACR)-Instanz abzurufen, die mit dem Cluster verbunden ist, anstatt von der MAR zu pullen. Wenn die Images nicht vorhanden sind, ruft die private ACR sie von MAR ab und stellt sie über ihren privaten Endpunkt zu, ohne dass ausgehender Datenverkehr vom Cluster zum öffentlichen MAR-Endpunkt aktiviert werden muss.
Die folgenden Optionen werden für eine privaten ACR mit netzwerkisolierten Clustern unterstützt:
AKS-verwaltete ACR: AKS erstellt, verwaltet und stimmt eine ACR-Ressource in dieser Option ab. Sie müssen weder irgendwelche Berechtigungen zuweisen noch die ACR verwalten. AKS verwaltet die Cacheregeln, die private Verbindung und den privaten Endpunkt, die im netzwerkisolierten Cluster verwendet werden. Eine AKS-verwaltetes ACR zeigt dasselbe Verhalten wie andere Ressourcen (Routentabelle, Azure Virtual Machine Scale Sets usw.) in der Infrastrukturressourcengruppe. Um das Risiko zu vermeiden, dass Clusterkomponenten oder der Bootstrap für neue Knoten fehlschlagen, sollten Sie die ACR, ihre Cacheregeln oder ihre Systemimages nicht aktualisieren oder löschen. Die AKS-verwaltete ACR wird kontinuierlich abgestimmt, sodass Clusterkomponenten und neue Knoten erwartungsgemäß funktionieren.
Hinweis
Nachdem Sie einen netzwerkisolierten AKS-Cluster gelöscht haben, werden die zugehörigen Ressourcen wie der von AKS verwaltete ACR, die private Verbindung und der private Endpunkt automatisch gelöscht.
Bring your own (BYO) ACR: Die BYO-ACR-Option erfordert die Erstellung einer ACR mit einer privaten Verbindung zwischen der ACR-Ressource und dem AKS-Cluster. Um zu verstehen, wie Sie einen privaten Endpunkt für Ihre Registrierung konfigurieren, lesen Sie Herstellen einer privaten Verbindung mit einer Azure Container Registry über Azure Private Link.
Hinweis
Wenn Sie den AKS-Cluster löschen, werden die BYO-ACR, die private Verbindung und der private Endpunkt nicht automatisch gelöscht. Wenn Sie der BYO-ACR benutzerdefinierte Images und Cacheregeln hinzufügen, bleiben diese auch nach dem Abgleich des Clusters, nach der Deaktivierung der Funktion oder nach dem Löschen des AKS-Clusters erhalten.
Beim Erstellen eines netzwerkisolierten AKS-Clusters können Sie einen der folgenden privaten Clustermodi auswählen:
- Auf Private Link basierender AKS-Cluster: Die Steuerungsebene oder der API-Server befindet sich in einer von AKS verwalteten Azure-Ressourcengruppe, und Ihr Knotenpool befindet sich in Ihrer Ressourcengruppe. Der Server und der Knotenpool können über den Azure Private Link-Dienst im virtuellen Netzwerk des API-Servers und über einen privaten Endpunkt, der im Subnetz des AKS-Clusters verfügbar gemacht wird, miteinander kommunizieren.
- API-Server-VNet-Integration (Vorschau): Ein Cluster mit konfigurierter API-Server-VNet-Integration (Vorschau) projiziert den API-Serverendpunkt direkt in ein delegiertes Subnetz in dem virtuellen Netzwerk, in dem AKS bereitgestellt wurde. Die API-Server-VNet-Integration ermöglicht die Netzwerkkommunikation zwischen dem API-Server und den Clusterknoten, ohne dass eine private Verbindung oder ein Tunnel erforderlich ist.
Begrenzungen
- Vom Netzwerk isolierte Cluster werden in AKS-Clustern mit Kubernetes Version 1.30 oder höher unterstützt.
- Für netzwerkisolierte Cluster wird nur der
NodeImage
-Kanal des automatischen Upgrades für Betriebssystemimages der Knoten unterstützt. - Windows-Knotenpools werden derzeit nicht unterstützt.
- Die folgenden AKS-Clustererweiterungen werden in vom Netzwerk isolierten Clustern noch nicht unterstützt:
Häufig gestellte Fragen
Worin besteht der Unterschied zwischen einem netzwerkisoliertem Cluster und Azure Firewall?
Ein netzwerkisolierter Cluster erfordert während des gesamten Cluster-Bootstrapping-Prozesses keinen ausgehenden Datenverkehr über das VNet. Ein netzwerkisolierter Cluster weist den ausgehenden Typ none
oder block
auf. Wenn der ausgehende Typ auf none
festgelegt wird, richtet AKS keine ausgehenden Verbindungen für den Cluster ein, sodass der Benutzer oder die Benutzerin sie eigenständig konfigurieren kann. Wenn der ausgehende Typ auf block
festgelegt ist, werden alle ausgehenden Verbindungen blockiert.
Eine Firewall errichtet normalerweise eine Barriere zwischen einem vertrauenswürdigen Netzwerk und einem nicht vertrauenswürdigen Netzwerk wie dem Internet. Von Azure Firewall kann beispielsweise ausgehender HTTP- und HTTPS-Datenverkehr auf der Grundlage des FQDN des Ziels eingeschränkt werden. Dadurch können Sie ausgehenden Datenverkehr präzise steuern, gleichzeitig aber den Zugriff auf die FQDNs ermöglichen, die die ausgehenden Abhängigkeiten eines AKS-Clusters umfassen. (Dies ist mit NSGs nicht möglich.) Sie können beispielsweise den Ausgangstyp des Clusters auf userDefinedRouting
festlegen, sodass ausgehender Datenverkehr durch die Firewall erzwungen wird, und dann FQDN-Beschränkungen für den ausgehenden Verkehr konfigurieren.
Zusammenfassend lässt sich sagen, dass Azure Firewall zwar verwendet werden kann, um Egress-Beschränkungen für Cluster mit ausgehenden Anforderungen zu definieren, dass netzwerkisolierte Cluster jedoch noch weiter gehen, indem sie die ausgehenden Anforderungen ganz eliminieren oder blockieren.
Muss ich eine Positivliste für Endpunkte einrichten, damit der vom Netzwerk isolierte Cluster funktioniert?
Für die Clustererstellungs- und Bootstrappingphasen ist kein ausgehender Datenverkehr aus dem vom Netzwerk isolierten Cluster erforderlich. Images, die für AKS-Komponenten und Add-Ons erforderlich sind, werden aus der privaten ACR abgerufen, die mit dem Cluster verbunden ist, anstatt von der Microsoft-Artefaktregistrierung (MAR) über öffentliche Endpunkte abgerufen zu werden.
Wenn Sie nach dem Einrichten eines netzwerkisolierten Clusters Funktionen oder Add-Ons aktivieren möchten, die ausgehende Anforderungen an ihre Dienstendpunkte senden müssen, können private Endpunkte für die Dienste, die sich auf Azure Private Link stützen, eingerichtet werden.
Kann ich manuell für Pakete ein Upgrade durchführen, um das Knotenpoolimage zu aktualisieren?
Das manuelle Upgrade von Paketen auf der Grundlage von ausgehendem Dateverkehr aus Paket-Repositorys wird nicht unterstützt. Stattdessen können Sie die Knotenbetriebssystemimages automatisch aktualisieren. Für vom Netzwerk isolierte Cluster wird nur der NodeImage
-Kanal für das automatische Upgrade von Knotenbetriebssystemimages unterstützt.
Nächste Schritte
Azure Kubernetes Service