Bewährte Methoden für die Netzwerksicherheit für Azure Kubernetes Service (AKS)

Kubernetes funktioniert standardmäßig als flaches Netzwerk, in dem alle Pods frei miteinander kommunizieren können. Diese uneingeschränkte Konnektivität kann für Entwickler bequem sein, stellt jedoch erhebliche Sicherheitsrisiken dar, da anwendungen skaliert werden. Stellen Sie sich eine Organisation vor, die mehrere Microservices bereitstellt, wobei vertrauliche Daten, Kundentransaktionen oder Back-End-Vorgänge verarbeitet werden. Ohne Einschränkungen könnte jeder kompromittierte Pod auf nicht autorisierte Daten zugreifen oder Dienste stören.

Die Sicherheit des Produktionsnetzwerks erfordert Kontrollen sowohl für die Arbeitsauslastungskommunikation als auch für die Endpunktexposition. Verwenden Sie Kubernetes-Netzwerkrichtlinien , um den Datenverkehr zwischen Workloads einzuschränken, wählen Sie den Am wenigsten verfügbar gemachten Kubernetes-Diensttyp aus, der die Anforderungen der einzelnen Anwendungen erfüllt, und beschränken Sie den Zugriff auf den Kubernetes-API-Server.

Dienst- und Clustergefährdungen planen

Beginnen Sie mit privatem Zugriff, und fügen Sie öffentliche Gefährdung nur hinzu, wenn die Workload sie erfordert. Netzwerkrichtlinien ergänzen Kubernetes Services, Ingress-Kontrollen, Webanwendungsfirewalls (WAFs) und Zugriffskontrollen für den API-Server, ersetzen diese jedoch nicht.

Verwenden Sie beim Planen eines Produktions-AKS-Clusters die folgenden Anleitungen:

Dienste, die nur innerhalb des Clusters verwendet werden

Empfehlung: Verwenden Sie einen ClusterIP Dienst, bei dem es sich um den Standarddiensttyp handelt.

Wenden Sie Netzwerkrichtlinien für ein- und ausgehenden Datenverkehr an, damit nur autorisierte Pods und Namespaces die Pods hinter dem Dienst erreichen können.

Von einem privaten Netzwerk verwendete Dienste

Empfehlung: Verwenden Sie einen internen LoadBalancer Dienst oder einen internen Eingangscontroller.

Die private IP beschränkt den Zugriff auf Netzwerke, die über Eine Verbindung mit dem virtuellen Netzwerk verfügen. Beschränken Sie auch Quellnetzwerke mit Netzwerksicherheitsgruppen, Firewalls und Netzwerkrichtlinien.

Öffentliche Nicht-HTTP- oder Nicht-HTTPS-Dienste

Empfehlung: Verwenden Sie einen öffentlichen LoadBalancer Dienst nur, wenn ein direkter externer Zugriff erforderlich ist.

Einschränken zulässiger Quell-IP-Bereiche, Verfügbarmachen nur erforderlicher Ports und Vermeiden der Verwendung NodePort als direkter Produktionsrisikomechanismus.

Öffentliche HTTP- oder HTTPS-Anwendungen

Empfehlung: Platzieren Sie Dienste hinter einer Eingangscontroller - oder Gateway-API-Implementierung, anstatt jedem Dienst eine öffentliche IP zuzuweisen.

Zentralisieren Sie TLS-Terminierung, Routing, Authentifizierung und die Verwaltung öffentlicher IP-Adressen. Konfigurieren Sie Backend-Dienste als ClusterIP, wenn kein direkter externer Zugriff erforderlich ist.

Internetorientierte Webanwendungen und APIs

Empfehlung: Platzieren Sie eine Azure Webanwendungsfirewall (WAF) vor der Eingangsebene, z. B. mit Azure Application Gateway für Container.

Verwenden Sie verwaltete und benutzerdefinierte WAF-Regeln, um vor allgemeinen Web-Exploits zu schützen. Beschränken Sie den direkten Zugriff auf den Eingangsursprung, damit Clients die WAF nicht umgehen können.

Kubernetes-API-Server

Empfehlung: Bevorzugen Sie einen privaten AKS-Cluster , wenn Administratoren und Automatisierung eine Verbindung über ein privates Netzwerk herstellen können.

Ein privater Cluster behält API-Serverdatenverkehr auf einem privaten Endpunkt bei. Planen Sie DNS, VPN, ExpressRoute, Peering oder einen gesicherten Verwaltungshost für den Administratorzugriff.

Öffentlicher Kubernetes-API-Server

