Private Kubernetes-Cluster in der Azure Public Cloud – Teil 1: Architektur 

Öffentlich zugängliche Dienste – ein gefährlicher Standard? 

Public Cloud Provider bieten Unternehmen die Möglichkeit, innerhalb kürzester Zeit Kubernetes-Cluster bereitzustellen und zu nutzen. Der Zugriff auf diese Cluster kann genau wie bei vielen anderen Public Cloud-Diensten über öffentliche oder private Endpunkte erfolgen. Während öffentliche Endpunkte für jeden Internetnutzer ansprechbar sind, lassen sich private nur aus unternehmensinternen Netzwerken erreichen. Viele Cloud-Dienste sehen den öffentlichen Zugang als Standardeinstellung vor. Die Nutzung von privaten Endpunkten muss also explizit durch Endnutzer:innen eingerichtet werden. Wie die Vergangenheit zeigt, sind öffentliche Endpunkte oft die Grundlage für Angriffe auf Unternehmen, wie zum Beispiel im Falle des Unternehmens Accenture im Jahr 2017. Die Nutzung von privaten Endpunkten stellt daher eine sinnvolle Maßnahme zur Verkleinerung der Angriffsfläche dar. 

Voreinstellungen des Azure Kubernetes Service im Azure Portal 

Auch der Azure Kubernetes Service (AKS) aus dem Hause Microsoft verfügt im Standard über einen öffentlichen Endpunkt. Bei der Erstellung eines AKS-Clusters über das Azure-Portal können unterschiedliche Clustervoreinstellungen für die Clusterkonfiguration gewählt werden. Die Voreinstellung „Produktionsstandard“ (engl. „Production Standard“) sieht vor, dass der API-Server des Clusters über einen öffentlichen Endpunkt erreichbar ist. Dies gilt auch für alle weiteren Voreinstellungen, bis auf die Voreinstellung „Produktionsunternehmen“ (engl. „Production Enterprise“). Diese ist laut Microsoft „am besten geeignet für große Unternehmen, welche die vollständige Kontrolle über Sicherheit und Stabilität benötigen“ (siehe Screenshot aus dem Azure Portal).

Auch verschiedene Tutorials in der Dokumentation von Microsoft enthalten die Erstellung eines Kubernetes-Clusters mit öffentlich zugänglichem API-Servern, wie zum Beispiel der Artikel  „Schnellstart: Bereitstellen eines AKS-Clusters (Azure Kubernetes Service) über das Azure-Portal“.

Den Zugriff auf den API-Server auf Netzwerkebene einzuschränken, empfiehlt sich unabhängig von der Größe des Unternehmens. Dem „Defense in depth“-Prinzip folgend kann hierdurch eine Sicherheitsschicht etabliert werden, die beispielsweise vor unbefugtem Zugriff im Falle kompromittierter Zugangsdaten schützen kann. Darüber hinaus könnensowohl eingehende als auch ausgehende Netzwerkzugriffe auf weiteren Ebenen eingeschränkt und/oder reglementiert werden.

 Absicherung eines AKS-Clusters auf Netzwerkebene

In dieser Artikelreihe betrachten wir unterschiedliche Ansatzpunkte für die Absicherung eines AKS-Clusters auf Netzwerkebene.

Die ersten drei Teile der Artikelreihe widmen sich dem Kubernetes API-Server. In Teil 4 und 5 werden weitere Aspekte, die über die Absicherung des API-Servers hinausgehen, betrachtet.

• Teil 1: Architektur von privaten AKS-Clustern
• Teil 2: Provisionierung der Infrastruktur
• Teil 3: Continuous Deployment
• Teil 4: Private Anwendungen
• Teil 5: Reglementierung des Datenverkehrs

Architektur von privaten AKS-Clustern 

Merkmale eines privaten AKS-Clusters

An dieser Stelle betrachten wir zunächst, durch welche Merkmale sich ein privater Cluster auszeichnet. Microsoft bezeichnet einen AKS-Cluster als privat, wenn der Endpunkt des API-Servers nicht öffentlich, sondern ausschließlich innerhalb eines Azure Virtual Networks erreichbar ist. Diese Methode zur Einschränkung des Zugriffs ist seit April 2020 allgemein verfügbar.

