Freigeben über

Verbessern der Netzwerkzugriffssicherheit für Kubernetes

In diesem Artikel werden Netzwerkmodi für Azure Kubernetes Service (AKS) und Amazon Elastic Kubernetes Service (EKS) verglichen. Es beschreibt, wie die Verbindungssicherheit mit dem verwalteten API-Server eines AKS-Clusters verbessert wird. Es enthält auch Optionen zum Einschränken des öffentlichen Netzwerkzugriffs.

Hinweis

Dieser Artikel ist Teil einer Reihe von Artikeln , die Fachleuten helfen, die mit Amazon EKS vertraut sind, Azure Kubernetes Service (AKS) zu verstehen.

Amazon EKS-Netzwerkmodi

Sie können Amazon Virtual Private Cloud (VPC) verwenden, um Amazon Web Services (AWS)-Ressourcen in einem virtuellen Netzwerk mit öffentlichen und privaten Subnetzen zu starten. Die Subnetze sind Bereiche von IP-Adressen innerhalb der VPC. Ein öffentliches Subnetz hostt Ressourcen, die eine Verbindung mit dem Internet herstellen. Ein privates Subnetz hostt Ressourcen, die keine Verbindung mit dem öffentlichen Internet herstellen. Amazon EKS kann verwaltete Knotengruppen sowohl in öffentlichen als auch in privaten Subnetzen bereitstellen.

Die Endpunktzugriffskontrolle ermöglicht es Ihnen zu konfigurieren, ob der API-Endpunkt über das öffentliche Internet oder über die VPC erreichbar ist. Amazon EKS bietet mehrere Möglichkeiten, den Zugriff auf den Cluster-Endpunktzu kontrollieren. Sie können den öffentlichen Standardendpunkt, einen privaten Endpunkt oder beide Endpunkte gleichzeitig aktivieren. Wenn Sie den öffentlichen Endpunkt aktivieren, können Sie CIDR-Einschränkungen (Classless Inter-Domain Routing, klassenloses domänenübergreifendes Routing) hinzufügen, um die Client-IP-Adressen einzuschränken, die eine Verbindung mit dem öffentlichen Endpunkt herstellen können.

Die Endpunkteinstellung des Clusters bestimmt, wie Amazon EKS-Knoten mit der verwalteten Kubernetes-Steuerungsebene verbinden. Sie können die Endpunkteinstellungen über die Amazon EKS-Konsole oder die API ändern. Weitere Informationen finden Sie unter Zugriffssteuerung für den Amazon EKS-Cluster-Endpunkt.

Nur öffentlicher Endpunkt

Der Standardmodus für neue Amazon EKS-Cluster macht die Steuerebene über einen öffentlichen Endpunkt verfügbar. Wenn nur der öffentliche Endpunkt für den Cluster aktiviert ist, verlassen Kubernetes-API-Anforderungen, die aus dem VPC stammen, den VPC, aber nicht das Amazon-Netzwerk. Zu diesen Anforderungen gehören die Kommunikation vom Arbeitsknoten zur Steuerungsebene. Knoten stellen über eine öffentliche IP-Adresse und eine Route zu einem Internetgateway eine Verbindung mit der Steuerebene her. Sie können auch eine Route zu einem NAT-Gateway (Network Address Translation) verwenden, wo sie die öffentliche IP-Adresse des NAT-Gateways verwenden können.

Öffentliche und private Endpunkte

Wenn Sie sowohl die öffentlichen als auch die privaten Endpunkte aktivieren, kommunizieren Kubernetes-API-Anforderungen innerhalb der VPC über die von Amazon EKS verwalteten elastischen Netzwerkschnittstellen (ENIs) in der VPC mit der Kontroll-Ebene. Der Cluster-API-Server kann über das Internet erreichbar sein.

Nur privater Endpunkt

