Standardmäßige Calico- und Kubernetes-Netzrichtlinien

Wenn ein Cluster mit einem öffentlichen VLAN erstellt wird, wird für jeden Workerknoten und die entsprechende öffentliche Netzschnittstelle automatisch eine Host-Endpunkt-Ressource (HostEndpoint) mit der Bezeichnung ibm.role: worker_public erstellt. Dieser HostEndpoint bewirkt, dass der gesamte Datenverkehr zur oder von der öffentlichen Netzschnittstelle gelöscht wird, es sei denn, er wird durch eine Calico-Richtlinie, die die Bezeichnung ibm.role: worker_public auswählt, explizit zugelassen.

Für jeden Workerknoten und die zugehörige private Netzschnittstelle wird ebenfalls automatisch eine Host-Endpunkt-Ressource (HostEndpoint) mit der Bezeichnung ibm.role: worker_private erstellt. Es wird eine allow-all-private-default-Standardrichtlinie erstellt, sodass der gesamte Datenverkehr von und zu der privaten Netzschnittstelle zugelassen wird. Dies HostEndpoint erleichtert es Cluster-Benutzern, den privaten Netzwerkverkehr weiter einzuschränken, indem sie Calico-Richtlinien erstellen, die auswählen ibm.role: worker_private und eine niedrigere Ordnungsnummer als die haben allow-all-private-default.

Diese Calico-Standardhostrichtlinien lassen sämtlichen öffentlichen ausgehenden Netzverkehr und den öffentlichen eingehenden Datenverkehr zu bestimmten Clusterkomponenten, wie z. B. Kubernetes-NodePort-, LoadBalancer- und Ingress-Services, zu. Der gesamte private Datenverkehr wird standardmäßig von der Richtlinie allow-all-private-default zugelassen. Jeder andere eingehende Netzverkehr vom Internet zu Ihren Workerknoten, der nicht in den Standardrichtlinien angegeben ist, wird blockiert. Die Standardrichtlinien wirken sich nicht auf Datenverkehr zwischen Pods aus.

Entfernen Sie die Standardrichtlinien nicht aus Ihrem Cluster, da diese bei der nächsten Aktualisierung oder dem nächsten Update des Cluster-Masters neu erstellt werden. Wenn Sie den Datenverkehr weiter einschränken möchten, wenden Sie Calico-Richtlinien mit niedrigerer Reihenfolge an, um den Datenverkehr zu blockieren. Stellen Sie sicher, dass Sie genau wissen, was Sie blockieren, und dass die Clusterkomponenten den Datenverkehr, den Sie blockieren möchten, nicht benötigen.

Sehen Sie sich die folgenden standardmäßigen Calico-Hostrichtlinien an, die automatisch auf Ihren Cluster angewendet werden.

Außerdem werden Standard- Kubernetes-Richtlinien erstellt, die den Zugriff auf das Kubernetes-Dashboard einschränken. Kubernetes-Richtlinien gelten nicht für den Host-Endpunkt, sondern auf Pod-Ebene und für alle klassischen Cluster und VPC-Cluster.

Netzrichtlinien anzeigen

Zeigen Sie die Details für Standardrichtlinien und allen weiteren hinzugefügten Netzrichtlinien an, die auf Ihren Cluster angewendet werden.

Vor Beginn installieren und konfigurieren Sie die Calico-CLI und richten Sie den Kontext für Ihren Cluster für die Ausführung von Calico-Befehlen ein.

1. Zeigen Sie den Calico-Host-Endpunkt an.

   kubectl get hostendpoints.projectcalico.org -o yaml
   

2. Zeigen Sie alle Calico-Netzrichtlinien an, die für den Cluster erstellt wurden. Diese Liste enthält Richtlinien, die möglicherweise noch nicht für Pods oder Hosts gelten. Damit eine Calico-Richtlinie umgesetzt werden kann, muss ein Kubernetes-Pod oder Calico HostEndpoint vorhanden sein, der mit dem Selektor in der Calico -Netzrichtlinie übereinstimmt.

   Calico Netzwerkrichtlinien gelten für bestimmte Namespaces:

   kubectl get networkpolicy.projectcalico.org --all-namespaces -o wide
   

   Kubernetes Netzwerkrichtlinien gelten zudem nur für bestimmte Namespaces:

   kubectl get networkpolicies.networking.k8s.io --all-namespaces -o wide
   

   Calico Globale Netzwerkrichtlinien gelten nicht für bestimmte Namespaces:

   kubectl get globalnetworkpolicies.projectcalico.org -o wide
   

