Bearbeiten

Freigeben über

Sicherer Netzwerkzugriff auf Kubernetes

Azure Bastion
Azure DNS
Azure Kubernetes Service (AKS)
Azure Private Link
Azure Virtual Network

In diesem Artikel werden Netzwerkmodi für Azure Kubernetes Service (AKS) und Amazon Elastic Kubernetes Service (Amazon EKS) verglichen. Im Artikel wird beschrieben, wie Sie die Verbindungssicherheit mit dem verwalteten API-Server eines AKS-Clusters verbessern können, sowie die verschiedenen Optionen zum Einschränken des öffentlichen Netzwerkzugriffs.

Hinweis

Dieser Artikel ist Teil einer Artikelreihe, die Experten, die mit Amazon EKS vertraut sind, hilft, AKS zu verstehen.

Amazon EKS-Netzwerkmodi

Mit Amazon Virtual Private Cloud (Amazon VPC) können Sie Amazon Web Services (AWS)-Ressourcen in einem virtuellen Netzwerk starten, das aus öffentlichen und privaten Subnetzen oder Bereichen von IP-Adressen in der VPC besteht. Ein öffentliches Subnetz hostet Ressourcen, die mit dem Internet verbunden sein müssen, und ein privates Subnetz hostet Ressourcen, die nicht mit dem öffentlichen Internet verbunden sind. Amazon EKS kann verwaltete Knotengruppen sowohl in öffentlichen als auch in privaten Subnetzen bereitstellen.

Mit der Zugriffssteuerung für Endpunkte können Sie konfigurieren, ob der API-Serverendpunkt über das öffentliche Internet oder über die VPC erreichbar ist. EKS bietet verschiedene Möglichkeiten zum Steuern des Zugriffs auf den Clusterendpunkt. 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.

Wie Amazon EKS-Knoten eine Verbindung mit der verwalteten Kubernetes-Steuerungsebene herstellen, wird davon bestimmt, welche Endpunkteinstellung für den Cluster konfiguriert ist. Sie können die Endpunkteinstellungen jederzeit über die Amazon EKS-Konsole oder die API ändern. Weitere Informationen finden Sie unter Zugriffssteuerung für Amazon EKS-Clusterendpunkte.

Nur öffentlicher Endpunkt

Das Verfügbarmachen der Steuerungsebene über einen öffentlichen Endpunkt ist der Standardmodus für neue Amazon EKS-Cluster. Wenn nur der öffentliche Endpunkt für den Cluster aktiviert ist, verlassen Kubernetes-API-Anforderungen, die aus der Amazon VPC stammen, z. B. Kommunikation von Workerknoten mit der Steuerungsebene, die VPC, verlassen aber nicht das Netzwerk von Amazon. Damit Knoten eine Verbindung mit der Steuerungsebene herstellen können, müssen sie eine öffentliche IP-Adresse und eine Route zu einem Internetgateway verwenden oder eine Route zu einem NAT-Gateway (Netzwerkadressenübersetzung), in dem sie die öffentliche IP-Adresse des NAT-Gateways verwenden können.

Öffentliche und private Endpunkte

Wenn sowohl die öffentlichen als auch die privaten Endpunkte aktiviert sind, kommunizieren Kubernetes-API-Anforderungen aus der VPC an die Steuerungsebene über die von Amazon EKS verwalteten elastischen Netzwerkschnittstellen (Elastic Network Interfaces, ENIs) in der VPC. Der Cluster-API-Server ist über das Internet zugänglich.

Nur privater Endpunkt

Wenn nur der private Endpunkt aktiviert ist, muss der gesamte Datenverkehr zum Cluster-API-Server, wie z. B. kubectl- oder helm-Befehle, aus dem VPC des Clusters oder aus einem verbundenen Netzwerk stammen. Der öffentliche Zugriff auf den API-Server aus dem Internet ist deaktiviert. Sie können diesen Zugriffsmodus implementieren, indem Sie AWS Virtual Private Network (AWS VPN) oder AWS DirectConnect mit der VPC verwenden. 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.

Weitere Informationen zu Konnektivitätsoptionen finden Sie unter Zugreifen auf einen rein privaten API-Server.

AKS-Netzwerkzugriff auf den API-Server

Es gibt zwei Optionen zum Sichern des Netzwerkzugriffs auf die Kubernetes-API in AKS, einen privaten AKS-Cluster oder autorisierte IP-Adressbereiche.