Wenn Sie nur den privaten Endpunkt aktivieren, muss der gesamte Datenverkehr an den Cluster-API-Server, wie z. B. kubectl oder helm Befehle, aus dem VPC des Clusters oder einem verbundenen Netzwerk stammen. Der öffentliche Zugriff auf den API-Server aus dem Internet ist deaktiviert. Um diesen Zugriffsmodus zu implementieren, verwenden Sie AWS Virtual Private Network (VPN) oder AWS DirectConnect zur VPC. Um den Zugriff auf den Endpunkt ohne AWS VPN oder DirectConnect einzuschränken, können Sie dem öffentlichen Endpunkt CIDR-Einschränkungen hinzufügen, um Verbindungen zu beschränken, ohne weitere Netztechnologien einrichten zu müssen.

Wenn Sie den öffentlichen Zugriff für den Kubernetes-API-Serverendpunkt Ihres Clusters deaktivieren, können Sie auf eine der folgenden Arten auf den Kubernetes-API-Serverendpunkt zugreifen:

Weitere Informationen zu Konnektivitätsoptionen finden Sie unter Access a private-only API-Server.

AKS-Netzwerkzugriff auf den API-Server

Um den Netzwerkzugriff auf die Kubernetes-API in AKS zu sichern, können Sie einen privaten AKS-Cluster oder autorisierte IP-Adressbereiche verwenden.

Privater AKS-Cluster

Ein privater AKS-Cluster trägt dazu bei, dass der Netzwerkdatenverkehr zwischen dem API-Server und den Agentknoten innerhalb des virtuellen Netzwerks verbleibt. In einem privaten AKS-Cluster verfügt die Steuerungsebene oder der API-Server über interne IP-Adressen. Ein privater Cluster trägt dazu bei, sicherzustellen, dass der Netzwerkdatenverkehr zwischen Ihrem API-Server und Ihren Knotenpools nur im privaten Netzwerk verbleibt.

In einem privaten AKS-Cluster verfügt der API-Server über eine interne IP-Adresse, die nur über einen privaten Azure-Endpunkt erreichbar ist, der sich im selben virtuellen Netzwerk befindet. Virtuelle Computer (VMs) im selben virtuellen Netzwerk können über diesen privaten Endpunkt privat mit der Steuerebene kommunizieren. Die Steuerebene oder der API-Server wird im azureverwalteten Abonnement gehostet. Der AKS-Cluster und seine Knotenpools befinden sich im Abonnement des Kunden.

Das folgende Diagramm zeigt eine private AKS-Clusterkonfiguration.

Diagramm, das eine private AKS-Clusterkonfiguration zeigt.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Um einen privaten AKS-Cluster bereitzustellen, erstellt der AKS-Ressourcenanbieter einen privaten vollqualifizierten Domänennamen (FQDN) für die Knotenressourcengruppe in einer privaten Dns-Zone (Domain Name System). Optional kann AKS auch einen öffentlichen FQDN erstellen, der über einen entsprechenden Adresseintrag A in der öffentlichen Azure DNS-Zone verfügt. Die Agent-Knoten verwenden den A-Eintrag in der privaten DNS-Zone, um die IP-Adresse des privaten Endpunkts für die Kommunikation mit dem API-Server aufzulösen.

Der AKS-Ressourcenanbieter kann die private DNS-Zone in der Knotenressourcengruppe erstellen, oder Sie können die private DNS-Zone erstellen und deren Ressourcen-ID an das Bereitstellungssystem übergeben. Um einen privaten Cluster zu erstellen, können Sie Terraform mit Azure-, Bicep-, Azure Resource Manager-Vorlagen, der Azure CLI, dem Azure PowerShell-Modul oder der Azure REST-API verwenden.

Sie können während der Bereitstellung einen öffentlichen FQDN für den API-Server aktivieren oder indem Sie den Befehl az aks update mit dem Parameter --enable-public-fqdn auf vorhandenen Clustern verwenden. Wenn Sie den öffentlichen FQDN aktivieren, müssen sich virtuelle Computer, die auf den Server zugreifen, im selben virtuellen Netzwerk befinden, in dem sich der Cluster oder in einem Netzwerk befindet, das über virtuelles Netzwerk-Peering oder Standort-zu-Standort-VPN verbunden ist. Beispiele für diese virtuellen Computer sind ein selbst gehosteter Azure DevOps-Agent oder ein selbst gehosteter GitHub Actions-Runner.