Diese Artikelreihe erweitert die Definition um weitere Aspekte. Neben dem API-Server können beispielsweise auch die Anwendungen, die im Cluster betrieben werden, über öffentliche oder über private Endpunkte angesprochen werden. Ein vollständig privater Cluster enthält ausschließlich Anwendungen, die über private Endpunkte verfügen.

Darüber hinaus sollten auch ausgehende Verbindungen nicht über einen beliebigen öffentlichen Endpunkt erfolgen, sondern zunächst zu einer zentral verwalteten Firewall geroutet werden und von dieser über klar definierte Endpunkte nach extern geleitet werden. Durch diese Vorgehensweise werden alle notwendigen eingehenden und ausgehenden Verbindungen ermöglicht. Zusätzlich dazu wird verhindert, dass der AKS-Cluster selbst über öffentliche IP-Adressen verfügt oder auf andere Netzwerkressourcen (z. B. Azure Load Balancer) zurückgreift, über die ein direkter (nicht reglementierter) Zugriff aus dem Internet bzw. in das Internet möglich ist.

Insgesamt soll der AKS-Cluster also ohne öffentliche IP-Adressen auskommen und sämtlicher Netzwerkverkehr über private und reglementierte Netzwerkwege ablaufen.

Beispiel-Architektur eines privaten AKS-Clusters

Überblick

Um die zuvor beschriebenen Merkmale zu veranschaulichen, beschreibt dieser Abschnitt ein häufiges Szenario, in dem mehrere AKS-Cluster eingesetzt werden. Die Architektur wird auf folgendem Schaubild dargestellt.

Netzwerktopologie

In diesem hybriden Szenario wird ein Unternehmensnetzwerk („on-premises“) über eine VPN-Verbindung an ein Netzwerk in Azure (das „Hub-Netzwerk“) angebunden. Dieses Netzwerk ist wiederum über Peerings an weitere Netzwerke („Spoke-Netzwerke“) angebunden, um Verbindungen vom lokalen Unternehmensnetzwerk in diese Netze und umgekehrt zu ermöglichen. Diese Netzwerktopologie wird auch als „Hub-Spoke-Netzwerktopologie“ bezeichnet und kann als Best Practice beschrieben werden, die auch von Microsoft empfohlen wird.

In dem dargestellten Szenario enthält das Hub-Netzwerk zentrale Netzwerkkomponenten, die von verschiedenen anderen Systemen für die Netzwerkkonnektivität genutzt werden. Hierzu zählen ein Virtual Network Gateway für die VPN-Verbindung und eine Firewall für die Überwachung und Reglementierung des Netzwerkverkehrs. Des Weiteren befinden sich im Hub-Netzwerk eine Container Registry, die über einen privaten Endpunkt (engl. „Private Endpoint“) an das Netzwerk angebunden ist, und ein Private DNS Resolver für die Namensauflösung von privaten Endpunkten.

An das Hub-Netzwerk werden mehrere Spoke-Netzwerke angebunden. In dem Architekturschaubild werden folgende Spoke-Netzwerke dargestellt:

Auf der rechten Seite befinden sich zwei AKS-Cluster, jeweils in einem eigenen dafür vorgesehenen Netzwerk. Mit Hilfe der beiden Cluster werden eine Testumgebung und eine produktive Umgebung realisiert. Die Master Nodes der Cluster werden als Teil des Managed Service von Azure verwaltet und sind als solche nicht für Endnutzer:innen sichtbar. Die Worker Nodes werden hingegen selbst verwaltet und basieren hier auf Virtual Machine Scale Sets. Der Zugriff auf den Kubernetes API-Server erfolgt über einen privaten Endpunkt.

Auf der linken Seite befindet sich ein separates Spoke-Netzwerk, das für Agents eines CI/CD-Tools (z. B. Azure DevOps oder GitLab) vorgesehen ist. Diese Agents werden beispielsweise für automatisierte Deployments in die AKS-Cluster genutzt.

Namensauflösung mit Hilfe von privaten DNS-Zonen

Die dargestellten Netzwerke sind jeweils mit privaten DNS-Zonen verknüpft, sodass die Namen von privaten Endpunkten zu privaten IP-Adressen aufgelöst werden können. 

Der Kubernetes API-Server jedes Azure Kubernetes Service Clusters soll aus verschiedenen Netzwerken über dessen privaten Endpunkt erreichbar sein:

1. Deployments mit Hilfe der links eingezeichneten CI/CD-Agents
2. Zugriff durch Entwickler:innen aus dem lokalen Unternehmensnetzwerk („on-premises“)

Da es nicht möglich ist, mit einem Netzwerk mehrere private DNS-Zonen mit demselben Namen zu verknüpfen, müssen die DNS-Zonen einmalig angelegt und dann mit mehreren Netzwerken verknüpft werden. Dadurch kann beispielsweise die private DNS-Zone „privatelink.germanywestcentral.azmk8s.io“ für mehrere Cluster genutzt werden. Durch die Verknüpfung der Zone mit dem Netzwerk, in dem sich die CI/CD-Agents befinden, können diese die Namen der Kubernetes API-Server auflösen und dann über das Hub-Netzwerk darauf zugreifen.

Der Private DNS Resolver im Hub-Netzwerk dient als DNS Forwarder, der DNS-Anfragen aus dem lokalen Unternehmensnetzwerk entgegennimmt und diese an einen Azure Nameserver weiterleitet. Auf dem lokalen DNS-Server innerhalb des Unternehmensnetzwerks können beispielsweise bedingte Weiterleitungen konfiguriert werden, sodass alle DNS-Anfragen für die Zonen „test.myapp.com“ und „myapp.com“ an den Private DNS Resolver in Azure weitergeleitet werden. Dadurch wird die Namensauflösung für private Endpunkte in Azure auch aus dem lokalen Unternehmensnetzwerk ermöglicht, sodass beispielsweise Entwickler:innen zu Testzwecken auf den jeweiligen Kubernetes API-Server zugreifen können.

 IP-Adressfilter als Alternative zu privaten Endpunkten

In dem zuvor beschriebenen Szenario verfügen die API-Server der AKS-Cluster ausschließlich über private Endpunkte, sodass der Zugriff aus dem Internet gänzlich ausgeschlossen wird. Alternativ hierzu gibt es weitere Möglichkeiten zur Einschränkung des Zugriffs auf den API-Server.

Zum einen besteht die Möglichkeit, den API-Server über einen öffentlichen Endpunkt zu nutzen, jedoch die zugelassenen IP-Adressbereiche einzuschränken, sodass Anfragen aus allen anderen IP-Adressbereichen blockiert werden. Diese Methode ist seit November 2019 allgemein verfügbar und bietet den Vorteil, dass die vergleichsweise komplexere Architektur, die sich bei der Nutzung von privaten AKS-Clustern ergibt, vermieden werden kann. Hierdurch reduziert sich beispielsweise der Aufwand für die Bereitstellung von AKS-Clustern und für Deployments in die Cluster. Diese Methode sollte in jedem Falle angewendet werden, falls der API-Server über einen öffentlichen Endpunkt erreichbar ist. Eine Herausforderung hierbei ist jedoch die Definition der zugelassenen IP-Adressbereiche, da unter Umständen von vielen unterschiedlichen und variablen Adressen auf den API-Server zugegriffen werden soll.

Zum anderen kann der API-Server mit Hilfe eines internen Load Balancers in einem delegierten Subnetz erreichbar gemacht werden. Diese als „VNet Integration“ bezeichnete Methode befindet sich seit Juli 2022 in der Phase „öffentliche Vorschau“ und ist zum Zeitpunkt der Erstellung dieses Artikels noch nicht allgemein verfügbar. Daher wird diese Methode in dieser Artikelreihe zunächst nicht näher betrachtet.

Zusammenfassung 

Der erste Teil dieser Artikelreihe beschreibt anhand einer Beispiel-Architektur, welche Merkmale einen privaten Kubernetes-Cluster in Azure ausmachen und wie die verschiedenen Ressourcen miteinander zusammenhängen. Auf dieser Grundlage betrachtet der nächste Teil der Reihe, wie die Infrastruktur für private Kubernetes-Cluster in Azure bereitgestellt werden kann und welche Fallstricke hierbei zu beachten sind.

Quellen

1. https://denniszielke.medium.com/fully-private-aks-clusters-without-any-public-ips-finally-7f5688411184
2. https://learn.microsoft.com/en-us/azure/aks/outbound-rules-control-egress
3. https://learn.microsoft.com/en-us/azure/aks/limit-egress-traffic
4. https://learn.microsoft.com/en-us/azure/architecture/guide/security/access-azure-kubernetes-service-cluster-api-server