Empfehlung: Wenn ein öffentlicher Endpunkt erforderlich ist, konfigurieren Sie autorisierte IP-Bereiche des API-Servers, und verwenden Sie Microsoft Entra ID mit RBAC mit geringsten Berechtigungen.

Nur bekannte Management- und Automatisierungs-Quellbereiche zulassen. Lassen Sie den API-Server nicht für alle Quell-IP-Adressen geöffnet. Erwägen Sie die API-Server-VNet-Integration , wenn für das Design eine private Netzwerkkonnektivität erforderlich ist oder der öffentliche Zugriff nach der Clustererstellung geändert wird.

Inventarisieren Sie jeden eingehenden Pfad vor der Bereitstellung und dokumentieren Sie, ob sie clusterintern, privat für verbundene Netzwerke oder öffentlich sein muss. Vermeiden Sie parallele öffentliche Pfade, die die freigegebene Eingangs- und WAF-Schicht umgehen. Reservieren Sie öffentliche IP-Adressen für Endpunkte mit einer dokumentierten Internetzugriffsanforderung, und überprüfen Sie regelmäßig öffentliche LoadBalancerEndpunkte, Eingangs- und API-Serverendpunkte für weitere Anforderungen.

Was ist eine Kubernetes-Netzwerkrichtlinie?

Eine Kubernetes-Netzwerkrichtlinie ist eine Reihe von Regeln, die steuern, wie Pods miteinander und mit externen Diensten kommunizieren. Es bietet eine fein abgestimmte Kontrolle über den Netzwerkdatenverkehr, sodass Administratoren Sicherheit und Segmentierung auf Namespaceebene erzwingen können. Durch die Implementierung von Netzwerkrichtlinien erhalten Sie Folgendes:

• Stärkere Sicherheitslage: Verhindern nicht autorisierter Lateralbewegungen innerhalb des Clusters.
• Compliance und Governance: Erzwingen gesetzlicher Anforderungen durch Steuern von Kommunikationspfaden.
• Reduzierter Strahlradius: Beschränken Sie die Auswirkungen einer kompromittierten Workload, indem Sie den Netzwerkzugriff einschränken.

Netzwerkrichtlinien arbeiteten anfangs auf Schicht 3 (IP) und Schicht 4 (TCP/UDP) des OSI-Modells und ermöglichten eine grundlegende Kontrolle über die Pod-zu-Pod- und die externe Kommunikation. Erweiterte Netzwerkrichtlinienmodule wie Cilium erweitern die Richtlinienerzwingung auf Layer 7 (Anwendungsschicht), wodurch der Anwendungsdatenverkehr für moderne cloudeigene Anwendungen tiefer gesteuert wird.

Netzwerkrichtlinien sind auf einen Namespace beschränkt, was bedeutet, dass jede Richtlinie für Workloads innerhalb eines bestimmten Namespace gilt. Zu den Hauptkomponenten einer Netzwerkrichtlinie gehören:

• Pod-Selektor: Definiert, auf welche Pods die Richtlinie basierend auf Labels angewendet wird.
• Eingangsregeln: Geben Sie die zulässigen eingehenden Verbindungen an.
• Ausgangsregeln: Geben Sie die zulässigen ausgehenden Verbindungen an.
• Richtlinientypen: Legen Sie fest, ob die Richtlinie auf eingehende, ausgehende oder beide angewendet wird.

Grundlagen des Aufbaus effektiver Netzwerkrichtlinien

Effektive Netzwerkrichtlinien erfordern ein Verständnis ihrer Anwendungsarchitektur, Datenverkehrsmuster und Sicherheitsanforderungen vor dem Schreiben von Konfigurationen.

Verstehen Ihrer Arbeitslastkonnektivität

Bevor Sie Netzwerkrichtlinien implementieren, benötigen Sie Einen Einblick in die Kommunikation zwischen Workloads und externen Diensten. Dieser Schritt stellt sicher, dass Richtlinien nicht versehentlich kritischen Datenverkehr blockieren und gleichzeitig unnötige Gefährdungen begrenzen.

• Verwenden Sie Sichtbarkeitstools: Verwenden Sie zusätzlich zu den vom Anwendungsteam bereitgestellten Netzwerkanforderungen Tools wie Cilium Hubble und Retina , um Pod-zu-Pod-Datenverkehr zu analysieren, zu identifizieren, welche Dienste kommunizieren müssen, und definieren Sie ihre Eingangs- und Ausgangsabhängigkeiten. Beispielsweise muss ein Frontend eine Back-End-API erreichen, sollte aber nicht direkt mit einer Datenbank kommunizieren.