Deaktivieren Sie für einen privaten AKS-Cluster den öffentlichen FQDN des API-Servers. Um mit der privaten Kontrollebene zu kommunizieren, muss sich eine VM im selben virtuellen Netzwerk oder in einem peered virtual network befinden, das über eine virtuelle Netzwerkverbindung zur privaten DNS-Zone verfügt. Der A-Eintrag in der privaten DNS-Zone löst den FQDN des API-Servers zur IP-Adresse des privaten Endpunkts auf, die mit der zugrunde liegenden Steuerungsebene kommuniziert. Weitere Informationen finden Sie unter Erstellen eines privaten AKS-Clusters.

Optionen für die Bereitstellung privater Cluster

Der AKS-Ressourcenanbieter macht die folgenden Parameter verfügbar, um private AKS-Clusterbereitstellungen anzupassen:

  • Die authorizedIpRanges Zeichenfolge gibt zulässige IP-Adressbereiche im CIDR-Format an.

  • Der disableRunCommand Boolesche Wert gibt an, ob der run Befehl für den Cluster deaktiviert werden soll.

  • Der enablePrivateCluster Boolesche Wert gibt an, ob der Cluster als privat erstellt werden soll.

  • Der enablePrivateClusterPublicFQDN Boolesche Wert gibt an, ob ein anderer öffentlicher FQDN für den privaten Cluster erstellt werden soll.

  • Die privateDnsZone Zeichenfolge gibt eine private DNS-Zone in der Knotenressourcengruppe an. Wenn Sie keinen Wert angeben, erstellt der Ressourcenanbieter die Zone. Sie können die folgenden Werte angeben:

    • Der Standardwert lautet System.

    • Die Standardeinstellung von None ist „öffentliches DNS“, sodass AKS keine private DNS-Zone erstellt.

    • <Your own private DNS zone resource ID> verwendet eine private DNS-Zone, die Sie im Format privatelink.<region>.azmk8s.io oder <subzone>.privatelink.<region>.azmk8s.io erstellen.

In der folgenden Tabelle sind die DNS-Konfigurationsoptionen zum Bereitstellen eines privaten AKS-Clusters aufgeführt:

Optionen für private DNS-Zonen enablePrivateClusterPublicFQDN: true enablePrivateClusterPublicFQDN: false
System Agentenknoten und alle anderen VMs im virtuellen Netzwerk des AKS-Clusters oder in einem virtuellen Netzwerk, das mit der privaten DNS-Zone verbunden ist, verwenden den Datensatz der privaten DNS-Zone A , um die private IP-Adresse des privaten Endpunkts aufzulösen.

Andere VMs verwenden den öffentlichen FQDN des API-Servers.		 Agentenknoten und alle anderen VMs im virtuellen Netzwerk des AKS-Clusters oder in einem virtuellen Netzwerk, das mit der privaten DNS-Zone verbunden ist, verwenden den Datensatz der privaten DNS-Zone A , um die private IP-Adresse des privaten Endpunkts aufzulösen.

Kein öffentlicher FQDN eines API-Servers ist verfügbar.
Nichts Alle virtuellen Computer, einschließlich Agentknoten, verwenden den öffentlichen FQDN des API-Servers über einen A Eintrag in einer von Azure verwalteten öffentlichen DNS-Zone. Falsche Konfiguration. Der private AKS-Cluster benötigt mindestens eine öffentliche oder private DNS-Zone für die Namensauflösung des API-Servers.
Die Ressourcen-ID Ihrer eigenen privaten DNS-Zone Agentenknoten und alle anderen VMs im virtuellen Netzwerk des AKS-Clusters oder in einem virtuellen Netzwerk, das mit der privaten DNS-Zone verbunden ist, verwenden den Datensatz der privaten DNS-Zone A , um die private IP-Adresse des privaten Endpunkts aufzulösen.

Andere VMs verwenden den öffentlichen FQDN des API-Servers.		 Agentenknoten und alle anderen VMs im virtuellen Netzwerk des AKS-Clusters oder in einem virtuellen Netzwerk, das mit der privaten DNS-Zone verbunden ist, verwenden den Datensatz der privaten DNS-Zone A , um die private IP-Adresse des privaten Endpunkts aufzulösen.

