Verwendung von Netzwerkrichtlinien mit EKS Auto Mode - Amazon EKS
-ÜbersichtErste SchritteFunktionsweiseÜberlegungen

Unterstützung für die Verbesserung dieser Seite beitragen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten auf, der sich im rechten Bereich jeder Seite befindet.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Verwendung von Netzwerkrichtlinien mit EKS Auto Mode

-Übersicht

Da Kunden ihre Anwendungsumgebungen mithilfe von EKS skalieren, wird die Isolierung des Netzwerkverkehrs immer wichtiger, um unbefugten Zugriff auf Ressourcen innerhalb und außerhalb des Clusters zu verhindern. Dies ist besonders wichtig in einer Umgebung mit mehreren Mandanten, in der mehrere voneinander unabhängige Workloads nebeneinander im Cluster ausgeführt werden. Mit Kubernetes-Netzwerkrichtlinien können Sie die Netzwerksicherheit für Ihre Kubernetes-Workloads und deren Integrationen mit clusterexternen Endpunkten verbessern. Der automatische Modus von EKS unterstützt verschiedene Arten von Netzwerkrichtlinien.

Isolierung der Schichten 3 und 4

Standard-Kubernetes-Netzwerkrichtlinien arbeiten auf den Ebenen 3 und 4 des OSI-Netzwerkmodells und ermöglichen Ihnen die Steuerung des Datenverkehrs auf IP-Adresse- oder Portebene innerhalb Ihres Amazon EKS-Clusters.

Anwendungsfälle

  • Segmentieren Sie den Netzwerkverkehr zwischen Workloads, um sicherzustellen, dass nur verwandte Anwendungen miteinander kommunizieren können.

  • Isolieren Sie Mandanten auf Namespace-Ebene mithilfe von Richtlinien, um die Netzwerktrennung durchzusetzen.

DNS-basierte Durchsetzung

Kunden stellen in der Regel Workloads in EKS bereit, die Teil einer breiteren verteilten Umgebung sind, von denen einige mit Systemen und Diensten außerhalb des Clusters kommunizieren müssen (Northbound-Verkehr). Diese Systeme und Dienste können sich in der AWS Cloud oder ganz außerhalb befinden AWS . Mit DNS-basierten Richtlinien (Domain Name System) können Sie Ihre Sicherheitslage verbessern, indem Sie einen stabileren und vorhersehbareren Ansatz verfolgen, um unbefugten Zugriff von Pods auf clusterexterne Ressourcen oder Endpunkte zu verhindern. Durch diesen Mechanismus entfällt die Notwendigkeit, bestimmte IP-Adressen manuell zu verfolgen und aufzulisten. Durch die Sicherung von Ressourcen mit einem DNS-basierten Ansatz haben Sie auch mehr Flexibilität bei der Aktualisierung der externen Infrastruktur, ohne dass Sie Ihre Sicherheitslage lockern oder die Netzwerkrichtlinien ändern müssen, wenn sich Änderungen an vorgelagerten Servern und Hosts ergeben. Sie können ausgehenden Datenverkehr zu externen Endpunkten entweder mithilfe eines vollqualifizierten Domänennamens (FQDN) oder eines passenden Musters für einen DNS-Domainnamen filtern. Dies bietet Ihnen die zusätzliche Flexibilität, den Zugriff auf mehrere Subdomänen zu erweitern, die einem bestimmten externen Cluster-Endpunkt zugeordnet sind.

Anwendungsfälle

  • Verwenden Sie standardmäßig einen DNS-basierten Ansatz zur Filterung des Zugriffs von einer Kubernetes-Umgebung auf clusterexterne Endpunkte.

  • Sicherer Zugriff auf Dienste in einer Umgebung mit mehreren Mandanten. AWS

  • Verwalten Sie den Netzwerkzugriff von Pods auf lokale Workloads in Ihren Hybrid-Cloud-Umgebungen.

Administratorregeln (oder Clusterregeln)