Privater AKS-Cluster

Ein privater AKS-Cluster stellt sicher, dass der Netzwerkdatenverkehr zwischen dem API-Server und den Knotenpools im virtuellen Netzwerk bleibt. In einem privaten AKS-Cluster verfügt der Steuerungsebenen- oder API-Server über eine interne IP-Adresse, die nur über einen privaten Azure-Endpunkt im selben virtuellen Netzwerk zugänglich ist. Jeder virtuelle Computer (VM) im selben virtuellen Netzwerk kann privat über den privaten Endpunkt mit der Steuerungsebene kommunizieren. Der Steuerungsebenen- oder API-Server wird in dem von Azure verwalteten Abonnement gehostet, während sich der AKS-Cluster mit seinen Knotenpools im Abonnement des Kunden befindet.

Das folgende Diagramm veranschaulicht eine private Clusterkonfiguration.

Diagramm eines privaten AKS-Clusters.

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. Optional kann AKS auch einen öffentlichen FQDN mit einem entsprechenden Adresseneintrag (A) in der öffentlichen Azure-DNS-Zone erstellen. 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. Sie können einen privaten Cluster erstellen, wenn Sie Terraform mit Azure, Bicep, ARM-Vorlagen, Azure CLI, ein Azure PowerShell-Modul oder die Azure-REST-API verwenden, um den Cluster zu erstellen.

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, muss sich jede VM, die auf den Server zugreift, z. B. ein selbstgehosteter Azure DevOps-Agent oder ein selbstgehosteter GitHub Actions-Runner, im selben virtuellen Netzwerk befinden, in dem der Cluster gehostet wird, oder in einem Netzwerk, das über Peering virtueller Netzwerke oder ein Site-to-Site-VPN verbunden ist.

Für einen privaten AKS-Cluster deaktivieren Sie den öffentlichen FQDN des API-Servers. Um mit der privaten Steuerungsebene zu kommunizieren, muss sich eine VM im selben virtuellen Netzwerk befinden oder in einem gepeerten virtuellen Netzwerk mit einer virtuellen Netzwerkverbindung mit der privaten DNS-Zone. 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 Azure Kubernetes Service-Clusters.

Optionen für die Bereitstellung privater Cluster

Der AKS-Ressourcenanbieter macht die folgenden Parameter zur Anpassung der Bereitstellung privater AKS-Cluster verfügbar:

  • authorizedIpRanges (string; Zeichenfolge) gibt zulässige IP-Adressbereiche im CIDR-Format an.
  • disableRunCommand (boolesch) gibt an, ob der Befehl run für den Cluster deaktiviert werden soll oder nicht.
  • enablePrivateCluster (boolesch) gibt an, ob der Cluster als „privat“ erstellt werden soll oder nicht.
  • enablePrivateClusterPublicFQDN (boolesch) gibt an, ob ein anderer, öffentlicher FQDN für den privaten Cluster erstellt werden soll oder nicht.
  • privateDnsZone (string; Zeichenfolge) gibt eine private DNS-Zone in der Knotenressourcengruppe an. Wenn Sie keinen Wert angeben, erstellt der Ressourcenanbieter die Zone. Sie können folgende 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.

Die folgende Tabelle zeigt die DNS-Konfigurationsoptionen für die Bereitstellung eines privaten AKS-Clusters:

Optionen für private DNS-Zonen enablePrivateClusterPublicFQDN: true enablePrivateClusterPublicFQDN: false
System Agent-Knoten 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 A-Eintrag der privaten DNS-Zone, um die private IP-Adresse des privaten Endpunkts aufzulösen.

Jede andere VM verwendet den öffentlichen FQDN des API-Servers.		 Agent-Knoten 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 A-Eintrag der privaten DNS-Zone, um die private IP-Adresse des privaten Endpunkts aufzulösen.

Es ist kein öffentlicher FQDN eines API-Servers verfügbar.
None Alle VMs, einschließlich Agent-Knoten, verwenden den öffentlichen FQDN des API-Servers, der über einen A-Eintrag in einer von Azure verwalteten öffentlichen DNS-Zone verfügbar ist. 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> Agent-Knoten 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 A-Eintrag der privaten DNS-Zone, um die private IP-Adresse des privaten Endpunkts aufzulösen.