• Verwenden Sie Bezeichnungen in Netzwerkrichtlinien: Traditionell basieren Netzwerksicherheitsrichtlinien auf statische IP-Adressen, um Datenverkehrsregeln zu definieren. Dieser Ansatz ist in Kubernetes problematisch, da Pods kurzlebig sind – häufig mit dynamisch zugewiesenen IP-Adressen erstellt und zerstört werden. Die Aufrechterhaltung von Sicherheitsregeln basierend auf ständig sich ändernden IPs erfordert kontinuierliche Updates, wodurch die Richtlinienverwaltung ineffizient und fehleranfällig wird.

Bezeichnungen lösen diese Herausforderung, indem sie eine stabile Möglichkeit zum Gruppieren von Workloads bieten. Anstatt sich auf feste IPs zu verlassen, verwenden Kubernetes-Netzwerkrichtlinien Bezeichnungen, um Sicherheitsregeln zu definieren, die auch dann konsistent bleiben, wenn Pods neu gestartet oder über Knoten verschoben werden. Beispielsweise kann eine Richtlinie die Kommunikation zwischen mit app: frontend und app: backend gekennzeichneten Pods sicherstellen, um Datenverkehrsflüsse unabhängig von Änderungen der IP-Adresse des Pods wie vorgesehen zu gewährleisten. Dieser bezeichnungsbasierte Ansatz ist entscheidend für die Erreichung skalierbarer, absichtsgesteuerter Netzwerksicherheit in cloudeigenen Umgebungen.

Eine gut definierte Bezeichnungsstrategie vereinfacht die Richtlinienverwaltung, reduziert Fehlkonfigurationen und verbessert die Sicherheitserzwingung über Cluster hinweg.

• Definieren von Mikrosegmentierung: Das Organisieren von Workloads in Sicherheitszonen wie Frontend, Back-End und Datenbankzonen trägt dazu bei, das Prinzip der geringsten Berechtigungen zu erzwingen. Isolieren Sie z. B. Microservices, die Kundentransaktionen von allgemeinen Anwendungen verarbeiten.

Mehrschichtiger Sicherheitsansatz für Kubernetes

Die Ausschließliche Verwendung grundlegender Kubernetes-Netzwerkrichtlinien reicht möglicherweise nicht für alle Sicherheitsanforderungen aus. Ein mehrstufiger Ansatz sorgt für umfassenden Schutz auf verschiedenen Ebenen der Netzwerkkommunikation.

• L3/L4-Richtlinien: Steuern des Datenverkehrs basierend auf Podbezeichnungen und Namespaces auf IP-, Port- und Protokollebene.
• FQDN-basierte Richtlinien: Einschränken des Ausgehenden Datenverkehrs auf bestimmte externe Domänen, um sicherzustellen, dass Workloads nur genehmigte externe Dienste erreichen können (z. B. nur Zugriff auf microsoft.com für API-Aufrufe).
• Layer 7-Richtlinien: Filtern von Anforderungen basierend auf HTTP-Methoden, Headern und Pfaden zu sicheren APIs und Erzwingen von Sicherheitsrichtlinien auf Anwendungsebene.

Verwalten von Netzwerkrichtlinien

Die Teams, die Netzwerkrichtlinien verwalten, hängen von der Struktur und den Sicherheitsanforderungen der Organisation ab. Ein ausgewogener Ansatz ermöglicht es Sicherheitsteams und Anwendungsentwicklern, effektiv zusammenzuarbeiten.

• Zentrale Sicherheitsverwaltung: Sicherheits- oder Netzwerkteams sollten grundlegende Richtlinien definieren, um globale Sicherheitsanforderungen zu erzwingen, z. B. standardverweigerungsfreie Regeln oder Compliance-gesteuerte Einschränkungen.
• Entwicklerautonomie mit Schutzmaßnahmen: Anwendungsteams sollten in der Lage sein, dienstspezifische Netzwerkrichtlinien innerhalb ihrer Namespaces zu definieren und dabei Sicherheit zu gewährleisten.
• Richtlinienlebenszyklusverwaltung: Durch regelmäßige Überprüfung und Aktualisierung von Richtlinien wird sichergestellt, dass die Sicherheit weiterhin an sich entwickelnde Anwendungsarchitekturen ausgerichtet bleibt. Observabilitätswerkzeuge können helfen, Fehlkonfigurationen von Richtlinien und fehlende Regeln zu erkennen.

Beispiel: Sichern einer mehrstufigen Webanwendung mit Netzwerkrichtlinien

Schritt 1: Grundlegendes zur Workloadkonnektivität

