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. Diese HostEndpoint erleichtert es Clusterbenutzern, den privaten Netzverkehr weiter zu beschränken, indem sie Calico-Richtlinien erstellen, die ibm.role: worker_private auswählen und eine niedrigere Folgenummer als die allow-all-private-defaulthaben.

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.

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

Calico-CLI installieren und konfigurieren

Installieren und konfigurieren Sie die Calico-CLI zum Anzeigen, Verwalten und Hinzufügen von Calico-Richtlinien.

1. Richten Sie den Kontext für Ihren Cluster für die Ausführung von Calico-Befehlen ein.

   • Kubernetes Version 1.19 und höher:

     1. Laden Sie die kubeconfig-Konfigurationsdatei für Ihren Cluster herunter.

        ibmcloud ks cluster config --cluster CLUSTER_NAME_OR_ID
        

     2. Setzen Sie die Umgebungsvariable DATASTORE_TYPE auf den Wert kubernetes.

        export DATASTORE_TYPE=kubernetes
        

2. Falls Unternehmensnetzrichtlinien den Zugriff von Ihrem lokalen System auf öffentliche Endpunkte über Proxys oder Firewalls verhindert, lassen Sie TCP-Zugriff für Calico-Befehle zu.

3. Führen Sie die Schritte zum Installieren des calicoctl-Befehlszeilentools aus.

   • Linux and OS X

     1. Laden Sie die für Ihr Betriebssystem geeignete Version der Calico-CLI herunter. Unter OS X müssen Sie möglicherweise manuell zulassen, dass die heruntergeladene Datei geöffnet und ausgeführt wird. Navigieren Sie dazu zu Systemeinstellungen > Sicherheit & Datenschutz > Allgemein.

     2. Verschieben Sie die Datei in das Verzeichnis /usr/local/bin.

        mv <filepath>/<filename> /usr/local/bin/calicoctl
        

     3. Konvertieren Sie die Datei in eine ausführbare Datei.

        chmod +x /usr/local/bin/calicoctl
        

     4. Stellen Sie sicher, dass sich keine alte Calico-Konfigurationsdatei calicoctl.cfg im Verzeichnis /etc/calico befindet. Wenn die Datei /etc/calico/calicoctl.cfg vorhanden ist, löschen Sie sie.

   • Windows

     1. Laden Sie die Calico-CLI herunter. Wenn Sie die Datei speichern, benennen Sie sie in calicoctl.exe um und speichern Sie sie im selben Verzeichnis wie die IBM CloudBefehlszeilenschnittstelle. Diese Konfiguration erspart Ihnen bei der späteren Ausführung von Befehlen einige Dateipfadänderungen.

     2. Setzen Sie die Umgebungsvariable auf die Konfigurationsdatei für Ihren Cluster.

        export KUBECONFIG=./.bluemix/plugins/container-service/clusters/<cluster_name>-<hash>/kube-config.yaml
        

4. Vergewissern Sie sich, dass die Calico-Konfiguration ordnungsgemäß funktioniert.

   calicoctl get nodes
   

   Beispielausgabe

   NAME
   10.176.48.106
   10.176.48.107
   10.184.58.23
   10.184.58.42
   ...
   

Das Ändern des Calico-Plug-ins, der Komponenten oder der Calico-Standardeinstellungen wird nicht unterstützt. Implementieren Sie beispielsweise keine neue Calico-Plug-in-Version oder die Dämongruppen oder Implementierungen für die Calico-Komponenten, Standardressourcen IPPool oder Calico-Knoten ändern. Stattdessen können Sie die Anweisungen in der Dokumentation zum Ändern der Calico-MTU oder zum Inaktivieren des Plug-ins für die Portzuordnung für die Calico-CNI befolgen.

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.

   calicoctl get hostendpoint -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.

   Netzwerkrichtlinien gelten für bestimmte Namespaces:

   calicoctl get NetworkPolicy --all-namespaces -o wide
   

   Globale Netzwerkrichtlinien gelten nicht für bestimmte Namespaces:

   calicoctl get GlobalNetworkPolicy -o wide
   

3. Zeigen Sie Details für ein Netzrichtlinie an.

   calicoctl get NetworkPolicy -o yaml <policy_name> --namespace <policy_namespace>
   

4. Zeigen Sie die Details aller globalen Netzrichtlinien für den Cluster an.

   calicoctl get GlobalNetworkPolicy -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 für Kubernetes.