In einigen Fällen, z. B. in Szenarien mit mehreren Mandanten, müssen Kunden möglicherweise einen Netzwerksicherheitsstandard durchsetzen, der für den gesamten Cluster gilt. Anstatt wiederholt eine eigene Richtlinie für jeden Namespace zu definieren und zu verwalten, können Sie eine einzige Richtlinie verwenden, um die Netzwerkzugriffskontrollen für verschiedene Workloads im Cluster unabhängig von ihrem Namespace zentral zu verwalten. Mit diesen Richtlinientypen können Sie den Umfang der Durchsetzung Ihrer Netzwerkfilterregeln, die auf Ebene 3, Schicht 4 und bei der Verwendung von DNS-Regeln angewendet werden, erweitern.

Anwendungsfälle

  • Verwalten Sie die Netzwerkzugriffskontrollen für alle (oder eine Teilmenge von) Workloads in Ihrem EKS-Cluster zentral.

  • Definieren Sie einen standardmäßigen Netzwerksicherheitsstatus für den gesamten Cluster.

  • Erweitern Sie die organisatorischen Sicherheitsstandards auf betrieblich effizientere Weise auf den gesamten Clusterbereich.

Erste Schritte

Voraussetzungen

  • Ein Amazon-EKS-Cluster mit aktiviertem EKS Auto Mode

  • Kubectl für die Verbindung mit Ihrem Cluster konfiguriert

Schritt 1: Netzwerkrichtlinien-Controller aktivieren

Um Netzwerkrichtlinien mit dem automatischen EKS-Modus verwenden zu können, müssen Sie zunächst den Network Policy Controller aktivieren, indem Sie a ConfigMap auf Ihren Cluster anwenden.

  1. Erstellen Sie eine Datei mit dem Namen enable-network-policy.yaml und dem folgenden Inhalt:

    apiVersion: v1
kind: ConfigMap
metadata:
  name: amazon-vpc-cni
  namespace: kube-system
data:
  enable-network-policy-controller: "true"

  2. Wenden Sie das ConfigMap auf Ihren Cluster an:

    kubectl apply -f enable-network-policy.yaml

Schritt 2: Netzwerkrichtlinien erstellen und testen

Ihr EKS-Auto-Mode-Cluster ist nun für den Support von Kubernetes-Netzwerkrichtlinien konfiguriert. Sie können dies mit Stars-Demo der Netzwerkrichtlinie für Amazon EKS testen.

Schritt 3: Passen Sie die Konfiguration des Network Policy Agents in der Knotenklasse an (optional)

Sie können optional eine neue Knotenklasse erstellen, um das Standardverhalten des Network Policy Agent auf den Knoten zu ändern oder die Protokollierung von Netzwerkrichtlinienereignissen zu aktivieren. Führen Sie dazu die folgenden Schritte aus:

  1. Erstellen oder bearbeiten Sie eine Knotenklassen-YAML-Datei (z. B. nodeclass-network-policy.yaml) mit dem folgenden Inhalt:

    apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
  name: network-policy-config
spec:
  # Optional: Changes default network policy behavior
  networkPolicy: DefaultAllow
  # Optional: Enables logging for network policy events
  networkPolicyEventLogs: Enabled
  # Include other Node Class configurations as needed

  2. Wenden Sie die Knotenklassen-Konfiguration auf Ihren Cluster an:

    kubectl apply -f nodeclass-network-policy.yaml

  3. Überprüfen Sie, ob die Knotenklasse erstellt wurde:

    kubectl get nodeclass network-policy-config

  4. Aktualisieren Sie Ihren Knoten-Pool, um diese Knotenklasse zu verwenden. Weitere Informationen finden Sie unter Einen Knotenpool für EKS Auto Mode erstellen.

Funktionsweise

DNS-basierte Netzwerkrichtlinie

