Begrenzen Sie den Pod-Datenverkehr mit Kubernetes-Netzwerkrichtlinien. - Amazon EKS
-ÜbersichtStandardnetzwerkrichtlinieNetzwerkrichtlinie für Administratoren (oder Cluster)Wichtige HinweiseÜ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.

Begrenzen Sie den Pod-Datenverkehr mit Kubernetes-Netzwerkrichtlinien.

-Übersicht

Standardmäßig gibt es in Kubernetes keine Einschränkungen für IP-Adressen, Ports oder Verbindungen zwischen Pods in Ihrem Cluster oder zwischen Ihren Pods und Ressourcen in anderen Netzwerken. Sie können die Kubernetes-Netzwerkrichtlinie verwenden, um Netzwerk-Datenerkehr zu und von Ihren Pods einzuschränken. Weitere Informationen finden Sie unter Netzwerk-Richtlinien in der Kubernetes-Dokumentation.

Standardnetzwerkrichtlinie

Sie können den Standard verwendenNetworkPolicy, um den pod-to-pod Verkehr im Cluster zu segmentieren. Diese Netzwerkrichtlinien arbeiten auf den Ebenen 3 und 4 des OSI-Netzwerkmodells, sodass Sie den Datenverkehrsfluss auf IP-Adresse- oder Portebene innerhalb Ihres Amazon EKS-Clusters steuern können. Standardnetzwerkrichtlinien beziehen sich auf die Namespace-Ebene.

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.

Beispiel

In der folgenden Richtlinie ist der ausgehende Datenverkehr aus den Webapp-Pods im Sun-Namespace eingeschränkt.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: webapp-egress-policy
  namespace: sun
spec:
  podSelector:
    matchLabels:
      role: webapp
  policyTypes:
  - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: moon
      podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080
  - to:
    - namespaceSelector:
        matchLabels:
          name: stars
      podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 8080

Die Richtlinie gilt für Pods mit dem Label role: webapp im Namespace. sun

  • Zulässiger Verkehr: Pods mit dem Label role: frontend im moon Namespace am TCP-Port 8080

  • Zulässiger Verkehr: Pods mit der Labelrolle: Frontend im stars Namespace am TCP-Port 8080

  • Blockierter Verkehr: Jeglicher andere ausgehende Datenverkehr von webapp Pods wird implizit verweigert

Netzwerkrichtlinie für Administratoren (oder Cluster)

Abbildung der Bewertungsreihenfolge für Netzwerkrichtlinien in EKS

Sie können den verwendenClusterNetworkPolicy, um einen Netzwerksicherheitsstandard durchzusetzen, 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.

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.

Beispiel

In der folgenden Richtlinie können Sie den Clusterverkehr von anderen Namespaces explizit blockieren, um den Netzwerkzugriff auf einen 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

Wichtige Hinweise

Netzwerkrichtlinien im Amazon VPC CNI-Plugin für Kubernetes werden in den unten aufgeführten Konfigurationen unterstützt.

  • Version 1.21.0 (oder höher) des Amazon VPC CNI-Plug-ins für Standard- und Admin-Netzwerkrichtlinien.

  • Für IPv4- oder IPv6-Adressen konfigurierter Cluster.

  • Sie können Netzwerkrichtlinien mit Sicherheitsgruppen für Pods verwenden. Mit Netzwerkrichtlinien können Sie die gesamte Kommunikation innerhalb eines Clusters steuern. Mit Sicherheitsgruppen für Pods können Sie den Zugriff auf AWS Dienste von Anwendungen innerhalb eines Pods aus steuern.

  • Sie können Netzwerkrichtlinien mit benutzerdefinierten Netzwerken und Präfixdelegierung verwenden.

Überlegungen

Architektur

  • Wenn Sie Netzwerkrichtlinien des Amazon VPC CNI-Plug-ins für Kubernetes mit dem Amazon VPC CNI-Plugin für Kubernetes auf Ihren Cluster anwenden, können Sie die Richtlinien nur auf Amazon Linux-Knoten anwenden. EC2 Sie können nicht in Fargate- oder Windows-Knoten angewendet werden.

  • Netzwerkrichtlinien gelten nur für IPv4- oder IPv6-Adressen, jedoch nicht für beide. In einem IPv4-Cluster weist die VPC CNI den Pods IPv4-Adressen zu und wendet IPv4-Richtlinien an. In einem IPv6-Cluster weist die VPC CNI den Pods IPv6-Adressen zu und wendet IPv6-Richtlinien an. Alle auf einen IPv6-Cluster angewendeten IPv4-Netzwerkrichtlinien werden ignoriert. Alle auf einen IPv4-Cluster angewendeten IPv6-Netzwerkrichtlinien werden ignoriert.