Verwenden Sie Cilium Hubble, um zu beobachten, wie Pods kommunizieren.

Ordnen Sie die erforderliche Konnektivität zu:

Schritt 2: Anwenden von Bezeichnungen für die Richtlinienerzwingung

Durch die ordnungsgemäße Bezeichnung von Workloads können Richtlinien stabil bleiben, auch wenn sich pod-IPs ändern.

• app: frontend für UI-Pods.
• app: backend für API-Pods.
• app: database für DB-Pods.

Schritt 3: Implementieren von Netzwerkrichtlinien auf Anwendungsebene

In diesem Beispiel werden zwei Ebenen von Netzwerkrichtlinien verwendet: L3/L4-Richtlinien zum Steuern des Datenverkehrs zwischen Microservices und einer vollqualifizierten Domänennamenrichtlinie (FQDN), um den Datenverkehr an ein externes Zahlungsgateway zu steuern.

Zulassen des Frontend-Datenverkehrs zum Back-End

Wenden Sie Richtlinien für den eingehenden und ausgehenden Datenverkehr an, damit Front-End-Pods Back-End-Pods nur über TCP-Port 8080 erreichen können.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 8080
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Back-End-Datenverkehr für die Datenbank zulassen

Wenden Sie Richtlinien für den eingehenden und ausgehenden Datenverkehr an, damit Back-End-Pods Datenbank-Pods nur über TCP-Port 5432 erreichen können.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: database
      ports:
        - protocol: TCP
          port: 5432
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: database-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 5432

Back-End-Datenverkehr zu einer externen Zahlungs-API zulassen

Wenden Sie eine Cilium-Netzwerkrichtlinie an, damit Back-End-Pods payments.example.com auflösen und nur über TCP-Port 443 eine Verbindung dazu herstellen können.

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: backend-payment-api
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: backend
  egress:
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": kube-system
            "k8s:k8s-app": kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: ANY
          rules:
            dns:
              - matchName: payments.example.com
    - toFQDNs:
        - matchName: payments.example.com
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP

Schritt 4: Richtlinien verwalten und pflegen

In der folgenden Tabelle sind die Richtlinienebenen zusammengefasst, die Teams über Cluster hinweg erzwingen sollten.

Stellen Sie sicher, dass Anwendungsnetzwerkrichtlinien die Grundlegenden, Plattform- und Sicherheitsanforderungen erfüllen und gleichzeitig die erforderliche Arbeitsauslastungskommunikation zulassen.

Azure CNI unterstützt von Cilium

Azure Container Network Interface (CNI), das von Cilium unterstützt wird, verwendet eBPF (erweiterter Berkeley Packet Filter), um leistungsstarke Netzwerke, Observability und Sicherheit für Kubernetes-Workloads bereitzustellen. Im Gegensatz zu herkömmlichen CNIs, die abhängig sind von iptables-basierter Paketfilterung, verwendet Azure CNI, das von Cilium unterstützt wird, eBPF, um auf Kernelebene zu arbeiten und effiziente und skalierbare Netzwerkrichtliniendurchsetzung zu ermöglichen. Cilium ist das empfohlene Netzwerkrichtlinienmodul für Linux-Workloads auf Azure Kubernetes Service (AKS). Weitere Informationen zu den anderen unterstützten Engines und deren Plattformunterstützung finden Sie unter "Netzwerkrichtlinienoptionen" in AKS. Azure Kubernetes Service integriert Cilium als verwaltete Komponente und vereinfacht die Durchsetzung der Netzwerksicherheit. Administratoren können Ressourcen direkt in ihren AKS-Clustern definieren CiliumNetworkPolicy , ohne dass externe Controller erforderlich sind.

Cilium-Identitäten erweitern die labelbasierte Durchsetzung von Richtlinien. Große Cluster mit hohem Pod-Churn können Skalierbarkeitsprobleme verursachen, da Knoten ständig IP-Filter aktualisieren müssen. Cilium-Identitäten werden Labels zugeordnet und ermöglichen, dass Verbindungen aufgebaut werden, sobald die Identität aufgelöst ist, ohne auf Filteraktualisierungen auf jedem Knoten warten zu müssen.

Mit Azure von Cilium unterstützten CNI müssen Sie kein separates Netzwerkrichtlinienmodul wie Azure Network Policy Manager oder Calico installieren.

Erstellen eines AKS-Clusters mit Azure CNI unterstützt von Cilium