Veranschaulichung des Workflows, wenn eine DNS-basierte Richtlinie in EKS Auto angewendet wird
Abbildung des Workflows, wenn eine DNS-basierte Richtlinie in EKS Auto angewendet wird

  1. Das Plattformteam wendet eine DNS-basierte Richtlinie auf den EKS-Cluster an.

  2. Der Network Policy Controller ist dafür verantwortlich, die Erstellung von Richtlinien innerhalb des Clusters zu überwachen und anschließend die Richtlinienendpunkte abzustimmen. In diesem Anwendungsfall weist der Netzwerkrichtlinien-Controller den Node-Agent an, DNS-Anfragen auf der Grundlage der Domänen zu filtern, die in der erstellten Richtlinie zugelassen sind. Domänennamen werden mithilfe des FQDN oder eines Domainnamens, der einem in der Kubernetes-Ressourcenkonfiguration definierten Muster entspricht, auf die Zulassungsliste gesetzt.

  3. Workload A versucht, die IP für einen clusterexternen Endpunkt aufzulösen. Die DNS-Anfrage durchläuft zunächst einen Proxy, der solche Anfragen anhand der in der Netzwerkrichtlinie festgelegten Zulassungsliste filtert.

  4. Sobald die DNS-Anfrage die Zulassungsliste des DNS-Filters durchlaufen hat, wird sie an CoreDNS weitergeleitet.

  5. CoreDNS wiederum sendet die Anfrage an den externen DNS-Resolver (Amazon Route 53 Resolver), um die Liste der IP-Adressen hinter dem Domainnamen abzurufen.

  6. Die IPs mit TTL aufgelösten Daten werden in der Antwort auf die DNS-Anfrage zurückgegeben. Diese IPs werden dann in eine eBPF-Map geschrieben, die im nächsten Schritt für die Durchsetzung der IP-Schicht verwendet wird.

  7. Die an die Pod-Veth-Schnittstelle angeschlossenen eBPF-Sonden filtern dann den ausgehenden Datenverkehr von Workload A zum clusterexternen Endpunkt auf der Grundlage der geltenden Regeln. Dadurch wird sichergestellt, dass Pods nur clusterexternen Datenverkehr an die aufgelisteten Domänen senden können. IPs Ihre Gültigkeit IPs basiert auf der TTL, die vom externen DNS-Resolver (Amazon Route 53 Resolver) abgerufen wurde.

Verwendung der Anwendungsnetzwerkrichtlinie

Die ApplicationNetworkPolicy kombiniert die Funktionen von Standard-Kubernetes-Netzwerkrichtlinien mit DNS-basierter Filterung auf Namespace-Ebene unter Verwendung einer einzigen Custom Resource Definition (CRD). Daher ApplicationNetworkPolicy kann der verwendet werden für:

  1. Definition von Einschränkungen auf den Ebenen 3 und 4 des Netzwerkstapels mithilfe von IP-Blöcken und Portnummern.

  2. Definition von Regeln, die auf Schicht 7 des Netzwerkstapels angewendet werden, und ermöglichen es Ihnen, den Datenverkehr anhand dieser Kriterien zu filtern FQDNs.

Wichtiger Hinweis: DNS-basierte Regeln, die mithilfe von definiert wurden, ApplicationNetworkPolicy gelten nur für Workloads, die in im EKS Auto Mode gestarteten Instances ausgeführt werden. EC2

Beispiel

Sie haben einen Workload in Ihrem EKS-Auto-Mode-Cluster, der mit einer lokalen Anwendung kommunizieren muss, die sich hinter einem Load Balancer mit einem DNS-Namen befindet. Sie könnten dies mithilfe der folgenden Netzwerkrichtlinie erreichen:

apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
  name: my-onprem-app-egress
  namespace: galaxy
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
  - Egress
  egress:
  - to:
    - domainNames:
      - "myapp.mydomain.com"
    ports:
    - protocol: TCP
      port: 8080

Auf Kubernetes-Netzwerkebene würde dies den Ausgang von allen Pods im „Galaxy“ -Namespace ermöglichen, die mit gekennzeichnet sind, role: backend um eine Verbindung zum Domainnamen myapp.mydomain.com am TCP-Port 8080 herzustellen. Darüber hinaus müssten Sie die Netzwerkkonnektivität für den ausgehenden Datenverkehr von Ihrer VPC zu Ihrem Unternehmensrechenzentrum einrichten.