3. Details zu einer Calico-Netzwerkrichtlinie anzeigen.

   kubectl get networkpolicies.projectcalico.org -o yaml <policy_name> --namespace <policy_namespace>
   

4. Zeigen Sie die Details aller globalen Netzwerkrichtlinien von Calico für den Cluster an.

   kubectl get globalnetworkpolicies.projectcalico.org -o yaml
   

5. Zeigen Sie die Details aller Kubernetes-Netzwerkrichtlinien für den Cluster an.

   kubectl get networkpolicies.networking.k8s.io --all-namespaces -o yaml
   

Netzrichtlinien hinzufügen

Normalerweise erfordern die Standardrichtlinien keine Änderungen. Nur erweiterte Szenarios können unter Umständen Änderungen erforderlich machen. Wenn Sie feststellen, dass Sie Änderungen vornehmen müssen, können Sie Ihre eigenen Netzrichtlinien erstellen.

Informationen zum Erstellen von Netzwerkrichtlinien für Kubernetes finden Sie in der Dokumentation zu Netzwerkrichtlinien unter Kubernetes.

Um Calico-Richtlinien zu erstellen, führen Sie die folgenden Schritte aus.

1. Definieren Sie Ihre Calico-Netzwerkrichtlinie oder globale Netzwerkrichtlinie,.yaml indem Sie ein Konfigurationsskript mit der Syntax Calico v3 erstellen. Diese Konfigurationsdateien enthalten die Selektoren, die beschreiben, auf welche Pods, Namensbereiche oder Hosts diese Richtlinien angewendet werden.

2. Wenden Sie die Richtlinien auf den Cluster an.

   kubectl apply -f policy.yaml
   

Calico Kubernetes-Netzwerkrichtlinien blockieren lediglich neue Verbindungen; bereits vor der Anwendung der Richtlinie bestehende Verbindungen werden nicht unterbrochen. Führen Sie nach der Anwendung einer neuen oder geänderten Richtlinie die folgenden Schritte durch, um zu prüfen, ob sie funktioniert und nicht mehr blockiert, als sie sollte:

1. Starten Sie alle Pods neu, die möglicherweise von der Richtlinie betroffen sind, oder starten Sie alle Pods neu, falls Ihr Selektor nicht korrekt ist und die Richtlinie mehr Pods betrifft, als Sie annehmen.

2. Führen Sie ibmcloud ks cluster master refresh -c CLUSTER-ID aus, um die Cluster-Master-Pods erneut zu starten. Dadurch werden bestehende Verbindungen von kubelet und anderen Komponenten zum Master unterbrochen und diese dazu gezwungen, sich erneut zu verbinden. Hier wird angezeigt, ob die neuen und geänderten Richtlinien notwendige Verbindungen zu Ihren Master-Komponenten blockieren.

3. Versuchen Sie, eine Verbindung zum Kubernetes-Dashboard herzustellen, um sicherzustellen, dass die Richtlinienänderungen die von diesen Komponenten benötigten Verbindungen nicht blockieren.

Eingehenden Datenverkehr an NLB- oder NodePort-Services steuern

Standardmäßig machen Kubernetes-NodePort- und LoadBalancer-Services Ihre App in allen öffentlichen und privaten Clusterschnittstellen verfügbar. Sie können jedoch die Richtlinien von Calico verwenden, um den eingehenden Datenverkehr auf Basis der Datenverkehrsquelle oder des Ziels zu blockieren.

Standard-Kubernetes- und Calico-Richtlinien sind aufgrund der DNAT-Iptables-Regeln, die für diese Services generiert werden, schwierig anzuwenden, um Kubernetes-NodePort- und LoadBalancer-Services zu schützen. Mit Richtlinien vom Typ 'Pre-DNAT' wird jedoch verhindert, dass angegebener Datenverkehr Ihre Apps erreicht, da durch sie 'Iptables'-Regeln generiert und angewendet werden, bevor Kubernetes reguläre DNAT verwendet, um Datenverkehr an Pods weiterzuleiten.