Im folgenden Beispiel wird ein AKS-Cluster mit Azure CNI-Overlay erstellt, das von Cilium unterstützt wird. Die --network-plugin-mode overlay Option konfiguriert Azure CNI Overlay-Netzwerk, --pod-cidr 192.168.0.0/16 weist den IP-Adressbereich des Pods zu und --network-dataplane cilium wählt Cilium als Datenebene aus. Clustererstellungsoptionen und Adresswerte können sich für andere AKS-Netzwerkkonfigurationen unterscheiden. Verwenden Sie werte, die für Ihre Netzwerkkonfiguration geeignet sind.

az aks create \
  --name <clusterName> \
  --resource-group <resourceGroupName> \
  --location <location> \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --pod-cidr 192.168.0.0/16 \
  --network-dataplane cilium \
  --generate-ssh-keys

Ressourcen und Komponenten für Cilium-Netzwerkrichtlinien

Mit Azure CNI unterstützt von Cilium können Sie Netzwerkrichtlinien systemintern in Kubernetes mit zwei verfügbaren Formaten konfigurieren:

• Die standardmäßige NetworkPolicy-Ressource, die L3- und L4-Richtlinien am Eingang oder Ausgang des Pods unterstützt.
• Das erweiterte CiliumNetworkPolicy-Format, das als CustomResourceDefinition verfügbar ist, die die Spezifikation von Richtlinien auf Layer 3-7 sowohl für den Eingangs- als auch Ausgangsverkehr unterstützt.

Verwenden Sie diese benutzerdefinierten Ressourcendefinitionen (CRDs), um Sicherheitsrichtlinien zu definieren. Kubernetes verteilt die Richtlinien automatisch an alle Knoten im Cluster.

Eine Netzwerkrichtlinie besteht aus mehreren wichtigen Komponenten:

• Pod-Selektor: Gibt an, auf welche Pods die Richtlinie anhand von Labels angewendet wird.

• Richtlinientypen: Bestimmt, ob die Richtlinie auf den eingehenden Datenverkehr, den ausgehenden Datenverkehr oder beides angewendet wird.

• Eingangsregeln: Definiert zulässige Quellen (Pods, Namespaces oder IP-Bereiche) und Ports.

• Ausgangsregeln: Definiert zulässige Ziele und Ports.

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: frontend-egress
    namespace: default
  spec:
    podSelector:
      matchLabels:
        app: frontend
    policyTypes:
      - Egress
    egress:
      - to:
          - podSelector:
              matchLabels:
                app: backend
        ports:
          - protocol: TCP
            port: 8080
  

Erweiterte Netzwerkrichtlinien mit ACNS

Azure Kubernetes Service bietet Advanced Container Networking Services (ACNS), eine Suite von Diensten, die zur Verbesserung der Netzwerkfunktionen von AKS-Clustern entwickelt wurden.

Ein wichtiges Feature von ACNS ist Container Network Security, das erweiterte Sicherheitsfunktionen zum Schutz von containerisierten Workloads bietet. Zu diesen Funktionen gehören vollqualifizierte Domänennamenfilterung (Fully Qualified Domain Name, FQDN) und Layer 7(L7)-Richtlinien für eine präzise Kontrolle über den Datenverkehr und die Kommunikation auf Anwendungsebene.

Container Network Security ist ein kostenpflichtiges Angebot für Linux-Knotenpools, das Azure CNI erfordert, das von Cilium und Kubernetes, Version 1.29 oder höher, unterstützt wird. Preisdetails finden Sie unter Advanced Container Networking Services-Preise.

Sicherer Ausgehender Datenverkehr mit FQDN-Filterung

Traditionell basieren Kubernetes-Netzwerkrichtlinien auf IP-Adressen. In dynamischen Umgebungen, in denen sich Pod-IPs häufig ändern, können diese Richtlinien schwierig verwaltet werden. Mithilfe der FQDN-Filterung können Sie Richtlinien mit Domänennamen anstelle von IP-Adressen definieren, wodurch die Datenverkehrskontrolle vereinfacht wird.

Für die FQDN-Filterung ist ein AKS-Cluster erforderlich, der Azure CNI verwendet, das von Cilium unterstützt wird, Kubernetes, Version 1.29 oder höher, ausführt und ACNS aktiviert hat. Konfigurieren Sie ein CiliumNetworkPolicy, um die Domänen zu definieren, auf die ausgewählten Pods zugreifen können.

Um Advanced Container Networking Services (ACNS) in Azure Kubernetes Service (AKS) zu aktivieren, verwenden Sie das Flag --enable-acns.

Beispiel: Aktivieren erweiterter Containernetzwerkdienste für einen vorhandenen Cluster

az aks update \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --enable-acns

Dieser Befehl ermöglicht ACNS, einschließlich FQDN-Filterung, auf einem vorhandenen Cluster, der die Cilium-Datenebene verwendet.