Abbildung der Arbeitslast in EKS Automatische Kommunikation mit Anwendungen vor Ort

Netzwerkrichtlinie für Administratoren (oder Cluster)

Abbildung der Bewertungsreihenfolge für Netzwerkrichtlinien in EKS

Verwendung der Cluster-Netzwerkrichtlinie

Bei Verwendung von werden die Richtlinien der Admin-Ebene zuerst bewertet und können nicht außer Kraft gesetzt werden. ClusterNetworkPolicy Wenn die Richtlinien auf Admin-Ebene evaluiert wurden, werden die angewendeten Netzwerksegmentierungsregeln anhand der standardmäßigen Namespace-Richtlinien ausgeführt. Dies kann entweder mit oder erreicht werden. ApplicationNetworkPolicy NetworkPolicy Schließlich werden die Baseline-Tier-Regeln, die die Standard-Netzwerkeinschränkungen für Cluster-Workloads definieren, durchgesetzt. Diese Regeln der Baseline-Stufe können bei Bedarf durch die Richtlinien für den Namespace-Bereich außer Kraft gesetzt werden.

Beispiel

Sie haben eine Anwendung in Ihrem Cluster, die Sie von anderen Mandanten-Workloads isolieren möchten. Sie können den Clusterverkehr von anderen Namespaces explizit blockieren, um den Netzwerkzugriff auf den sensiblen Workload-Namespace zu verhindern.

apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
  name: protect-sensitive-workload
spec:
  tier: Admin
  priority: 10
  subject:
    namespaces:
      matchLabels:
        kubernetes.io/metadata.name: earth
  ingress:
    - action: Deny
      from:
      - namespaces:
          matchLabels: {} # Match all namespaces.
      name: select-all-deny-all

Überlegungen

Verstehen Sie die Reihenfolge der Richtlinienbewertung