Kein öffentlicher FQDN eines API-Servers ist verfügbar.

Konnektivität und Verwaltung privater Cluster

In einem privaten AKS-Cluster verfügt der API-Serverendpunkt über keine öffentliche IP-Adresse. Sie können eine der folgenden Optionen verwenden, um die Netzwerkkonnektivität mit dem privaten Cluster herzustellen:

  • Erstellen Sie einen virtuellen Computer im selben virtuellen Netzwerk wie der AKS-Cluster, der den az vm create Befehl mit dem --vnet-name Flag verwendet.

  • Verwenden Sie einen virtuellen Computer in einem separaten virtuellen Netzwerk, und richten Sie virtuelles Netzwerk-Peering mit dem virtuellen AKS-Clusternetzwerk ein.

  • Konfigurieren Sie ein Azure ExpressRoute- oder VPN-Gateway , um eine Verbindung mit dem virtuellen Clusternetzwerk herzustellen.

  • Erstellen Sie eine private Azure-Endpunktverbindung in einem anderen virtuellen Netzwerk.

  • Verwenden Sie eine Azure Cloud Shell-Instanz , die in einem Subnetz bereitgestellt wird, das mit dem API-Server für den Cluster verbunden ist.

Verwenden Sie die Azure CLI, um den Befehl "az aks" aufzurufen , um auf private Cluster zuzugreifen, ohne ein VPN- oder ExpressRoute-Gateway zu konfigurieren. Verwenden Sie diesen Befehl, um andere Befehle, wie z. B. kubectl und helm, aus der Ferne über die Azure-API auf Ihrem privaten Cluster auszuführen, ohne eine direkte Verbindung mit dem Cluster herzustellen. Um command invoke zu verwenden, richten Sie die erforderlichen Berechtigungen für die Aktionen Microsoft.ContainerService/managedClusters/runcommand/action und Microsoft.ContainerService/managedclusters/commandResults/read ein.

Im Azure-Portal können Sie das Run command Feature verwenden, um Befehle auf Ihrem privaten Cluster auszuführen. Dieses Feature verwendet die command invoke Funktionalität zum Ausführen von Befehlen auf Ihrem Cluster. Der von der Run command-Funktion erstellte Pod stellt kubectl- und helm-Tools zur Verwaltung Ihres Clusters bereit. Dieses Run command bietet auch eine Bash-Umgebung innerhalb des Pods, die Tools wie jq, xargs, grep und awk umfasst.

Sie können Azure Bastion im selben virtuellen Netzwerk oder in einem verbundenen virtuellen Netzwerk verwenden, um eine Verbindung mit einer VM für die Jumpbox-Verwaltung herzustellen. Azure Bastion ist eine vollständig verwaltete Plattform als Dienst (PaaS), die Sie zum Herstellen einer Verbindung mit einem virtuellen Computer über Ihren Browser und das Azure-Portal verwenden können. Azure Bastion bietet hochsichere und nahtlose Remotedesktopprotokoll (RDP)- oder SSH-VM-Konnektivität über Transport Layer Security (TLS) direkt aus dem Azure-Portal. Beim Herstellen einer Verbindung über Azure Bastion benötigen VMs keine öffentliche IP-Adresse, keinen Agent und keine spezielle Clientsoftware.

API-Server-VNET-Integration

Ein AKS-Cluster, der mit api Server VNet Integration konfiguriert ist, projiziert den API-Serverendpunkt direkt in ein delegiertes Subnetz. Das Subnetz befindet sich im virtuellen Netzwerk, in dem AKS bereitgestellt wird. Die VNet-Integration von API-Servern ermöglicht die Netzwerkkommunikation zwischen dem API-Server und den Clusterknoten ohne private Verknüpfung oder Tunnel. Der API-Server steht hinter einem internen Load Balancer VIP zur Verfügung, der sich im delegierten Subnetz befindet. Die Knoten sind so konfiguriert, dass sie den internen Load Balancer VIP verwenden. Verwenden Sie die VNet-Integration von API-Servern, um sicherzustellen, dass der Netzwerkdatenverkehr zwischen Ihrem API-Server und Ihren Knotenpools nur im privaten Netzwerk verbleibt.