Beispiel: Erstellen einer Netzwerkrichtlinie, die Datenverkehr zu bing.com und deren Unterdomänen zulässt

Die folgende Richtlinie ermöglicht ausgewählten Pods, bing.com sowie seine Unterdomains aufzulösen und eine Verbindung zu ihnen herzustellen. Die dns-Regeln erlauben die Namensauflösung und die toFQDNs-Regeln erlauben ausgehende Verbindungen zu den aufgelösten Adressen.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "allow-bing-fqdn"
spec:
  endpointSelector:
    matchLabels:
      app: demo-container
  egress:
    - toEndpoints:
        - matchLabels:
            "k8s:io.kubernetes.pod.namespace": kube-system
            "k8s:k8s-app": kube-dns
      toPorts:
        - ports:
            - port: "53"
              protocol: ANY
          rules:
            dns:
              - matchName: "bing.com"
              - matchPattern: "*.bing.com"
    - toFQDNs:
        - matchName: "bing.com"
        - matchPattern: "*.bing.com"

Schutz und Sicherheit für APIs mit L7-Richtlinien

Layer 7(L7)-Richtlinien in AKS verwenden CiliumNetworkPolicy Ressourcen zum Filtern des Anwendungsdatenverkehrs nach Attributen wie HTTP-Methoden und Pfaden, gRPC-Pfaden und Kafka-Themen. Sie setzen ACNS in einem AKS-Cluster voraus, das Azure CNI mit Cilium-Unterstützung verwendet. Standardnetzwerkrichtlinien steuern Datenverkehr bei Layer 3 (IP) und Layer 4 (TCP/UDP), überprüfen diese Attribute auf Anwendungsebene jedoch nicht.

Layer 7 (L7)-Richtlinien bieten die folgenden Vorteile und Features:

• Granulare API-Sicherheit: Erzwingen von Richtlinien basierend auf HTTP-, gRPC- oder Kafka-Anforderungsdaten und nicht nur IP-Adressen und Ports.
• Reduzierte Angriffsfläche: Verhindern Sie nicht autorisierten Zugriff und mindern Sie API-basierte Angriffe, indem Sie den Datenverkehr auf der Anwendungsebene filtern.
• Compliance und Überwachung: Sicherstellen der Einhaltung von Sicherheitsstandards durch Protokollierung und Kontrolle bestimmter API-Interaktionen.
• Vereinfachtes Policy-Management: Vermeiden Sie die betriebliche Überlastung zusätzlicher Sidecar-Proxies, indem Sie integrierte, Cilium-basierte L7-Kontrollen nutzen.

L7-Richtlinien unterstützen HTTP-, HTTPS-, gRPC- und Kafka-Protokolle.

Beispiel: Aktivieren von ACNS- und L7-Richtlinien für einen vorhandenen Cluster

az aks update \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --enable-acns \
  --acns-advanced-networkpolicies L7

Dieser Befehl ermöglicht die Erzwingung von ACNS- und L7-Richtlinien für den vorhandenen Cluster. Das Festlegen von --acns-advanced-networkpolicies auf L7 aktiviert auch die FQDN-Filterung.

Beispiel: Erlaube nur GET-Anfragen an /api vom Frontend-Pod zum Backend-Dienst auf Port 8080.

Die folgende Richtlinie erlaubt ausgewählten Frontend-Pods, nur GET Anfragen an /api über TCP-Port 8080 der ausgewählten Backend-Endpunkte zu senden.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: frontend-l7-policy
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: frontend
  egress:
    - toEndpoints:
        - matchLabels:
            app: backend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api"

Netzwerkrichtlinienstrategien für AKS-Workloads

Die folgenden Strategien tragen dazu bei, Regeln zur geringsten Berechtigung für den Datenverkehr in allen AKS-Workloads durchzusetzen.

Übernehmen eines Zero Trust Modells

Standardmäßig ermöglicht Kubernetes die uneingeschränkte Kommunikation zwischen allen Pods in einem Cluster. Ein Zero Trust Ansatz erfordert, dass Sie den Datenverkehr standardmäßig verweigern und explizit erforderliche Kommunikationspfade zulassen. Eine standardmäßig jeglichen Netzwerkverkehr verweigernde Netzwerkrichtlinie stellt sicher, dass nur notwendiger Datenverkehr zwischen Workloads fließt.

Beispiel für eine Richtlinie „Alles ablehnen”:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Namespace- und Mehrinstanzensegmentierung

In Umgebungen mit mehreren Mandanten helfen Namespaces, Workloads zu isolieren. Unterschiedliche Teams verwalten ihre Anwendungen in der Regel innerhalb dedizierter Namespaces, wodurch eine logische Isolierung zwischen Workloads sichergestellt wird. Diese Trennung ist wichtig, wenn mehrere Anwendungen miteinander ausgeführt werden. Das Anwenden von Netzwerkrichtlinien im Namespacebereich ist häufig der erste Schritt bei der Sicherung von Workloads, da die uneingeschränkte laterale Bewegung zwischen Anwendungen verhindert wird, die von verschiedenen Teams verwaltet werden.

Beschränken Sie z. B. den gesamten Eingehenden Datenverkehr auf einen Namespace, sodass nur Datenverkehr aus demselben Namespace zulässig ist:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-cross-namespace
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: team-a

Mikrosegmentierung für Workloadisolation

Während die namespacebasierte Segmentierung ein wesentlicher erster Schritt bei der Sicherung von Kubernetes-Clustern mit mehreren Mandanten ist, bietet die Mikrosegmentierung auf Anwendungsebene eine differenzierte Kontrolle darüber, wie Workloads innerhalb eines Namespace interagieren. Die Namespaceisolation allein verhindert keine unbeabsichtigte oder nicht autorisierte Kommunikation zwischen verschiedenen Anwendungen innerhalb desselben Namespaces. Hier wird die Segmentierung auf Podebene kritisch.

Wenn beispielsweise ein Frontend-Dienst nur mit einem Back-End-Dienst innerhalb desselben Namespace sprechen sollte, kann eine Richtlinie mit Podbezeichnungen diese Einschränkung erzwingen:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: frontend-to-backend
  namespace: team-a
spec:
  podSelector:
    matchLabels:
      app: frontend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 8080

Dadurch wird verhindert, dass Frontend-Pods unbeabsichtigte Verbindungen mit anderen Diensten herstellen, wodurch das Risiko eines nicht autorisierten Zugriffs oder einer lateralen Bewegung innerhalb des Namespaces verringert wird.

Durch die Kombination der namespaceweiten Isolation mit präzisen Richtlinien auf Anwendungsebene können Teams ein mehrschichtiges Sicherheitsmodell implementieren, das nicht autorisierten Datenverkehr verhindert und gleichzeitig die erforderliche Kommunikation für Anwendungsfunktionen ermöglicht.

Mehrstufiger Sicherheitsansatz

Die Netzwerksicherheit sollte in Ebenen implementiert werden, wobei mehrere Erzwingungsebenen kombiniert werden:

• L3/L4-Richtlinien: Einschränken des Datenverkehrs auf IP- und Portebene (z. B. Zulassen von TCP-Datenverkehr auf Port 443).
• FQDN-basierte Filterung: Einschränken der externen Kommunikation basierend auf Domänennamen und nicht auf IP-Adressen.
• L7-Richtlinien: Steuern der Kommunikation basierend auf Attributen auf Anwendungsebene (z. B. nur HTTP GET-Anforderungen für bestimmte API-Pfade zulassen).

Eine Cilium L7-Richtlinie kann beispielsweise die Frontend-Dienste so einschränken, dass sie nur GET-Anforderungen an die Backend-API senden.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: frontend-l7-policy
  namespace: default
spec:
  endpointSelector:
    matchLabels:
      app: frontend
  egress:
    - toEndpoints:
        - matchLabels:
            app: backend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api"

Dadurch wird verhindert, dass das Frontend POST- oder DELETE-Anforderungen vornimmt, wodurch die Angriffsfläche eingeschränkt wird.

Integrieren von RBAC in die Netzwerkrichtlinienverwaltung

Rollenbasierte Zugriffssteuerung (RBAC) spielt eine wichtige Rolle bei der Sicherstellung, dass nur autorisierte Benutzer oder Teams Netzwerkrichtlinien erstellen, ändern oder löschen können. Ohne ordnungsgemäße Zugriffssteuerungen könnte eine falsch konfigurierte Richtlinie Workloads entweder für nicht autorisierten Zugriff verfügbar machen oder versehentlich kritischen Anwendungsdatenverkehr blockieren.

Durch die Nutzung von Kubernetes RBAC in Verbindung mit Netzwerkrichtlinien können Organisationen die Trennung von Aufgaben zwischen Plattformadministratoren, Sicherheitsteams und Anwendungsentwicklern erzwingen. Ein typischer Ansatz ist:

• Definieren Sie grundlegende Sicherheitsrichtlinien über Plattform- oder Sicherheitsteams, um Compliance zu erzwingen und den externen Zugriff einzuschränken.
• Gewähren Sie Anwendungsteams eingeschränkte Berechtigungen, um Netzwerkrichtlinien nur für ihre jeweiligen Namespaces zu erstellen oder zu aktualisieren.

Mit der folgenden RBAC-Richtlinie können Entwickler beispielsweise Netzwerkrichtlinien erstellen und ändern, jedoch nur innerhalb ihres zugewiesenen Namespaces:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: network-policy-editor
  namespace: team-a
rules:
  - apiGroups: ["networking.k8s.io"]
    resources: ["networkpolicies"]
    verbs: ["get", "list", "create", "update", "delete"]

Binden Sie diese Rolle an ein bestimmtes Team, indem Sie ein RoleBinding verwenden:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: team-a-network-policy-binding
  namespace: team-a
subjects:
  - kind: User
    name: developer@example.com
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: network-policy-editor
  apiGroup: rbac.authorization.k8s.io

Durch das Einschränken von Netzwerkrichtlinienänderungen auf bestimmte Teams und Namespaces können Organisationen versehentliche Fehlkonfigurationen oder nicht autorisierte Änderungen verhindern und gleichzeitig die Flexibilität für Entwickler zur Implementierung anwendungsspezifischer Sicherheitsrichtlinien ermöglichen.

Dieser Ansatz verstärkt das Prinzip der geringsten Rechte und stellt gleichzeitig sicher, dass Strategien zur Netzwerksegmentierung konsistent, sicher und an die Organisationsrichtlinien angepasst bleiben.

Legacy- und Drittanbieterlösungen

Azure Netzwerkrichtlinien-Manager (NPM)

Azure Network Policy Manager (NPM) ist eine Legacylösung zum Erzwingen von Kubernetes-Netzwerkrichtlinien auf AKS.

Für Linux-Knoten empfiehlt Microsoft den Übergang von NPM zu Cilium, das durch die eBPF-basierte Erzwingung eine bessere Leistung, Skalierbarkeit und erhöhte Sicherheit bietet. Anleitungen zur Migration finden Sie unter Upgrade von Azure Netzwerkrichtlinien-Manager auf Cilium.

NetworkPolicy Unterstützung für Windows-Knoten

Azure CNI mit Cilium unterstützt nur Linux-Knoten. Für Windows Workloads unterstützt AKS Calico, das in AKS integriert ist, um die Bereitstellung zu vereinfachen. Sie können es mithilfe des --network-policy calico Flags aktivieren, wenn Sie einen Cluster erstellen. NPM unterstützt auch bis zum 30. September 2026 Windows-Knoten, aber für neue Abonnements kann das zu ihrer Aktivierung erforderliche Feature-Flag nicht mehr registriert werden.

Calico Open Source: Drittanbieterlösung

Calico Open Source ist eine Drittanbieterlösung zum Erzwingen von Kubernetes-Netzwerkrichtlinien unter Linux und Windows Knoten. Tigera pflegt das Calico-Projekt und die Images. Der Microsoft-Support beschränkt sich darauf, sicherzustellen, dass Calico in AKS integriert ist und innerhalb der Plattform wie erwartet funktioniert. Leiten Sie Upstream-Fehler, Featureanforderungen und Probleme, die über die AKS-Integration hinausgehen, an die Calico-Open-Source-Community oder an Tigera.

Für Linux-Knoten empfiehlt Microsoft die Verwendung von Cilium für die Erzwingung von Netzwerkrichtlinien. Für Windows Knoten empfiehlt Microsoft die Verwendung von Calico.

Schlussfolgerung

Netzwerkrichtlinien sind ein grundlegender Bestandteil der Kubernetes-Sicherheit, sodass Organisationen den Datenverkehrsfluss steuern, Workloadisolation erzwingen und die Angriffsfläche reduzieren können. Da sich cloudnative Umgebungen entwickeln, reicht die Ausschließliche Verwendung grundlegender Layer 3/4-Richtlinien nicht mehr aus. Erweiterte Lösungen wie Layer 7-Filter- und FQDN-basierte Richtlinien bieten die granulare Sicherheit und Flexibilität, die zum Schutz moderner Anwendungen erforderlich ist.

Durch die Umsetzung von Praktiken wie einem Zero-Trust-Modell und Mikrosegmentierung sowie durch die Einführung von Azure CNI auf Basis von Cilium können Teams die Sicherheit verbessern und gleichzeitig die betriebliche Effizienz aufrechterhalten. Moderne, auf Observability basierende Ansätze helfen dabei, Workloads zu sichern, während sich die Vernetzung in Kubernetes weiterentwickelt.