Um Calico-Richtlinien zu erstellen, führen Sie die folgenden Schritte aus. 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. 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.

   Für neue Cluster, die ab Version 1.29 bereitgestellt wurden, werden die Kurznamen für „ globalnetworkpolicies.crd.projectcalico.org “ (gnp) und „ hostendpoints.crd.projectcalico.org “ (hep) nicht unterstützt. Wenn Sie einen Cluster jedoch auf die Version „ 1.29 “ oder höher aktualisieren, werden die Kurznamen weiterhin unterstützt.

2. Wenden Sie die Richtlinien auf den Cluster an. Wenn Sie ein Windows-System haben, schließen Sie die Option --config=<filepath>/calicoctl.cfg ein.

   calicoctl apply -f policy.yaml [--config=<filepath>/calicoctl.cfg]
   

Bitte beachten Sie, dass Calico- und Kubernetes-Netzrichtlinien nur neue Verbindungen blockieren und keine Verbindungen unterbrechen, die vor der Anwendung der Richtlinie vorhanden waren. Gehen Sie wie folgt vor, um nach dem Anwenden einer neuen oder geänderten Richtlinie zu testen, ob sie funktioniert und nicht mehr blockiert, als sie sollte:

1. Starten Sie alle Pods erneut, die von der Richtlinie betroffen sein könnten. Besser noch: Starten Sie alle Pods neu, für den Fall, dass Ihr Selektor nicht korrekt ist und dies größere Auswirkungen hat, als Sie vermuten.

2. Führen Sie ibmcloud ks cluster master refresh -c CLUSTER-ID aus, um die Cluster-Master-Pods erneut zu starten. Dadurch werden vorhandene Verbindungen von kubelet und anderen Komponenten zum Master unterbrochen und die Wiederherstellung der Verbindung erzwungen. Dadurch wird angezeigt, ob die neuen und geänderten Richtlinien alle erforderlichen Verbindungen zu Ihren Masterkomponenten 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

Wir stellen eine Gruppe von Beispielen Richtlinien für öffentliche Calico-Netze bereit, die den öffentlichen/privaten Netzverkehr auf Cluster-Workern weiter einschränken. Diese Richtlinien lassen den für die Bereitstellung des Clusters erforderlichen Datenverkehr zu und blockieren bestimmten anderen Datenverkehr.

Diese Richtlinien sind nicht dazu gedacht, alles zu blockieren, noch erfüllen sie notwendigerweise alle Compliance-Anforderungen auf eigene Faust. Sie sind als Ausgangspunkt gedacht und müssen entsprechend Ihren speziellen Anwendungsfällen bearbeitet werden. Weitere Informationen finden Sie in der Readme-Datei.

Bei jeder Aktivierung neuer Standorte für IBM Cloud Kubernetes Service und andere IBM Cloud-Services werden die Teilnetze für diese Standorte zu den Calico-Richtlinien hinzugefügt. Informieren Sie sich bitte unter Das Repository „ GitHub “ beobachten über etwaige Aktualisierungen dieser Richtlinien.

Bitte beachten Sie, dass wir die Verwendung der Beispielrichtlinien allow-egress-pods-public, allow-public-services-pods, allow-egress-pods-private und allow-private-services-pods in den Abschnitten Anwenden von Richtlinien für öffentliche Netzwerke und Anwenden von Richtlinien für private Netzwerke nicht mehr empfehlen. Diese Richtlinien kontrollierten den Austritt aus allen Pods des Clusters. Wenn Sie den Datenverkehr zu und von Pods steuern möchten, sollten Sie Kubernetes ( NetworkPolicy ) verwenden und bestimmte Namespaces und Pods gezielt ansprechen, anstatt diese pauschalen Richtlinien zu nutzen, 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.

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. 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 unterscheidet sich die Syntax geringfügig, da es sich um einen Calico NetworkPolicy anstelle eines 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 der Bezeichnung run=access stammen, werden sofort akzeptiert, d. h., es werden keine anderen 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 Log-Aktion schreibt einen Protokolleintrag für alle Anforderungen, die dieser Richtlinie entsprechen, in den /var/log/syslog-Pfad auf dem Workerknoten. : 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 einer sehr hohen Priorität, wie z. B. 3000, erst als Letzte 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. Wenn Sie einen Windows-Rechner verwenden, fügen Sie die Option --config=<filepath>/calicoctl.cfg hinzu.

   calicoctl apply -f log-denied-packets.yaml [--config=<filepath>/calicoctl.cfg]
   

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.