Die Steuerebene oder der API-Server befindet sich in einem AKS-verwalteten Azure-Abonnement. Ihr Cluster- oder Knotenpool befindet sich in Ihrem Azure-Abonnement. Der Server und die virtuellen Computer, aus denen die Clusterknoten bestehen, können über die VIP- und Pod-IP-Adressen des API-Servers miteinander kommunizieren, die in das delegierte Subnetz projiziert werden.

Sie können die API-Server-VNet-Integration mit öffentlichen Clustern und privaten Clustern verwenden. Sie können nach der Clusterbereitstellung den öffentlichen Zugriff hinzufügen oder entfernen. Im Gegensatz zu Clustern, die nicht über eine Virtuelle Netzwerkintegration verfügen, kommunizieren die Agentknoten immer direkt mit der privaten IP-Adresse des internen LASTENausgleichs-IP des API-Servers, ohne DNS zu verwenden. Datenverkehr, der vom Knoten zum API-Serverdatenverkehr wechselt, befindet sich in privaten Netzwerken. Und für die API-Server-zu-Knoten-Konnektivität ist kein Tunnel erforderlich. Out-of-Cluster-Clients können normalerweise mit dem API-Server kommunizieren, wenn der Zugriff auf öffentliche Netzwerke aktiviert ist. Wenn der Zugriff auf öffentliche Netzwerke deaktiviert ist, befolgen Sie dieselbe private DNS-Einrichtungsmethode wie standard private Cluster. Weitere Informationen finden Sie unter Create an AKS cluster with API Server VNet Integration.

Autorisierte IP-Adressbereiche

Sie können auch autorisierte IP-Adressbereiche verwenden, um die Clustersicherheit zu verbessern und Angriffe auf den API-Server zu minimieren. Autorisierte IP-Adressbereiche beschränken den Zugriff auf die Kontrollebene eines öffentlichen AKS-Clusters auf eine bekannte Liste von IP-Adressen und CIDRs. Wenn Sie diese Option verwenden, ist der API-Server weiterhin öffentlich verfügbar, doch der Zugriff ist eingeschränkt.

Der folgende az aks update Azure CLI-Befehl autorisiert IP-Adressbereiche:

 az aks update \
     --resource-group myResourceGroup \
     --name myAKSCluster \
     --api-server-authorized-ip-ranges  73.140.245.0/24

Überlegungen zur AKS-Konnektivität

Berücksichtigen Sie die folgenden wichtigen Punkte für die AKS-Konnektivität:

  • Ein privater AKS-Cluster bietet eine verbesserte Sicherheit und Isolation im Vergleich zu autorisierten IP-Adressbereichen. Sie können jedoch keinen vorhandenen öffentlichen AKS-Cluster in einen privaten Cluster konvertieren. Stattdessen können Sie autorisierte IP-Adressbereiche für jeden vorhandenen AKS-Cluster aktivieren.

  • Sie können autorisierte IP-Adressbereiche nicht auf einen privaten API-Serverendpunkt anwenden. Sie gelten nur für den öffentlichen API-Server.

  • Private Cluster unterstützen keine von Azure DevOps gehosteten Agents. Stattdessen sollten Sie selbst gehostete Agents verwenden.

  • Damit azure Container Registry mit einem privaten AKS-Cluster funktioniert, müssen Sie einen privaten Link für die Containerregistrierung im virtuellen Clusternetzwerk einrichten. Alternativ können Sie ein Peering zwischen dem virtuellen Netzwerk der Containerregistrierung und dem virtuellen Netzwerk des privaten Clusters einrichten.

  • Die Einschränkungen von Azure Private Link gelten für private Cluster.

  • Wenn der private Endpunkt im Kundensubnetz eines privaten Clusters gelöscht oder geändert wird, funktioniert der Cluster nicht mehr.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

Andere Mitwirkende:

Um nichtöffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte