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 unter, 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. Mithilfe von Kubernetes-Netzwerkrichtlinien können Sie die Netzwerksicherheit für Ihre Kubernetes-Workloads und deren Integration mit clusterexternen Endpunkten verbessern. Der EKS-Automatikmodus unterstützt verschiedene Arten von Netzwerkrichtlinien.

Isolierung der Schichten 3 und 4

Die standardmäßigen Kubernetes-Netzwerkrichtlinien arbeiten auf den Ebenen 3 und 4 des OSI-Netzwerkmodells und ermöglichen es Ihnen, den Verkehrsfluss auf der IP-Adresse- oder Portebene innerhalb Ihres Amazon EKS-Clusters zu steuern.

Anwendungsfälle

DNS-based Durchsetzung

Kunden stellen in der Regel Workloads in EKS bereit, die Teil einer umfassenderen verteilten Umgebung sind, von denen einige mit Systemen und Diensten außerhalb des Clusters kommunizieren müssen (Northbound-Traffic). Diese Systeme und Dienste können sich in der AWS Cloud oder komplett außerhalb befinden AWS . Auf dem Domain Name System (DNS) basierende Richtlinien ermöglichen es Ihnen, Ihre Sicherheitslage zu stärken, indem Sie einen stabileren und vorhersehbareren Ansatz verfolgen, um den unbefugten Zugriff von Pods auf Cluster-externe Ressourcen oder Endpunkte zu verhindern. Durch diesen Mechanismus müssen bestimmte IP-Adressen nicht mehr manuell nachverfolgt und zugelassen werden. Indem Sie Ressourcen mit einem bestimmten DNS-based Ansatz sichern, haben Sie auch mehr Flexibilität bei der Aktualisierung Ihrer externen Infrastruktur, ohne Ihre Sicherheitslage lockern oder Netzwerkrichtlinien aufgrund von Änderungen an den vorgelagerten Servern und Hosts ändern zu müssen. Sie können den 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 clusterexternen Endpunkt zugeordnet sind.

Anwendungsfälle

Admin-Regeln (oder Cluster-Regeln)

In einigen Fällen, wie z. B. bei 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 erweitern, die auf Layer 3, Layer 4 und bei der Verwendung von DNS-Regeln angewendet werden.

Anwendungsfälle

Erste Schritte

Voraussetzungen

Schritt 1: Netzwerkrichtlinien-Controller aktivieren

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

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 Node Class an (optional)

Sie können optional eine neue Node Class erstellen, um das Standardverhalten des Network Policy Agents auf den Knoten zu ändern oder die Protokollierung von Netzwerkrichtlinien-Ereignissen zu aktivieren. Führen Sie dazu die folgenden Schritte aus:

Funktionsweise

DNS-based Netzwerkrichtlinie

Verwenden der Netzwerkrichtlinie für Anwendungen

Die ApplicationNetworkPolicy kombiniert die Funktionen der standardmäßigen Kubernetes-Netzwerkrichtlinien mit DNS-basierter Filterung auf Namespace-Ebene mithilfe einer einzigen benutzerdefinierten Ressourcendefinition (CRD). Daher ApplicationNetworkPolicy kann die verwendet werden für:

Beispiel

In Ihrem EKS-Auto-Mode-Cluster befindet sich eine Arbeitslast, die mit einer lokalen Anwendung kommunizieren muss, die sich hinter einem Load Balancer mit einem DNS-Namen befindet. Sie könnten dies mit 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:
    - ipBlock: { cidr: 10.100.0.10/32 }
    ports:
    - protocol: TCP
      port: 53
    - protocol: UDP
      port: 53
  - to:
    - domainNames:
      - "myapp.mydomain.com"
    ports:
    - protocol: TCP
      port: 8080

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

Bestimmung der CoreDNS-IP-Adresse

Damit Ihre Anwendung DNS auflösen kann, muss sie mit CoreDNS kommunizieren können, das lokal auf jeder EKS-Auto-Mode-Instance ausgeführt wird. Die CoreDNS-IP-Adresse wird aus dem für den Cluster konfigurierten Service-CIDR-Bereich abgeleitet und bleibt für die gesamte Lebensdauer des Clusters unverändert. Sie können sie daher einmal ermitteln und direkt in Ihren Netzwerkrichtlinien darauf verweisen.

Netzwerkrichtlinie für Administratoren (oder Cluster)

Verwendung der Cluster-Netzwerkrichtlinie

Wenn Sie eine verwendenClusterNetworkPolicy, werden die Richtlinien der Admin-Ebene zuerst evaluiert und können nicht außer Kraft gesetzt werden. Wenn die Richtlinien der Admin-Ebene evaluiert wurden, werden die angewendeten Netzwerksegmentierungsregeln anhand der standardmäßigen Richtlinien für den Namespace-Bereich ausgeführt. Dies kann mithilfe von entweder oder erreicht werden. ApplicationNetworkPolicy NetworkPolicy Schließlich werden die Regeln der Basisebene, die die standardmäßigen Netzwerkeinschränkungen für Cluster-Workloads definieren, durchgesetzt. Diese Regeln der Baseline-Ebene 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 Bewertung von Richtlinien

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

Anwendung des Prinzips der geringsten Privilegien

Verwenden von DNS-based Richtlinien in EKS

Validierung Ihrer DNS-Richtlinien

Interaktion mit der Amazon Route 53 DNS-Firewall

Die EKS-Administrations- und Netzwerkrichtlinien werden zuerst auf Pod-Ebene bewertet, wenn der Verkehr initiiert wird. Wenn eine EKS-Netzwerkrichtlinie den Ausgang zu einer bestimmten Domain zulässt, führt der Pod dann eine DNS-Abfrage durch, die den Route 53-Resolver erreicht. Zu diesem Zeitpunkt werden die Route 53-DNS-Firewallregeln 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: DNS-based EKS-Netzwerkrichtlinien bieten Ausgangskontrolle auf Pod-Ebene für anwendungsspezifische Zugriffsanforderungen und mehrinstanzenübergreifende Sicherheitsgrenzen, während die DNS-Firewall VPC-wide Schutz vor bekannten bösartigen Domänen bietet und unternehmensweite Blocklisten durchsetzt.