Netzwerkrichtlinien

  • Netzwerkrichtlinien werden ausschließlich auf Pods angewendet, die Teil einer Bereitstellung sind. Auf eigenständige Pods, für die kein metadata.ownerReferences festgelegt ist, können keine Netzwerkrichtlinien angewendet werden.

  • Sie können mehrere Netzwerkrichtlinien auf denselben Pods anwenden. Wenn zwei oder mehr Richtlinien konfiguriert werden, die denselben Pods auswählen, werden alle Richtlinien auf den Pod angewendet.

  • Die maximale Anzahl an Kombinationen aus Ports und Protokollen für einen einzelnen IP-Adressbereich (CIDR) beträgt 24 über alle Ihre Netzwerkrichtlinien hinweg. Selektoren wie die Auflösung zu einem oder mehreren. namespaceSelector CIDRs Wenn mehrere Selektoren zu einem einzigen CIDR führen oder Sie denselben direkten CIDR mehrfach in denselben oder verschiedenen Netzwerkrichtlinien angeben, werden diese alle auf dieses Limit angerechnet.

  • Für jeden Ihrer Kubernetes-Services muss der Port des Services mit dem Port des Containers identisch sein. Wenn Sie benannte Ports verwenden, verwenden Sie denselben Namen auch in der Servicespezifikation.

Netzwerkrichtlinien für Administratoren

  1. Richtlinien auf Admin-Ebene (zuerst bewertet): Alle Richtlinien auf Admin-Ebene ClusterNetworkPolicies werden 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 einer Ablehnungsaktion auf Traffic trifft, wird dieser Verkehr sofort blockiert, unabhängig von anderen Richtlinien. Es werden keine weiteren ClusterNetworkPolicy NetworkPolicy OD-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 Ressourcen mit NetworkPolicy Namespace-Bereich als Nächstes bewertet. Diese Richtlinien ermöglichen eine detaillierte Steuerung innerhalb der einzelnen Namespaces und werden von Anwendungsteams verwaltet. Namespace-bezogene 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. Admin-Richtlinien 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.

Migration

  • Falls Ihr Cluster derzeit eine Drittanbieterlösung zur Verwaltung von Kubernetes-Netzwerkrichtlinien verwendet, können Sie dieselben Richtlinien mit dem Amazon-VPC-CNI-Plugin für Kubernetes nutzen. Sie müssen jedoch Ihre vorhandene Lösung entfernen, damit sie nicht dieselben Richtlinien verwaltet.

Warnung

Wir empfehlen, nach dem Entfernen einer Netzwerkrichtlinienlösung alle Knoten zu ersetzen, auf welche die Netzwerkrichtlinienlösung angewendet wurde. Der Grund dafür ist, dass die Datenverkehrsregeln möglicherweise von einem Pod der Lösung zurückgelassen werden, wenn dieser plötzlich beendet wird.

Installation

  • Das Netzwerkrichtlinienfeature erstellt und erfordert die Definition einer benutzerdefinierten PolicyEndpoint-Ressource (Custom Resource Definition, CRD) namens policyendpoints.networking.k8s.aws. PolicyEndpoint-Objekte der benutzerdefinierten Ressource werden von Amazon EKS verwaltet. Ändern oder löschen Sie diese Ressourcen nicht.

  • Wenn Sie Pods ausführen, die die IAM-Anmeldeinformationen der Instanzrolle verwenden oder eine Verbindung zum EC2 IMDS herstellen, achten Sie darauf, dass Netzwerkrichtlinien den EC2 Zugriff auf das IMDS blockieren würden. Möglicherweise müssen Sie eine Netzwerkrichtlinie hinzufügen, um den Zugriff auf IMDS zu ermöglichen. EC2 Weitere Informationen finden Sie unter Instance-Metadaten und Benutzerdaten im EC2 Amazon-Benutzerhandbuch.

    Pods, die IAM-Rollen für Dienstkonten oder EKS Pod Identity verwenden, greifen nicht auf EC2 IMDS zu.

  • Das Amazon-VPC-CNI-Plugin für Kubernetes wendet keine Netzwerkrichtlinien auf zusätzliche Netzwerkschnittstellen für jeden Pod an, sondern nur auf die primäre Schnittstelle für jeden Pod (eth0). Das hat Auswirkungen auf folgende Architekturen:

    • IPv6-Pods, bei denen die Variable ENABLE_V4_EGRESS auf true festgelegt ist. Diese Variable ermöglicht es der IPv4 Ausgangsfunktion, die IPv6 Pods mit Endpunkten zu verbinden, z. B. mit IPv4 Endpunkten außerhalb des Clusters. Die IPv4 Ausgangsfunktion erstellt eine zusätzliche Netzwerkschnittstelle mit einer lokalen Loopback-Adresse. IPv4

    • Bei Verwendung verketteter Netzwerk-Plugins wie Multus. Da diese Plugins jedem Pod Netzwerkschnittstellen hinzufügen, werden Netzwerkrichtlinien nicht auf die verketteten Netzwerk-Plugins angewendet.