Nachfolgend finden Sie einige gängige Anwendungsbereiche für die Calico-Netzrichtlinien des Typs 'Pre-DNAT':

• Blockieren von Datenverkehr zu öffentlichen Knotenports eines privaten Netzausgleichsfunktions- (NLB-) Service: Ein NLB-Service macht Ihre App über die NLB-IP-Adresse und den -Port zugänglich und macht die App über die Knotenports des Service verfügbar. Auf Knotenports kann über jede IP-Adresse (öffentlich und privat) für jeden Knoten innerhalb des Clusters zugegriffen werden.
• Blockieren von Datenverkehr zu öffentlichen Knotenports auf Clustern, auf denen Edge-Workerknoten ausgeführt werden: Durch das Blockieren der Knotenports wird sichergestellt, dass die Edge-Workerknoten die einzigen Workerknoten sind, von denen ankommender Datenverkehr verarbeitet wird.
• Blockieren von Datenverkehr von bestimmten Quellen-IP-Adressen oder CIDRs
• Zulassen von Datenverkehr nur von bestimmten Quellen-IP-Adressen oder CIDRs und Blockieren des gesamten restlichen Datenverkehrs

Um zu erfahren, wie Sie Quellen-IP-Adressen zulassen oder blockieren, machen Sie sich mit dem Lernprogramm zur Verwendung von Calico-Netzrichtlinien zum Blockieren von Datenverkehr vertraut.

Calico-Beispielrichtlinien zum Beschränken des öffentlichen oder privaten Netzverkehrs

IBM Stellt eine Reihe von Beispiel -Richtlinien für öffentliche Netzwerke unter Calico und für private Netzwerke unter Calico bereit, die den Datenverkehr in öffentlichen und privaten Netzwerken auf Cluster-Workern weiter einschränken.

Diese Richtlinien sind nicht dazu gedacht, alles zu blockieren, noch erfüllen sie notwendigerweise alle Compliance-Anforderungen auf eigene Faust. Sie werden von IBM nicht aktiv unterstützt und dienen lediglich als möglicher Ausgangspunkt; sie müssen an Ihre individuellen Anwendungsfälle angepasst werden. Weitere Informationen finden Sie in der Readme-Datei.

IBM Es wird nicht mehr empfohlen, die Beispielrichtlinien allow-egress-pods-public, allow-public-services-pods, allow-egress-pods-private oder allow-private-services-pods in den Abschnitten Anwenden von Richtlinien für öffentliche Netzwerke und Anwenden von Richtlinien für private Netzwerke zu verwenden. Diese Richtlinien kontrollierten den Austritt aus allen Pods des Clusters. Um den Datenverkehr zu und von Pods zu steuern, empfiehlt IBM die Verwendung von Kubernetes ( NetworkPolicy ) sowie die gezielte Ausrichtung auf bestimmte Namespaces und Pods anstelle der Verwendung pauschaler Richtlinien, die jeden Pod gleich behandeln.

Datenverkehr zwischen Pods steuern

Kubernetes-Richtlinien schützen Pods vor internem Netzverkehr. Sie können einfache Kubernetes-Netzrichtlinien erstellen, um App-Mikroservices in einem Namensbereich oder in mehreren Namensbereichen voneinander zu isolieren.

Standardmäßig hat jeder Pod Zugriff auf alle anderen Pods im Cluster. Darüber hinaus hat jeder Pod Zugriff auf alle über das Podnetz zugänglich gemachten Services, z. B. einen Metrikservice, den Cluster-DNS, den API-Server sowie alle von Ihnen manuell erstellten Services im Cluster.

Protokollierung von verweigertem Datenverkehr

Sie können eine Calico-Protokollnetzrichtlinie erstellen, um die verweigerten Datenverkehrsanforderungen an bestimmte Pods in Ihrem Cluster zu protokollieren.

