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.

Sicherheitsgruppen pro Pod

Eine AWS Sicherheitsgruppe fungiert als virtuelle Firewall für EC2 Instances zur Steuerung des eingehenden und ausgehenden Datenverkehrs. Standardmäßig verwendet Amazon VPC CNI Sicherheitsgruppen, die der Primärgruppe ENI auf dem Knoten zugeordnet sind. Genauer gesagt hat jede der Instance ENI zugeordnete Instanz dieselben EC2 Sicherheitsgruppen. Somit verwendet jeder Pod auf einem Knoten dieselben Sicherheitsgruppen wie der Knoten, auf dem er ausgeführt wird.

Wie in der Abbildung unten zu sehen ist, haben alle Anwendungs-Pods, die auf Worker-Knoten ausgeführt werden, Zugriff auf den RDS Datenbankdienst (wenn man berücksichtigt, dass RDS eingehende Nachrichten die Knotensicherheitsgruppe zulassen). Sicherheitsgruppen sind zu grob gefasst, da sie für alle Pods gelten, die auf einem Knoten ausgeführt werden. Sicherheitsgruppen für Pods bieten Netzwerksegmentierung für Workloads, was ein wesentlicher Bestandteil einer guten Verteidigungsstrategie ist.

Mit Sicherheitsgruppen für Pods können Sie die Recheneffizienz verbessern, indem Sie Anwendungen mit unterschiedlichen Netzwerksicherheitsanforderungen auf gemeinsam genutzten Rechenressourcen ausführen. Mehrere Arten von Sicherheitsregeln, wie Pod-to-Pod z. B. Pod-to-External AWS Dienste, können mit EC2 Sicherheitsgruppen an einem einzigen Ort definiert und mit Kubernetes Native auf Workloads angewendet werden. APIs Die Abbildung unten zeigt Sicherheitsgruppen, die auf Pod-Ebene angewendet werden, und zeigt, wie sie die Anwendungsbereitstellung und die Knotenarchitektur vereinfachen. Der Pod kann jetzt auf die RDS Amazon-Datenbank zugreifen.

Sie können Sicherheitsgruppen für Pods aktivieren, indem Sie ENABLE_POD_ENI=true für einstellen VPCCNI. Nach der Aktivierung erstellt der VPCResource Controller, der auf der Steuerungsebene läuft (verwaltet vonEKS), eine Trunk-Schnittstelle namens „`aws-k8s-trunk-eni“ und fügt sie dem Knoten hinzu. Die Trunk-Schnittstelle fungiert als Standard-Netzwerkschnittstelle, die an die Instanz angeschlossen ist. Um Trunk-Schnittstellen zu verwalten, müssen Sie die AmazonEKSVPCResourceController verwaltete Richtlinie der Cluster-Rolle hinzufügen, die zu Ihrem EKS Amazon-Cluster gehört.

Der Controller erstellt auch Zweigschnittstellen mit dem Namen „aws-k8s-branch-eni“ und ordnet sie der Trunk-Schnittstelle zu. Den Pods wird mithilfe der SecurityGroupPolicybenutzerdefinierten Ressource eine Sicherheitsgruppe zugewiesen und sie sind einer Branch-Schnittstelle zugeordnet. Da Sicherheitsgruppen mit Netzwerkschnittstellen spezifiziert sind, können wir jetzt Pods planen, für die bestimmte Sicherheitsgruppen auf diesen zusätzlichen Netzwerkschnittstellen erforderlich sind. Lesen Sie den Abschnitt „Sicherheitsgruppen für Pods“ im EKS Benutzerhandbuch, einschließlich der Voraussetzungen für die Bereitstellung.

Die Kapazität der Zweigstellenschnittstelle wird zu den bestehenden Beschränkungen für Instance-Typen für sekundäre IP-Adressen addiert. Pods, die Sicherheitsgruppen verwenden, werden in der Max-Pods-Formel nicht berücksichtigt. Wenn Sie eine Sicherheitsgruppe für Pods verwenden, müssen Sie eine Erhöhung des Max-Pods-Werts in Betracht ziehen oder damit einverstanden sein, weniger Pods auszuführen, als der Knoten tatsächlich unterstützen kann.

Einem m5.large können bis zu 9 Zweignetzwerkschnittstellen und bis zu 27 sekundäre IP-Adressen den Standardnetzwerkschnittstellen zugewiesen werden. Wie im Beispiel unten gezeigt, sind die Standard-Max-Pods für ein m5.large 29, und die Pods, die Sicherheitsgruppen verwenden, werden auf die EKS maximale Anzahl an Pods angerechnet. Anweisungen zum Ändern der EKSMax-Pods für Knoten finden Sie im Benutzerhandbuch.

Wenn Sicherheitsgruppen für Pods in Kombination mit benutzerdefinierten Netzwerken verwendet werden, wird die Sicherheitsgruppe verwendet, die in den Sicherheitsgruppen für Pods definiert ist, und nicht die in der angegebene Sicherheitsgruppe. ENIConfig Wenn benutzerdefinierte Netzwerke aktiviert sind, sollten Sie daher die Reihenfolge der Sicherheitsgruppen sorgfältig prüfen und dabei Sicherheitsgruppen pro Pod verwenden.

Empfehlungen

Deaktivieren Sie TCP Early Demux für Liveness Probe

Wenn Sie Liveness- oder Readiness Probes verwenden, müssen Sie auch TCP Early-Demux deaktivieren, damit das Kubelet über Netzwerkschnittstellen in Zweigstellen eine Verbindung zu Pods herstellen kann. TCP Dies ist nur im strikten Modus erforderlich. Führen Sie dazu den folgenden Befehl aus:

kubectl edit daemonset aws-node -n kube-system

Ändern Sie unter dem initContainer Abschnitt den Wert für DISABLE_TCP_EARLY_DEMUX zu true.

Verwenden Sie Security Group For Pods, um bestehende AWS Konfigurationsinvestitionen optimal zu nutzen.

Sicherheitsgruppen erleichtern die Beschränkung des Netzwerkzugriffs auf VPC Ressourcen wie RDS Datenbanken oder EC2 Instanzen. Ein klarer Vorteil von Sicherheitsgruppen pro Pod ist die Möglichkeit, vorhandene AWS Sicherheitsgruppenressourcen wiederzuverwenden. Wenn Sie Sicherheitsgruppen als Netzwerk-Firewall verwenden, um den Zugriff auf Ihre AWS Dienste einzuschränken, empfehlen wir, Sicherheitsgruppen mithilfe von Branch auf Pods anzuwendenENIs. Erwägen Sie die Verwendung von Sicherheitsgruppen für Pods, wenn Sie Apps von EC2 Instances auf andere AWS Dienste übertragen EKS und den Zugriff auf diese Dienste mit Sicherheitsgruppen einschränken.

Konfigurieren Sie den Modus zur Durchsetzung der Pod-Sicherheitsgruppe

Die VPC CNI Amazon-Plug-in-Version 1.11 hat eine neue Einstellung mit dem Namen POD_SECURITY_GROUP_ENFORCING_MODE („Enforcing Mode“) hinzugefügt. Der Erzwingungsmodus steuert sowohl, welche Sicherheitsgruppen für den Pod gelten, als auch, ob die Quelle NAT aktiviert ist. Sie können den Erzwingungsmodus entweder als strikt oder als Standard angeben. Strict ist die Standardeinstellung und spiegelt das vorherige Verhalten von with wider, das VPC CNI auf ENABLE_POD_ENI true gesetzt wurde.

Im Strict-Modus werden nur die ENI Branch-Sicherheitsgruppen durchgesetzt. Die Quelle NAT ist ebenfalls deaktiviert.

Im Standardmodus werden die Sicherheitsgruppen angewendet, die sowohl dem primären ENI als auch dem Branch ENI (dem Pod zugeordnet) zugeordnet sind. Der Netzwerkverkehr muss beiden Sicherheitsgruppen entsprechen.

Erzwungener Modus: Verwenden Sie den Strict-Modus, um den Pod- und Node-Verkehr zu isolieren:

Standardmäßig ist für Sicherheitsgruppen für Pods der „strikte Modus“ festgelegt. Verwenden Sie diese Einstellung, wenn Sie den Pod-Verkehr vollständig vom restlichen Datenverkehr des Knotens trennen müssen. Im strikten Modus NAT ist die Quelle ausgeschaltet, sodass die ENI ausgehenden Branch-Sicherheitsgruppen verwendet werden können.

Erzwungener Modus: Verwenden Sie den Standardmodus in den folgenden Situationen

Die Client-Quell-IP ist für die Container im Pod sichtbar

Wenn Sie sicherstellen möchten, dass die Client-Quell-IP für die Container im Pod sichtbar bleibt, sollten Sie die Einstellung POD_SECURITY_GROUP_ENFORCING_MODE auf in Erwägung ziehenstandard. Kubernetes-Dienste unterstützen externalTrafficPolicy =local, um die Beibehaltung der Client-Quell-IP zu unterstützen (Standardtyp Cluster). Sie können jetzt Kubernetes-Dienste des Typs NodePort und der LoadBalancer Verwendung von Instanzzielen mit einer externalTrafficPolicy Einstellung auf Lokal im Standardmodus ausführen. Localbehält die Quell-IP des Clients bei und vermeidet einen zweiten Hop für Services LoadBalancer und NodePort den Typ Services.

Bereitstellen NodeLocal DNSCache

Wenn Sie Sicherheitsgruppen für Pods verwenden, konfigurieren Sie den Standardmodus so, dass er Pods unterstützt, die NodeLocal DNSCache NodeLocal DNSCacheverbessert die DNS Clusterleistung, indem ein DNS Caching-Agent auf Clusterknoten als DaemonSet ausgeführt wird. Dies hilft den Pods, die die höchsten DNS QPS Anforderungen haben, lokale Kube-DNS/Core DNS mit einem lokalen Cache abzufragen, was die Latenz verbessert.

NodeLocal DNSCachewird im strikten Modus nicht unterstützt, da der gesamte Netzwerkverkehr, auch der zum Knoten, in den fließt. VPC

Unterstützung der Kubernetes-Netzwerkrichtlinie

Wir empfehlen, den Standard-Erzwingungsmodus zu verwenden, wenn Netzwerkrichtlinien mit Pods verwendet werden, denen Sicherheitsgruppen zugeordnet sind.

Wir empfehlen dringend, Sicherheitsgruppen für Pods zu verwenden, um den Zugriff auf Netzwerkebene auf AWS Dienste zu beschränken, die nicht Teil eines Clusters sind. Ziehen Sie Netzwerkrichtlinien in Betracht, um den Netzwerkverkehr zwischen Pods innerhalb eines Clusters einzuschränken, der häufig als Ost/West-Verkehr bezeichnet wird.

Identifizieren Sie Inkompatibilitäten mit Sicherheitsgruppen pro Pod

Windows-basierte und Nicht-Nitro-Instances unterstützen keine Sicherheitsgruppen für Pods. Um Sicherheitsgruppen mit Pods verwenden zu können, müssen die Instanzen mit gekennzeichnet werden. isTrunkingEnabled Verwenden Sie Netzwerkrichtlinien, um den Zugriff zwischen Pods zu verwalten, anstatt Sicherheitsgruppen, wenn Ihre Pods nicht von AWS Diensten innerhalb oder außerhalb Ihrer abhängig sindVPC.

Verwenden Sie Sicherheitsgruppen pro Pod, um den Datenverkehr zu AWS Diensten effizient zu kontrollieren

Wenn eine Anwendung, die innerhalb des EKS Clusters ausgeführt wird, mit einer anderen Ressource innerhalb des Clusters kommunizieren mussVPC, z. B. mit einer RDS Datenbank, sollten Sie die Verwendung SGs für Pods in Betracht ziehen. Zwar gibt es Policy-Engines, mit denen Sie einen CIDR oder einen DNS Namen angeben können, diese sind jedoch weniger optimal, wenn Sie mit AWS Diensten kommunizieren, deren Endpunkte sich innerhalb eines befinden. VPC

Im Gegensatz dazu bieten Kubernetes-Netzwerkrichtlinien einen Mechanismus zur Steuerung des ein- und ausgehenden Datenverkehrs sowohl innerhalb als auch außerhalb des Clusters. Kubernetes-Netzwerkrichtlinien sollten in Betracht gezogen werden, wenn Ihre Anwendung nur begrenzte Abhängigkeiten von anderen Diensten aufweist. AWS Sie können Netzwerkrichtlinien konfigurieren, die Ausgangsregeln auf der Grundlage von CIDR Bereichen festlegen, um den Zugriff auf AWS Dienste zu beschränken, im Gegensatz zu AWS systemeigener Semantik wie. SGs Sie können Kubernetes-Netzwerkrichtlinien verwenden, um den Netzwerkverkehr zwischen Pods (oft als Ost/West-Verkehr bezeichnet) und zwischen Pods und externen Diensten zu steuern. Kubernetes-Netzwerkrichtlinien werden auf den Stufen 3 und 4 implementiert. OSI

Amazon EKS ermöglicht Ihnen die Verwendung von Netzwerkrichtlinien-Engines wie Calico und Cilium. Standardmäßig sind die Netzwerkrichtlinien-Engines nicht installiert. Anweisungen zur Einrichtung finden Sie in den jeweiligen Installationsanleitungen. Weitere Informationen zur Verwendung von Netzwerkrichtlinien finden Sie unter Bewährte EKS Sicherheitsmethoden. Die Funktion für DNS Hostnamen ist in den Unternehmensversionen der Netzwerkrichtlinien-Engines verfügbar. Sie kann nützlich sein, um den Verkehr zwischen Kubernetes Services/Pods und Ressourcen zu kontrollieren, die außerhalb von ausgeführt werden. AWS Sie können auch die Unterstützung von DNS Hostnamen für AWS Dienste in Betracht ziehen, die standardmäßig keine Sicherheitsgruppen unterstützen.

Kennzeichnen Sie eine einzelne Sicherheitsgruppe, um den AWS Loadbalancer Controller zu verwenden

Wenn einem Pod viele Sicherheitsgruppen zugewiesen sind, EKS empfiehlt Amazon, eine einzelne Sicherheitsgruppe mit kubernetes.io/cluster/$nameShared oder Owned zu kennzeichnen. Das Tag ermöglicht es dem AWS Loadbalancer Controller, die Regeln der Sicherheitsgruppen zu aktualisieren, um den Datenverkehr an die Pods weiterzuleiten. Wenn einem Pod nur eine Sicherheitsgruppe zugewiesen wird, ist die Zuweisung eines Tags optional. In einer Sicherheitsgruppe festgelegte Berechtigungen sind additiv, daher reicht es aus, eine einzelne Sicherheitsgruppe zu kennzeichnen, damit der Loadbalancer-Controller die Regeln finden und abgleichen kann. Es hilft auch, die von Sicherheitsgruppen definierten Standardkontingente einzuhalten.

NATFür ausgehenden Datenverkehr konfigurieren

NATDie Quelle ist für ausgehenden Datenverkehr von Pods deaktiviert, denen Sicherheitsgruppen zugewiesen sind. Für Pods, die Sicherheitsgruppen verwenden, die Zugriff auf das Internet benötigen, starten Sie Worker-Knoten in privaten Subnetzen, die mit einem NAT Gateway oder einer Instance konfiguriert sind, und aktivieren Sie externe Knoten SNAT in. CNI

kubectl set env daemonset -n kube-system aws-node AWS_VPC_K8S_CNI_EXTERNALSNAT=true

Stellen Sie Pods mit Sicherheitsgruppen in privaten Subnetzen bereit

Pods, denen Sicherheitsgruppen zugewiesen sind, müssen auf Knoten ausgeführt werden, die in privaten Subnetzen bereitgestellt werden. Beachten Sie, dass Pods mit zugewiesenen Sicherheitsgruppen, die in öffentlichen Subnetzen bereitgestellt werden, nicht auf das Internet zugreifen können.

Überprüfen Sie die terminationGracePeriodSekunden in der Pod-Spezifikationsdatei

Stellen Sie sicher, terminationGracePeriodSeconds dass dieser Wert in Ihrer Pod-Spezifikationsdatei ungleich Null ist (Standard 30 Sekunden). Dies ist wichtig, damit Amazon VPC CNI das Pod-Netzwerk vom Worker-Knoten löschen kann. Wenn der Wert auf Null gesetzt ist, entfernt das CNI Plugin das Pod-Netzwerk nicht vom Host und der Branch ENI wird nicht effektiv bereinigt.

Verwenden von Sicherheitsgruppen für Pods mit Fargate

Sicherheitsgruppen für Pods, die auf Fargate ausgeführt werden, funktionieren sehr ähnlich wie Pods, die auf EC2 Worker-Knoten ausgeführt werden. Beispielsweise müssen Sie die Sicherheitsgruppe erstellen, bevor Sie sie in dem, den SecurityGroupPolicy Sie Ihrem Fargate-Pod zuordnen, referenzieren. Standardmäßig wird die Cluster-Sicherheitsgruppe allen Fargate-Pods zugewiesen, wenn Sie einem Fargate-Pod nicht explizit a SecurityGroupPolicy zuweisen. Der Einfachheit halber möchten Sie möglicherweise die Cluster-Sicherheitsgruppe zu der eines Fagate-Pods hinzufügen, SecurityGroupPolicy andernfalls müssen Sie Ihrer Sicherheitsgruppe die Mindestsicherheitsgruppenregeln hinzufügen. Sie können die Cluster-Sicherheitsgruppe mithilfe des Describe-Clusters finden. API

 aws eks describe-cluster --name CLUSTER_NAME --query 'cluster.resourcesVpcConfig.clusterSecurityGroupId'

cat >my-fargate-sg-policy.yaml <<EOF
apiVersion: vpcresources.k8s.aws/v1beta1
kind: SecurityGroupPolicy
metadata:
  name: my-fargate-sg-policy
  namespace: my-fargate-namespace
spec:
  podSelector:
    matchLabels:
      role: my-fargate-role
  securityGroups:
    groupIds:
      - cluster_security_group_id
      - my_fargate_pod_security_group_id
EOF

Die Mindestregeln für Sicherheitsgruppen sind hier aufgeführt. Diese Regeln ermöglichen es Fargate Pods, mit Clusterdiensten wie kube-apiserver, kubelet und Core zu kommunizieren. DNS Sie müssen auch Regeln hinzufügen, um eingehende und ausgehende Verbindungen zu und von Ihrem Fargate-Pod zuzulassen. Dadurch kann Ihr Pod mit anderen Pods oder Ressourcen in Ihrem kommunizieren. VPC Darüber hinaus müssen Sie Regeln für Fargate angeben, um Container-Images von Amazon ECR oder anderen Container-Registern abzurufen, z. DockerHub Weitere Informationen finden Sie in der AWSAllgemeinen AWS Referenz unter IP-Adressbereiche.

Sie können die folgenden Befehle verwenden, um die Sicherheitsgruppen zu finden, die auf einen Fargate-Pod angewendet wurden.

kubectl get pod FARGATE_POD -o jsonpath='{.metadata.annotations.vpc\.amazonaws\.com/pod-eni}{"\n"}'

Notieren Sie sich den Befehl eniId von oben.

aws ec2 describe-network-interfaces --network-interface-ids ENI_ID --query 'NetworkInterfaces[*].Groups[*]'

Bestehende Fargate-Pods müssen gelöscht und neu erstellt werden, damit neue Sicherheitsgruppen angewendet werden können. Der folgende Befehl initiiert beispielsweise die Bereitstellung der Beispiel-App. Um bestimmte Pods zu aktualisieren, können Sie den Namespace und den Bereitstellungsnamen im folgenden Befehl ändern.

kubectl rollout restart -n example-ns deployment example-pod

📝 Bearbeiten Sie diese Seite auf GitHub