Die in EKS unterstützten Funktionen für Netzwerkrichtlinien werden in einer bestimmten Reihenfolge bewertet, um ein vorhersehbares und sicheres Datenverkehrsmanagement zu gewährleisten. Daher ist es wichtig, den Bewertungsablauf zu verstehen, um eine effektive Netzwerksicherheit für Ihre Umgebung zu entwickeln.

  1. Richtlinien auf Admin-Ebene (zuerst bewertet): ClusterNetworkPolicies Die gesamte Admin-Ebene wird vor allen anderen Richtlinien bewertet. Innerhalb der Admin-Ebene werden Richtlinien in der Reihenfolge ihrer Priorität verarbeitet (Nummer mit der niedrigsten Priorität zuerst). Der Aktionstyp bestimmt, was als Nächstes passiert.

    • Aktion ablehnen (höchste Priorität): Wenn eine Admin-Richtlinie mit der Aktion „Ablehnen“ dem Verkehr entspricht, wird dieser Verkehr sofort blockiert, unabhängig von allen anderen Richtlinien. Es werden keine weiteren ClusterNetworkPolicy NetworkPolicy Regeln verarbeitet. Dadurch wird sichergestellt, dass unternehmensweite Sicherheitskontrollen nicht durch Richtlinien auf Namespace-Ebene außer Kraft gesetzt werden können.

    • Aktion zulassen: Nach der Auswertung der Ablehnungsregeln werden Administratorrichtlinien mit Zulassen-Aktionen in der Reihenfolge ihrer Priorität verarbeitet (die niedrigste Priorität zuerst). Wenn eine Aktion „Zulassen“ zutrifft, wird der Datenverkehr akzeptiert und es findet keine weitere Richtlinienbewertung statt. Diese Richtlinien können auf der Grundlage von Label-Selektoren Zugriff auf mehrere Namespaces gewähren und ermöglichen so eine zentrale Kontrolle darüber, welche Workloads auf bestimmte Ressourcen zugreifen können.

    • Aktion weiterleiten: Bei der Weiterleitung von Aktionen in den Richtlinien der Admin-Ebene wird die Entscheidungsfindung an untergeordnete Ebenen delegiert. Wenn der Traffic mit einer Pass-Regel übereinstimmt, werden bei der Evaluierung alle verbleibenden Regeln auf Admin-Ebene für diesen Traffic übersprungen und direkt zur NetworkPolicy Stufe weitergeleitet. Auf diese Weise können Administratoren die Kontrolle über bestimmte Datenverkehrsmuster explizit an Anwendungsteams delegieren. Sie können beispielsweise Pass-Regeln verwenden, um die Verwaltung des Datenverkehrs innerhalb des Namespaces an Namespace-Administratoren zu delegieren und gleichzeitig strenge Kontrollen des externen Zugriffs aufrechtzuerhalten.

  2. Netzwerkrichtlinienebene: Wenn keine Richtlinie auf Admin-Ebene mit „Verweigern“ oder „Zulassen“ übereinstimmt oder wenn eine Pass-Aktion gefunden wurde, werden als Nächstes Ressourcen mit ApplicationNetworkPolicy Namespace-Bereich und herkömmliche Ressourcen bewertet. NetworkPolicy Diese Richtlinien ermöglichen eine detaillierte Steuerung innerhalb der einzelnen Namespaces und werden von Anwendungsteams verwaltet. Namespace-Richtlinien können nur restriktiver sein als Admin-Richtlinien. Sie können die Ablehnungsentscheidung einer Admin-Richtlinie nicht außer Kraft setzen, aber sie können den Datenverkehr weiter einschränken, der durch Admin-Richtlinien zugelassen oder weitergeleitet wurde.

  3. Administratorrichtlinien der Baseline-Stufe: Wenn keine Admin- oder Namespace-bezogenen Richtlinien dem Traffic entsprechen, wird die Baseline-Stufe bewertet. ClusterNetworkPolicies Diese bieten standardmäßige Sicherheitsvorkehrungen, die durch Richtlinien im Namespace-Bereich außer Kraft gesetzt werden können. So können Administratoren unternehmensweite Standardeinstellungen festlegen und den Teams gleichzeitig die Flexibilität geben, sie nach Bedarf anzupassen. Basisrichtlinien werden in der Reihenfolge ihrer Priorität bewertet (niedrigste Priorität zuerst).

  4. Standardverweigerung (wenn keine Richtlinien zutreffen): Dieses deny-by-default Verhalten stellt sicher, dass nur explizit zugelassene Verbindungen zugelassen werden, wodurch ein hohes Maß an Sicherheit gewährleistet wird.

Anwendung des Prinzips der geringsten Rechte

  • Beginnen Sie mit restriktiven Richtlinien und fügen Sie nach Bedarf schrittweise Berechtigungen hinzu. Implementieren Sie zunächst deny-by-default Richtlinien auf Clusterebene und fügen Sie dann schrittweise Zulassungsregeln hinzu, wenn Sie legitime Konnektivitätsanforderungen überprüfen. Dieser Ansatz zwingt die Teams, jede externe Verbindung ausdrücklich zu begründen, wodurch eine sicherere und überprüfbarere Umgebung geschaffen wird.

  • Regelmäßige Überprüfung und Entfernung ungenutzter Richtlinienregeln — Netzwerkrichtlinien können sich im Laufe der Zeit ansammeln, wenn sich Anwendungen weiterentwickeln, sodass veraltete Regeln zurückbleiben, die Ihre Angriffsfläche unnötig erweitern. Führen Sie einen regelmäßigen Überprüfungsprozess durch, um nicht mehr benötigte Richtlinienregeln zu identifizieren und zu entfernen. So stellen Sie sicher, dass Ihre Sicherheitsvorkehrungen weiterhin streng und durchführbar sind.

  • Verwenden Sie nach Möglichkeit spezifische Domainnamen statt allgemeiner Muster. Platzhaltermuster wie z. B. *.amazonaws.com bieten zwar Komfort, gewähren aber auch Zugriff auf eine breite Palette von Diensten. Geben Sie, wann immer möglich, genaue Domainnamen an, z. B. s3.us-west-2.amazonaws.com um den Zugriff nur auf die spezifischen Dienste zu beschränken, die Ihre Anwendungen benötigen, wodurch das Risiko einer seitlichen Verlagerung verringert wird, wenn eine Arbeitslast beeinträchtigt wird.