Wenn Sie Netzrichtlinien einrichten, um den Datenverkehr an App-Pods zu beschränken, werden Datenverkehrsanforderungen, die aufgrund dieser Richtlinien nicht zulässig sind, verweigert und gelöscht. In bestimmten Szenarios wünschen Sie möglicherweise weitere Informationen zu verweigerten Datenverkehrsanforderungen. Beispielsweise könnte es sein, dass Sie ungewöhnlichen Datenverkehr bemerken, der kontinuierlich durch eine Ihrer Netzrichtlinien verweigert wird. Um die potenzielle Sicherheitsbedrohung zu überwachen, können Sie eine Protokollierung einrichten, um jeden Zeitpunkt aufzuzeichnen, zu dem die Richtlinie eine versuchte Aktion für die angegebenen App-Pods verweigert.

In diesem Abschnitt wird gezeigt, wie Datenverkehr protokolliert wird, der von einer Kubernetes-Netzrichtlinie verweigert wird. Informationen zu Datenverkehr, der von einer Calico-Netzrichtlinie abgelehnt wird, finden Sie in Lerneinheit 5 des Lernprogramms zur Calico-Netzrichtlinie.

1. Erstellen oder verwenden Sie eine vorhandene Kubernetes-Netzrichtlinie, die den eingehenden Datenverkehr blockiert oder begrenzt.

   1. Erstellen Sie eine Kubernetes-Netzrichtlinie. Wenn Sie beispielsweise den Datenverkehr zwischen Pods steuern möchten, können Sie die folgende Kubernetes-Beispielrichtlinie mit dem Namen access-nginx verwenden, die den Zugriff auf eine NGINX-App einschränkt. Der eingehende Datenverkehr an Pods mit der Bezeichnung "run=nginx" ist nur von Pods mit der Bezeichnung "run=access" zulässig. Der gesamte weitere eingehende Datenverkehr für die "run=nginx"-App-Pods wird blockiert.

       kind: NetworkPolicy
       apiVersion: networking.k8s.io/v1
       metadata:
        name: access-nginx
       spec:
        podSelector:
          matchLabels:
            run: nginx
        ingress:
          - from:
            - podSelector:
                matchLabels:
                  run: access
       ```
   2. Wenden Sie die Richtlinie an.
   
   ```sh {: pre}
       kubectl apply -f <policy_name>.yaml
       ```
   

2. Um den gesamten Datenverkehr zu protokollieren, der von der im vorigen Schritt erstellten Richtlinie verweigert wurde, erstellen Sie eine Calico-Netzrichtlinie mit dem Namen log-denied-packets. Die folgende Richtlinie Calico verwendet denselben Pod-Selektor wie die in Schritt 1 beschriebene Beispielrichtlinie Kubernetesaccess-nginx, allerdings weicht die Syntax geringfügig ab, da es sich um eine Calico NetworkPolicy statt um eine Kubernetes NetworkPolicy handelt. Da alle Kubernetes NetworkPolicy von Calico als Bestellung 1000 ausgewertet werden, wird außerdem die Bestellnummer 3000 hinzugefügt, um sicherzustellen, dass sie nach der Kubernetes NetworkPolicyausgewertet wird. Wenn diese beiden Richtlinien vorhanden sind, ergibt sich Folgendes:

   • Neue Verbindungen, die beim Nginx-Pod eingehen, werden zuerst anhand der Kubernetes-NetworkPolicy (Reihenfolge 1000) ausgewertet. Verbindungen, die von einem Pod mit dem Label run=access stammen, werden sofort akzeptiert, d. h., es werden keine weiteren Richtlinien ausgewertet.
   • Wenn die Verbindung von einem Pod ohne das Label run=access (oder von etwas anderem als einem Pod) stammt, hat Kubernetes NetworkPolicy keine Auswirkung, und Calico wertet anschließend die Richtlinie log-denied-packets aus. Diese Richtlinie protokolliert das Paket im Syslog auf dem Worker, auf dem sich der Nginx-Pod befindet.
   • Calico sucht dann nach anderen Richtlinien, die auf die Verbindung angewendet werden sollen, und da es keine findet, wird das Paket gelöscht. Dies liegt daran, dass jeglicher Datenverkehr zu einem Pod mit einer Richtlinie, die nicht ausdrücklich zulässig ist, gelöscht wird.

       apiVersion: projectcalico.org/v3
       kind: NetworkPolicy
       metadata:
         name: log-denied-packets
       spec:
         types:
         - Ingress
         ingress:
         - action: Log
           destination: {}
           source: {}
         selector: projectcalico.org/orchestrator == 'k8s' && run == 'nginx'
         order: 3000
       ```
   
   

