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 das Amazon VPC CNI Sicherheitsgruppen, die der primären ENI auf dem Knoten zugeordnet sind. Genauer gesagt wird jede ENI, die der Instance zugeordnet ist, dieselben EC2-Sicherheitsgruppen haben. 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 betrieben werden, Zugriff auf den RDS-Datenbankdienst (wobei die Sicherheitsgruppe „RDS Inbound Allows Node“ berücksichtigt). Sicherheitsgruppen sind zu grobkörnig, da sie für alle Pods gelten, die auf einem Knoten laufen. Sicherheitsgruppen für Pods bieten eine Netzwerksegmentierung für Workloads, was ein wesentlicher Bestandteil einer guten Strategie zur umfassenden Verteidigung ist.

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

Sie können Sicherheitsgruppen für Pods aktivieren, indem Sie VPC CNI einrichtenENABLE_POD_ENI=true. Nach der Aktivierung erstellt der VPC Resource Controller, der auf der Steuerungsebene läuft (von EKS verwaltet), eine Trunk-Schnittstelle namens „`aws-k8s-trunk-eni"` und hängt sie an den Knoten an. Die Trunk-Schnittstelle fungiert als Standard-Netzwerkschnittstelle, die an die Instance angeschlossen ist. Um Trunk-Schnittstellen zu verwalten, müssen Sie die AmazonEKSVPCResourceController verwaltete Richtlinie der Cluster-Rolle hinzufügen, die zu Ihrem Amazon EKS-Cluster gehört.

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

Die Kapazität der Zweigstellenschnittstelle kommt zu den bestehenden Grenzwerten für Instance-Typen für sekundäre IP-Adressen hinzu. Pods, die Sicherheitsgruppen verwenden, werden in der Max-Pods-Formel nicht berücksichtigt. Wenn Sie eine Sicherheitsgruppe für Pods verwenden, müssen Sie erwägen, den Max-Pods-Wert zu erhöhen, oder Sie können damit einverstanden sein, weniger Pods auszuführen, als der Knoten tatsächlich unterstützen kann.

Ein m5.large kann über bis zu 9 Zweigstellen-Netzwerkschnittstellen und bis zu 27 sekundäre IP-Adressen verfügen, die seinen Standard-Netzwerkschnittstellen zugewiesen sind. Wie im Beispiel unten gezeigt, ist die Standard-Max-Pods für einen m5.large 29, und EKS zählt die Pods, die Sicherheitsgruppen verwenden, zu den maximalen Pods. Anweisungen zum Ändern der Max-Pods für Nodes finden Sie im EKS-Benutzerhandbuch.

Wenn Sicherheitsgruppen für Pods in Kombination mit benutzerdefinierten Netzwerken verwendet werden, wird die in den Sicherheitsgruppen für Pods definierte Sicherheitsgruppe anstelle der in der ENIConfig angegebenen Sicherheitsgruppe verwendet. Wenn benutzerdefinierte Netzwerke aktiviert sind, sollten Sie daher die Reihenfolge der Sicherheitsgruppen sorgfältig prüfen, während Sie Sicherheitsgruppen pro Pod verwenden.

Empfehlungen

Deaktivieren Sie TCP Early Demux für Liveness Probe

Wenn Sie Liveness- oder Readiness-Probes verwenden, müssen Sie außerdem den TCP-Early-Demux deaktivieren, damit das Kubelet über TCP eine Verbindung zu Pods auf den Netzwerkschnittstellen der Zweigstellen herstellen kann. 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 in true.

Verwenden Sie Security Group For Pods, um bestehende Investitionen in die AWS-Konfiguration zu nutzen.

Sicherheitsgruppen erleichtern die Beschränkung des Netzwerkzugriffs auf VPC-Ressourcen wie RDS-Datenbanken oder EC2-Instances. 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-Services einzuschränken, schlagen wir vor, mithilfe von Branch-ENIs Sicherheitsgruppen auf Pods anzuwenden. Erwägen Sie die Verwendung von Sicherheitsgruppen für Pods, wenn Sie Apps von EC2-Instances auf EKS übertragen und den Zugriff auf andere AWS-Services mit Sicherheitsgruppen einschränken.

Konfigurieren Sie den Erzwingungsmodus für Pod-Sicherheitsgruppen

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

Im Strict-Modus werden nur die ENI-Sicherheitsgruppen der Branch durchgesetzt. Das Quell-NAT ist ebenfalls deaktiviert.

Im Standardmodus werden die Sicherheitsgruppen angewendet, die sowohl der primären ENI als auch der Branch-ENI (die dem Pod zugeordnet ist) zugeordnet sind. Der Netzwerkverkehr muss den Anforderungen beider Sicherheitsgruppen entsprechen.

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

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

Erzwingungsmodus: Verwenden Sie den Standardmodus in den folgenden Situationen

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

Wenn Sie die Client-Quell-IP für die Container im Pod sichtbar halten müssen, sollten Sie die Einstellung POD_SECURITY_GROUP_ENFORCING_MODE auf in Betracht ziehenstandard. Kubernetes-Dienste unterstützen external TrafficPolicy =local, um die Beibehaltung der Client-Quell-IP zu unterstützen (Standardtyp-Cluster). Sie können jetzt Kubernetes-Dienste vom Typ NodePort und LoadBalancer unter Verwendung von Instanzzielen ausführen, wobei die externe Option im Standardmodus auf Lokal TrafficPolicy gesetzt ist. Localbehält die Client-Quell-IP bei und vermeidet einen zweiten Hop für LoadBalancer und NodePort den Typ Services.

DNSCache bereitstellen NodeLocal

Wenn Sie Sicherheitsgruppen für Pods verwenden, konfigurieren Sie den Standardmodus so, dass Pods unterstützt werden, die DNSCache verwenden NodeLocal . NodeLocal DNSCache verbessert die Cluster-DNS-Leistung, indem ein DNS-Caching-Agent auf Clusterknoten als ausgeführt wird. DaemonSet Dies hilft den Pods, die die höchsten DNS-QPS-Anforderungen haben, bei der Abfrage des lokalen Kubes, dns/CoreDNS da sie über einen lokalen Cache verfügen, was die Latenz verbessert.

NodeLocal DNSCache wird im strikten Modus nicht unterstützt, da der gesamte Netzwerkverkehr, auch zum Knoten, in die VPC gelangt.

Unterstützung der Kubernetes-Netzwerkrichtlinie

Wir empfehlen, den Standard-Durchsetzungsmodus zu verwenden, wenn Sie Netzwerkrichtlinien mit Pods verwenden, denen Sicherheitsgruppen zugeordnet sind.

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

Identifizieren Sie Inkompatibilitäten mit Sicherheitsgruppen pro Pod

Windows-based und Nicht-Nitro-Instances unterstützen keine Sicherheitsgruppen für Pods. Um Sicherheitsgruppen mit Pods verwenden zu können, müssen die Instanzen mit is gekennzeichnet werden. TrunkingEnabled Verwenden Sie Netzwerkrichtlinien, um den Zugriff zwischen Pods statt Sicherheitsgruppen zu verwalten, wenn Ihre Pods nicht von AWS-Services innerhalb oder außerhalb Ihrer VPC abhängen.

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

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

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 AWS-Services hat. Sie können Netzwerkrichtlinien konfigurieren, die Ausgangsregeln auf der Grundlage von CIDR-Bereichen festlegen, um den Zugriff auf AWS-Services im Gegensatz zu systemeigenen AWS-Semantiken wie SGs einzuschränken. Sie können Kubernetes-Netzwerkrichtlinien verwenden, um den Netzwerkverkehr zwischen Pods (oft als East/West Verkehr bezeichnet) und zwischen Pods und externen Diensten zu steuern. Die Kubernetes-Netzwerkrichtlinien werden auf den OSI-Ebenen 3 und 4 implementiert.

Mit Amazon EKS können Sie Netzwerkrichtlinien-Engines wie Calico und Cilium verwenden. https://docs.cilium.io/en/stable/intro/ 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 Best Practices von EKS Security. Die Funktion für DNS-Hostnamen ist in den Unternehmensversionen der Network Policy Engines verfügbar. Sie kann für die Steuerung des Datenverkehrs zwischen Kubernetes Services/Pods und Ressourcen, die außerhalb von AWS ausgeführt werden, nützlich sein. Sie können auch die Unterstützung von DNS-Hostnamen für AWS-Services in Betracht ziehen, die standardmäßig keine Sicherheitsgruppen unterstützen.

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

Wenn einem Pod viele Sicherheitsgruppen zugewiesen sind, empfiehlt Amazon EKS, eine einzelne Sicherheitsgruppe mit kubernetes.io/cluster/$name Shared 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.

Konfigurieren Sie NAT für ausgehenden Verkehr

Quell-NAT ist für ausgehenden Datenverkehr von Pods, denen Sicherheitsgruppen zugewiesen sind, deaktiviert. 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 NAT-Instance konfiguriert sind, und aktivieren Sie externes SNAT im 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.

Verify Kündigung GracePeriodSeconds in der Pod-Spezifikationsdatei

Stellen Sie sicher, terminationGracePeriodSeconds dass in Ihrer Pod-Spezifikationsdatei ein Wert ungleich Null ist (standardmäßig 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 die Branch-ENI wird nicht effektiv bereinigt.

Verwendung 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 Dokument, das SecurityGroupPolicy Sie Ihrem Fargate-Pod zuordnen, referenzieren. Standardmäßig wird die Cluster-Sicherheitsgruppe allen Fargate-Pods zugewiesen, wenn Sie sie nicht explizit einem SecurityGroupPolicy Fargate-Pod zuweisen. Der Einfachheit halber möchten Sie die Cluster-Sicherheitsgruppe vielleicht 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 der Describe-Cluster-API finden.

 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. https://docs.aws.amazon.com/eks/latest/userguide/sec-group-reqs.html Diese Regeln ermöglichen es Fargate Pods, mit Cluster-internen Diensten wie Kube-Apiserver, Kubelet und CoreDNS zu kommunizieren. Sie müssen auch Regeln hinzufügen, um eingehende und ausgehende Verbindungen zu und von Ihrem Fargate Pod zu ermöglichen. Dadurch kann Ihr Pod mit anderen Pods oder Ressourcen in Ihrer VPC kommunizieren. Darüber hinaus müssen Sie Regeln angeben, damit Fargate Container-Images aus Amazon ECR oder anderen Container-Registern abrufen kann, z. B. DockerHub Weitere Informationen finden Sie unter AWS-IP-Adressbereiche in der allgemeinen AWS-Referenz.

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

kubectl get pod FARGATE_POD -o jsonpath='{.metadata.annotations.fargate\.amazonaws\.com/pod-sg}{"\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 mit dem folgenden Befehl ändern.

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