Verwendung von DNS-basierten Richtlinien in EKS

  • DNS-basierte Regeln, die mithilfe von definiert wurden, ApplicationNetworkPolicy gelten nur für Workloads, die in im automatischen Modus von EKS gestarteten Instanzen ausgeführt werden. EC2 Wenn Sie einen Cluster im gemischten Modus ausführen (der sowohl aus EKS Auto- als auch aus Nicht-EKS Auto-Worker-Knoten besteht), sind Ihre DNS-basierten Regeln nur in den EKS-Workerknoten im automatischen Modus (verwaltete Instanzen) wirksam. EC2

Validierung Ihrer DNS-Richtlinien

  • Verwenden Sie zum Testen Staging-Cluster, die die Topologie des Produktionsnetzwerks widerspiegeln. Ihre Staging-Umgebung sollte die Netzwerkarchitektur, die externen Abhängigkeiten und die Konnektivitätsmuster der Produktion replizieren, um genaue Richtlinientests zu gewährleisten. Dazu gehören passende VPC-Konfigurationen, DNS-Auflösungsverhalten und Zugriff auf dieselben externen Dienste, die Ihre Produktions-Workloads benötigen.

  • Implementieren Sie automatisierte Tests für kritische Netzwerkpfade — Erstellen Sie automatisierte Tests, die die Konnektivität zu wichtigen externen Diensten als Teil Ihrer CI/CD Pipeline validieren. Mit diesen Tests sollte überprüft werden, ob legitime Datenströme zulässig sind, während nicht autorisierte Verbindungen blockiert werden. Auf diese Weise soll kontinuierlich überprüft werden, ob Ihre Netzwerkrichtlinien bei der Weiterentwicklung Ihrer Infrastruktur den richtigen Sicherheitsstatus beibehalten.

  • Überwachen Sie das Anwendungsverhalten nach Richtlinienänderungen — Nach der Implementierung neuer oder geänderter Netzwerkrichtlinien in der Produktion sollten Sie die Anwendungsprotokolle, Fehlerraten und Leistungskennzahlen genau überwachen, um Verbindungsprobleme schnell zu identifizieren. Richten Sie klare Rollback-Verfahren ein, damit Sie Richtlinienänderungen schnell rückgängig machen können, falls sie zu unerwartetem Anwendungsverhalten oder Betriebsunterbrechungen führen.

Interaktion mit der Amazon Route 53 DNS-Firewall

Die Admin- und Netzwerkrichtlinien von EKS werden zunächst auf Pod-Ebene bewertet, wenn der Datenverkehr initiiert wird. Wenn eine EKS-Netzwerkrichtlinie den Ausgang zu einer bestimmten Domäne zulässt, führt der Pod dann eine DNS-Abfrage durch, die den Route 53 53-Resolver erreicht. Zu diesem Zeitpunkt werden die DNS-Firewallregeln für Route 53 ausgewertet. Wenn die DNS-Firewall die Domänenabfrage blockiert, schlägt die DNS-Auflösung fehl und die Verbindung kann nicht hergestellt werden, obwohl die EKS-Netzwerkrichtlinie dies zulässt. Dadurch entstehen ergänzende Sicherheitsebenen: Die DNS-basierten Netzwerkrichtlinien von EKS bieten Ausgangskontrolle auf Pod-Ebene für anwendungsspezifische Zugriffsanforderungen und mehrinstanzenfähige Sicherheitsgrenzen, während die DNS-Firewall VPC-weiten Schutz vor bekannten bösartigen Domänen bietet und unternehmensweite Blocklisten durchsetzt.