types

Diese Ingress-Richtlinie bezieht sich auf alle eingehenden Datenverkehrsanforderungen. Der Wert Ingress ist ein allgemeiner Begriff für den gesamten eingehenden Datenverkehr und bezieht sich nicht nur auf den Datenverkehr von der IBM Ingress ALB. ingress : action: Die Aktion Log schreibt für alle Anfragen, die dieser Richtlinie entsprechen, einen Protokolleintrag in den Pfad /var/log/syslog auf dem Worker-Knoten. : destination: Es wird kein Ziel angegeben, da selector diese Richtlinie auf alle Pods mit einer bestimmten Bezeichnung anwendet. : source: Diese Richtlinie gilt für Anforderungen von einer beliebigen Quelle.

selector

Der Selektor sollte auf denselben Datenverkehr abzielen wie die ursprüngliche NetworkPolicy für access-nginx Kubernetes. Da es sich um eine Calico-Richtlinie handelt, müssen Sie zusätzlich zum ursprünglichen die Angabe einfügen, um projectcalico.org/orchestrator == 'k8s' zu verdeutlichen, dass sie für alle Pods im Namespace der Richtlinie gilt run == 'nginx'.

order

Calico-Richtlinien haben eine Reihenfolge, die bestimmt, wann sie auf eingehende Anforderungspakete angewendet werden. Richtlinien mit niedrigerem Wert (z. B. 1000) werden zuerst angewendet. Richtlinien mit höherem Wert werden nach den Richtlinien mit niedrigerem Wert angewendet. Beispielsweise wird eine Richtlinie mit sehr hoher Priorität, wie z. B. 3000, erst als Letztes angewendet, nachdem alle Richtlinien mit niedrigerer Priorität angewendet wurden. Eingehende Anforderungspakete durchlaufen die 'iptables'-Regelkette und versuchen, zuerst mit den Regeln aus den Richtlinien mit niedrigerem Wert übereinzustimmen. Wenn ein Paket mit einer beliebigen Regel übereinstimmt, wird das Paket akzeptiert. Wenn ein Paket jedoch mit keiner Regel übereinstimmt, gelangt es zur letzten Regel in der 'iptables'-Regelkette mit dem höchsten Wert. Um sicherzustellen, dass es sich um die letzte Richtlinie in der Kette handelt, verwenden Sie einen viel höheren Wert (z. B. 3000) als den der Richtlinie, die Sie in Schritt 1 erstellt haben. Beachten Sie, dass Kubernetes und NetworkPolicy in dieser Reihenfolge angewendet werden 1000.

3. Wenden Sie die Richtlinie an.

   kubectl apply -f log-denied-packets.yaml
   

4. Generieren Sie Protokolleinträge, indem Sie Anforderungen senden, die gemäß der in Schritt 1 erstellten Richtlinie nicht zulässig sind. Versuchen Sie beispielsweise, den Pod, der durch die Netzrichtlinie geschützt ist, von einem Pod oder einer nicht zulässigen IP-Adresse mit Ping zu überprüfen.

5. Suchen Sie nach Protokolleinträgen, die in den Pfad /var/log/syslog geschrieben werden. Die DST- (Ziel-) oder SRC- (Quellen-) IP-Adressen im Protokolleintrag können aufgrund von Proxys, Network Address Translation (NAT) und anderen Netzprozessen von den erwarteten Werten abweichen. Der Protokolleintrag ähnelt dem folgenden.

   Sep 5 14:34:40 <worker_hostname> kernel: [158271.044316] calico-packet: IN=eth1 OUT= MAC=08:00:27:d5:4e:57:0a:00:27:00:00:00:08:00 SRC=192.XXX.XX.X DST=192.XXX.XX.XX LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=52866 DF PROTO=TCP SPT=42962 DPT=22 WINDOW=29200 RES=0x00 SYN URGP=0
   

6. Optional: Leiten Sie die Protokolle von /var/log/syslog an IBM Cloud Logs oder an einen externen Syslog-Server weiter.