View a markdown version of this page

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 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.

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-zu-Pod-Verkehr im Cluster zu segmentieren. Diese 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. 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 von 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 dem Label role: frontend im stars Namespace am TCP-Port 8080

  • Blockierter Verkehr: Jeglicher anderer ausgehender Verkehr von webapp Pods wird implizit verweigert

Netzwerkrichtlinie für Administratoren (oder Cluster)

Abbildung der Bewertungsreihenfolge für Netzwerkrichtlinien in EKS

Sie können das 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 eine Standardsicherheitslage für das Netzwerk im 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 vertraulichen 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 Administratornetzwerkrichtlinien.

  • 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 für Amazon-VPC-CNI-Plugin für Kubernetes auf Ihren Cluster mit dem Amazon-VPC-CNI-Plugin für Kubernetes anwenden, können Sie die Richtlinien nur auf Amazon-EC2-Linux-Knoten anwenden. Sie können nicht in Fargate- oder Windows-Knoten angewendet werden.

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

Netzwerkrichtlinien

  • Amazon EKS optimiert die Durchsetzung von Netzwerkrichtlinien für Pods, für die ein Feld festgelegt ist. metadata.ownerReferences Dazu gehören Pods, die von Controllern wie Deployments, StatefulSets DaemonSets, Jobs und verwaltet werden. CronJobs Eigenständige Pods, die direkt ohne Controller erstellt wurden, haben kein metadata.ownerReferences Set, und die Durchsetzung von Netzwerkrichtlinien funktioniert für diese Pods möglicherweise nicht zuverlässig.

  • 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 namespaceSelector werden in einen oder mehrere CIDRs aufgelöst. 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 evaluiert): Alle Admin-Stufen ClusterNetworkPolicies werden vor allen anderen Richtlinien evaluiert. Innerhalb der Admin-Ebene werden Richtlinien in der Reihenfolge ihrer Priorität verarbeitet (niedrigste Priorität zuerst). Der Aktionstyp bestimmt, was als Nächstes passiert.

    • Aktion verweigern (höchste Priorität): Wenn eine Admin-Richtlinie mit der Aktion Verweigern einem Datenverkehr entspricht, wird dieser Verkehr unabhängig von anderen Richtlinien sofort blockiert. 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 Bewertung der Ablehnungsregeln werden Administratorrichtlinien mit Aktionen vom Typ Zulassen in der Reihenfolge ihrer Priorität verarbeitet (niedrigste Priorität zuerst). Wenn die Aktion „Zulassen“ zutrifft, wird der Datenverkehr akzeptiert und es erfolgt keine weitere Überprüfung der Richtlinien. Diese Richtlinien können auf der Grundlage von Label-Selektoren Zugriff auf mehrere Namespaces gewähren. So können Sie zentral steuern, welche Workloads auf bestimmte Ressourcen zugreifen können.

    • Weiterleiten von Maßnahmen: Übergeben Sie Aktionen in Richtlinien auf Admin-Ebene, um Entscheidungen an niedrigere Ebenen zu delegieren. Wenn der Traffic einer Pass-Regel entspricht, überspringt die Evaluierung alle verbleibenden Regeln der Admin-Stufe für diesen Traffic und geht direkt zur NetworkPolicy Stufe über. Auf diese Weise können Administratoren die Kontrolle über bestimmte Datenverkehrsmuster explizit an Anwendungsteams delegieren. Beispielsweise können Sie Pass-Regeln verwenden, um die Verwaltung des namespace-internen Datenverkehrs an Namespace-Administratoren zu delegieren und gleichzeitig den externen Zugriff strikt zu kontrollieren.

  2. Netzwerkrichtlinienebene: Wenn keine Richtlinie auf Admin-Ebene mit Verweigern oder Zulassen übereinstimmt oder wenn eine Pass-Aktion zutrifft, werden als Nächstes Ressourcen für den NetworkPolicy Namespace-Bereich ausgewertet. Diese Richtlinien ermöglichen eine detaillierte Steuerung innerhalb einzelner Namespaces und werden von Anwendungsteams verwaltet. Namespace-scoped Richtlinien können nur restriktiver sein als Administratorrichtlinien. Sie können die Ablehnungsentscheidung einer Admin-Richtlinie nicht außer Kraft setzen, aber sie können den Traffic, der durch Admin-Richtlinien zugelassen oder weitergegeben wurde, weiter einschränken.

  3. Administratorrichtlinien auf Basisebene: Wenn keine Richtlinien für Administratoren oder Namespaces dem Traffic entsprechen, wird die Basisstufe evaluiert. ClusterNetworkPolicies Diese bieten Standardsicherheitsmaßnahmen, die durch Richtlinien im Namespace-Bereich außer Kraft gesetzt werden können, sodass Administratoren unternehmensweite Standardeinstellungen festlegen können, während die Teams die Flexibilität haben, sie nach Bedarf anzupassen. Grundlegende Richtlinien werden in der Reihenfolge ihrer Priorität bewertet (niedrigste Priorität zuerst).

  4. Standardverweigerung (wenn keine Richtlinien übereinstimmen): Dieses standardmäßige Ablehnungsverhalten stellt sicher, dass nur explizit zugelassene Verbindungen zugelassen werden, wodurch ein hohes Sicherheitsniveau 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 Instance-Rolle verwenden oder eine Verbindung mit EC2 IMDS herstellen, achten Sie auf Netzwerkrichtlinien, die den Zugriff auf EC2 IMDS blockieren würden. Möglicherweise müssen Sie eine Netzwerkrichtlinie hinzufügen, um den Zugriff auf EC2 IMDS zu ermöglichen. Weitere Informationen finden Sie unter Instance-Metadaten und Benutzerdaten im Amazon EC2-Benutzerhandbuch für Linux-Instances.

    Pods, die IAM-Rollen für Servicekonten oder EKS Pod Identityverwenden, haben keinen Zugriff auf EC2 IMDS.

  • 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, eine Verbindung zwischen den IPv6-Pods und IPv4-Endpunkten (beispielsweise außerhalb des Clusters) herzustellen. Die IPv4-Ausgangsfunktion erstellt eine zusätzliche Netzwerkschnittstelle mit einer lokalen IPv4-Loopback-Adresse.

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