Alle anderen VMs verwenden den öffentlichen FQDN des API-Servers.		 Agent-Knoten 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 A-Eintrag der privaten DNS-Zone, um die private IP-Adresse des privaten Endpunkts aufzulösen.

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

Konnektivität und Verwaltung privater Cluster

Es gibt mehrere Optionen zum Einrichten der Netzwerkkonnektivität mit dem privaten Cluster.

  • Erstellen Sie virtuelle Computer im selben virtuellen Netzwerk wie dem des AKS-Clusters.

  • Verwenden Sie VMs in einem separaten virtuellen Netzwerk, und richten Sie Peering virtueller Netzwerke mit dem virtuellen Netzwerk des AKS-Clusters ein.

  • Verwenden Sie eine Azure ExpressRoute- oder VPN-Verbindung.

  • Verwenden Sie den Azure CLI-Befehl az aks command invoke, um die Befehle kubectl und helm im privaten Cluster auszuführen, ohne eine direkte Verbindung mit dem Cluster herzustellen.

  • Verwenden Sie eine Verbindung mit einem privaten Azure-Endpunkt.

Sie können einen privaten AKS-Cluster mithilfe des Kubectl-Befehlszeilentools aus einer Verwaltungs-VM im selben virtuellen Netzwerk oder in einem gepeerten virtuellen Netzwerk verwalten.

Sie können Azure Bastion im selben virtuellen Netzwerk oder in einem gepeerten virtuellen Netzwerk verwenden, um eine Verbindung mit einer Jumpbox-Verwaltungs-VM herzustellen. Azure Bastion ist eine vollständig verwaltete Platform-as-a-Service (PaaS), mit der Sie eine Verbindung mit einer VM herstellen können, indem Sie Ihren Browser und das Azure-Portal verwenden. Azure Bastion bietet über das Remotedesktopprotokoll (RDP) oder die Secure Shell (SSH) sichere und nahtlose VM-Konnektivität mittels Transport Layer Security (TLS) direkt über das Azure-Portal. Beim Herstellen einer Verbindung über Azure Bastion benötigen VMs keine öffentliche IP-Adresse, keinen Agent und keine spezielle Clientsoftware.

Sie können auch az aks command invoke verwenden, um auf Ihrem privaten AKS-Cluster den Befehl kubectl oder helm auszuführen, ohne eine Verbindung mit einer Jumpbox-VM herstellen zu müssen.

Autorisierte IP-Adressbereiche

Die zweite Option, um die Clustersicherheit zu verbessern und Angriffe auf den API-Server zu minimieren, besteht darin, autorisierte IP-Adressbereiche zu verwenden. Autorisierte IPs schränken den Zugriff auf die Steuerungsebene eines öffentlichen AKS-Clusters auf eine bekannte Liste von IP-Adressen und CIDRs ein. Wenn Sie diese Option verwenden, ist der API-Server weiterhin öffentlich verfügbar, doch der Zugriff ist eingeschränkt. Weitere Informationen finden Sie unter Sicherer Zugriff auf den API-Server mit autorisierten IP-Adressbereichen in Azure Kubernetes Service (AKS).

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

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

Überlegungen zur AKS-Konnektivität

  • Ein privater AKS-Cluster bietet höhere Sicherheit und Isolation als autorisierte IP-Adressen. Sie können jedoch einen vorhandenen öffentlichen AKS-Cluster nicht in einen privaten Cluster konvertieren. Sie können autorisierte IP-Adressen für jeden vorhandenen AKS-Cluster aktivieren.

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

  • Private Cluster unterstützen keine in Azure DevOps gehosteten Agents. Erwägen Sie die Verwendung selbstgehosteter Agents.

  • Um Azure Container Registry für die Zusammenarbeit mit einem privaten AKS-Cluster zu aktivieren, richten Sie eine private Verbindung für die Container Registry im virtuellen Netzwerk des Clusters ein. Oder richten Sie Peering zwischen dem virtuellen Netzwerk der Container Registry und dem virtuellen Netzwerk des privaten Clusters ein.

  • Die Einschränkungen des Azure Private Link-Diensts gelten für private Cluster.

  • Wenn Sie den privaten Endpunkt im Kundensubnetz eines privaten Clusters löschen oder ändern, funktioniert der Cluster nicht mehr.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

Andere Mitwirkende:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Die folgenden Referenzen bieten Links zu Dokumentationen und Automatisierungsbeispielen zum Bereitstellen von AKS-Clustern mit einer gesicherten API: