Calico-Netzrichtlinien zur Steuerung des Datenverkehrs in Classic-Clustern verwenden

Hier können Sie lernen, wie Sie Calico-Richtlinien einsetzen, um Netzdatenverkehr, der bestimmte IP-Adressen als Quelle oder als Ziel hat, zuzulassen.

Beachten Sie, dass die folgenden Schritte für Classic-Cluster mit klassischen Laustausgleichsfunktionen gelten.

Standardmäßig wird Ihre App durch die NodePort-, LoadBalancer- und Ingress-Services von Kubernetes in allen öffentlichen und privaten Clusternetzschnittstellen verfügbar gemacht. Die Calico-Standardrichtlinie allow-node-port-dnat ermöglicht eingehenden Datenverkehr von den Services NodePort, Netzlastausgleichsfunktion (NLB) und der Ingress-Lastausgleichsfunktion für Anwendungen (ALB) zu den App-Pods, die von diesen Service zugänglich gemacht werden. Kubernetes verwendet die Zielnetzadressumsetzung (DNAT – Destination Network Address Translation), um Serviceanforderungen an die richtigen Pods weiterzuleiten.

Aus Sicherheitsgründen ist es jedoch unter Umständen erforderlich, dass der Datenverkehr zu den Netzbetriebsservices nur über bestimmte Quellen-IP-Adressen zulässig ist. Sie können Calico Pre-DNAT-Richtlinien verwenden, um Datenverkehr von oder zu bestimmten IP-Adressen zuzulassen oder zu blockieren. Mit Pre-DNAT-Richtlinien wird verhindert, dass angegebener Datenverkehr Ihre Apps erreicht, da die Richtlinien angewendet werden, bevor Kubernetes reguläre DNAT verwendet, um Datenverkehr an Pods weiterzuleiten. Wenn Sie Calico-Richtlinien des Typs 'Pre-DNAT' erstellen, wählen Sie aus, ob Quellen-IP-Adressen zugelassen oder blockiert werden sollen. In den meisten Szenarios ist das Zulassen bestimmter Datenübertragungen die sicherste Konfiguration, da der gesamte Datenverkehr gesperrt wird und nur Datenverkehr von bekannten und explizit zugelassenen IP-Adressen möglich ist. Das Verweigern eines bestimmten Datenstroms ist in der Regel nur hilfreich, um beispielsweise Angriffe über eine kleine Gruppe von IP-Adressen zu verhindern.

In diesem Szenario übernehmen Sie die Rolle des Netzadministrators für eine PR-Firma und bemerken ungewöhnlichen Datenverkehr, der Ihre Apps erreicht. Die Lerneinheiten in diesem Lernprogramm führen Sie durch die Schritte zur Erstellung einer Web-Server-Beispielapp, zur Verfügungstellung der App mithilfe eines Service für Netzlastausgleichsfunktionen (NLBs) und zum Schützen der App vor unerwünschtem ungewöhnlichem Datenverkehr mithilfe von Calico-Richtlinien mit Zulassungslisten und Blockierlisten.

Ziele

Erlernen Sie, wie der gesamte und zu allen Knotenports eingehende Datenverkehr durch Erstellen einer höherwertigen Richtlinie vom Typ 'Pre-DNAT' blockiert wird.
Erfahren Sie, wie Sie den Zugriff auf die öffentliche IP der NLB und den Port durch bestimmte Quellen-IP-Adressen zulassen, indem Sie eine niedrigwertige Richtlinie vom Typ 'Pre-DNAT' erstellen. Niedrigwertigere Richtlinien setzen höherwertigere Richtlinien außer Kraft.
Erfahren Sie, wie Sie den Zugriff auf die öffentliche IP der NLB und den Port durch bestimmte Quellen-IP-Adressen sperren, indem Sie eine niedrigwertige Richtlinie vom Typ 'Pre-DNAT' erstellen.

Zielgruppe

Dieses Lernprogramm ist für Softwareentwickler und Netzadministratoren konzipiert, die den an eine App gehenden Netzverkehr verwalten möchten.

Voraussetzungen

Erstellen Sie einen klassischen Cluster mit mindestens 3 Workerknoten. Einzelne Workerknotencluster verfügen nicht über die erforderlichen Ressourcen zum Durcharbeiten dieses Lernprogramms. Dieses Lernprogramm ist für VPC-Cluster nicht verfügbar.
Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.
Installieren und konfigurieren Sie die Calico-CLI.
Stellen Sie sicher, dass Sie über die folgenden IBM Cloud IAM-Zugriffsrichtlinien für IBM Cloud Kubernetes Service verfügen:
- Beliebige Plattformzugriffsrolle
- Die Writer- oder Manager-Servicezugriffsrolle

App bereitstellen und mit einer NLB zugänglich machen

In der ersten Lerneinheit erfahren Sie, wie Ihre App von mehreren IP-Adressen und Ports aus zugänglich gemacht wird und an welcher Stelle öffentlicher Datenverkehr in Ihren Cluster eingeht.

Starten Sie mit der Bereitstellung einer Web-Server-Beispielapp, die während des gesamten Lernprogramms verwendet wird. Der Web-Server echoserver zeigt Daten zu der Verbindung an, die vom Client zum Cluster hergestellt wird, und lässt Sie den Zugriff auf den Cluster der PR-Firma testen. Anschließend machen Sie die App durch Erstellen eines Netzausgleichsfunktionsservice (NLB-Service) der Version 1.0 zugänglich. Ein NLB-Service der Version 1.0 macht Ihre App sowohl über die IP-Adresse des NLB-Service als auch über die Knotenports der Workerknoten zugänglich.

Am Ende von Lektion 1 wird die Webserver-App über den öffentlichen Knotenport und den öffentlichen NLB dem Internet zugänglich gemacht.

Stellen Sie die Web-Server-Beispielapp bereit. Wenn eine Verbindung zur Web-Server-App hergestellt ist, antwortet die App mit den HTTP-Headern, die sie in der Verbindung empfangen hat.
```
kubectl apply -f https://raw.githubusercontent.com/IBM-Cloud/kube-samples/master/deploy-apps-clusters/webserver.yaml
```

Stellen Sie sicher, dass der STATUS der Web-Server-App-Pods 'Aktiv' (Running) lautet.

kubectl get pods -o wide

Beispielausgabe

NAME                         READY     STATUS    RESTARTS   AGE       IP               NODE
webserver-855556f688-6dbsn   1/1       Running   0          1m        172.30.xxx.xxx   10.176.48.78
webserver-855556f688-76rkp   1/1       Running   0          1m        172.30.xxx.xxx   10.176.48.78
webserver-855556f688-xd849   1/1       Running   0          1m        172.30.xxx.xxx   10.176.48.78

Um die App im öffentlichen Internet zugänglich zu machen, erstellen Sie für den NLB-Service der Version 1.0 in einem Texteditor eine Konfigurationsdatei mit dem Namen webserver-lb.yaml.

apiVersion: v1
kind: Service
metadata:
  labels:
    run: webserver                               
  name: webserver-lb
spec:
  type: LoadBalancer
  selector:
    run: webserver
  ports:
  - name: webserver-port
    protocol: TCP
    port: 8080
    targetPort: 8080 # Optional. By default, the `targetPort` is set to match the `port` value unless specified otherwise.

Stellen Sie die NLB bereit.

kubectl apply -f filepath/webserver-lb.yaml

Überprüfen Sie, ob Sie von Ihrem Computer aus öffentlich auf die App zugreifen können, die von der NLB zugänglich gemacht wurde.
1. Rufen Sie die öffentliche IP-Adresse (EXTERNAL-IP) der NLB ab.
```
kubectl get svc -o wide
```
  Beispielausgabe
```
NAME           CLUSTER-IP       EXTERNAL-IP        PORT(S)        AGE       SELECTOR
webserver-lb   172.21.xxx.xxx   169.xx.xxx.xxx     80:31024/TCP   2m        run=webserver
```
2. Erstellen Sie mit Spickzettel eine Textdatei und kopieren Sie die IP der NLB in die Textdatei. Mithilfe des Spickzettels können Sie in späteren Lerneinheiten Werte schneller verwenden.
3. Stellen Sie sicher, dass Sie öffentlich auf die externe IP der NLB zugreifen können.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
  In der folgenden Beispielausgabe wird bestätigt, dass die NLB Ihre App an der öffentlichen IP-Adresse 169.1.1.1 der Lastausgleichsfunktion zugänglich macht. Der Pod der App webserver-855556f688-76rkp hat die curl-Anforderung empfangen.
```
Hostname: webserver-855556f688-76rkp
Pod Information:
    -no pod information available-
Server values:
    server_version=nginx: 1.13.3 - lua: 10008
Request Information:
    client_address=10.176.XX.XX
    method=GET
    real path=/
    query=
    request_version=1.1
    request_scheme=http
    request_uri=http://169.1.1.1:8080/
Request Headers:
    accept=*/*
    host=169.1.1.1
    user-agent=curl/7.54.0
Request Body:
    -no body in request-
```
Überprüfen Sie, ob Sie von Ihrem Computer aus öffentlich auf die App zugreifen können, die vom Knotenport zugänglich gemacht wurde. Ein NLB-Service macht Ihre App sowohl über die IP-Adresse des NLB-Service als auch über die Knotenports der Workerknoten zugänglich.
1. Rufen Sie den Knotenport ab, der den Workerknoten von der NLB zugeordnet wurde. Der Knotenport befindet sich im Bereich 30000 - 32767.
```
kubectl get svc -o wide
```
  In der folgenden Beispielausgabe lautet der Knotenport 31024:
```
NAME           CLUSTER-IP       EXTERNAL-IP        PORT(S)        AGE       SELECTOR
webserver-lb   172.21.xxx.xxx   169.xx.xxx.xxx     80:31024/TCP   2m        run=webserver
```
2. Rufen Sie für klassische Cluster die öffentliche IP-Adresse (Public IP) eines Workerknotens ab. Rufen Sie für VPC-Cluster stattdessen die private IP-Adresse (Private IP) ab.
```
ibmcloud ks worker ls --cluster <cluster_name>
```
  Beispielausgabe
```
ID                                                 Public IP        Private IP     Machine Type        State    Status   Zone    Version   
kube-dal10-cr18e61e63c6e94b658596ca93d087eed9-w1   169.xx.xxx.xxx   10.176.48.67   u3c.2x4.encrypted   normal   Ready    dal10   1.32_1513*   
kube-dal10-cr18e61e63c6e94b658596ca93d087eed9-w2   169.xx.xxx.xxx   10.176.48.79   u3c.2x4.encrypted   normal   Ready    dal10   1.32_1513*   
kube-dal10-cr18e61e63c6e94b658596ca93d087eed9-w3   169.xx.xxx.xxx   10.176.48.78   u3c.2x4.encrypted   normal   Ready    dal10   1.32_1513*   
```
3. Kopieren Sie die öffentliche IP des Workerknotens und den Knotenport in Ihren Text-Spickzettel, um sie in späteren Lerneinheiten zu verwenden.
4. Überprüfen Sie, ob Sie über den Knotenport auf die öffentliche IP-Adresse des Workerknotens zugreifen können. Hinweis: Da Workerknoten in VPC-Clustern nicht über eine öffentliche IP-Adresse verfügen, können Sie nur dann über einen Knotenport auf eine App zugreifen, wenn Sie mit Ihrem privaten VPC-Netz verbunden sind (z. B. durch eine VPN-Verbindung). Anschließend können Sie die private IP-Adresse und den Knotenport des Workerknotens verwenden: <worker_private_IP>:<NodePort>.
```
curl  --connect-timeout 10 <worker_IP>:<NodePort>
```
  In der folgenden Beispielausgabe wird bestätigt, dass die Anforderung an Ihre App über die private IP-Adresse 10.1.1.1 des Workerknotens und über den Knotenport 31024 eingegangen ist. Der App-Pod webserver-855556f688-xd849 hat die curl-Anforderung empfangen:
```
Hostname: webserver-855556f688-xd849
Pod Information:
    -no pod information available-
Server values:
    server_version=nginx: 1.13.3 - lua: 10008
Request Information:
    client_address=1.1.1.1
    method=GET
    real path=/
    query=
    request_version=1.1
    request_scheme=http
    request_uri=http://10.1.1.1:8080/
Request Headers:
    accept=*/*
    host=10.1.1.1:31024
    user-agent=curl/7.60.0
Request Body:
    -no body in request-
```

Zu diesem Zeitpunkt wird Ihre App von mehreren IP-Adressen und Ports aus zugänglich gemacht. Die meisten dieser IPs sind clusterintern es kann nur über das private Netz auf sie zugegriffen werden. Nur der öffentliche Knotenport und der öffentliche Port der NLB sind im öffentlichen Internet zugänglich.

Als Nächstes können Sie mit der Erstellung und Anwendung von Calico-Richtlinien beginnen, um öffentlichen Datenverkehr zu blockieren.

Gesamten eingehenden Datenverkehr zu allen Knotenports blockieren

Zum Sichern des Clusters der PR-Firma müssen Sie den öffentlichen Zugriff sowohl auf die NLB als auch auf die Knotenports blockieren, die Ihre App zugänglich machen. Beginnen Sie, indem Sie den Zugriff auf die Knotenports blockieren.

Am Ende von Lektion 2 ist die Webserver-Anwendung nur über den öffentlichen NLB dem Internet zugänglich.

Erstellen Sie in einem Texteditor eine höherwertige Richtlinie des Typs 'Pre-DNAT' mit dem Namen deny-nodeports.yaml, um eingehenden TCP- und UDP-Datenverkehr zurückzuweisen, der von beliebigen Quellen-IPs an alle Knotenports fließt.

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: deny-nodeports
spec:
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Deny
    destination:
      ports:
      - 30000:32767
    protocol: TCP
    source: {}
  - action: Deny
    destination:
      ports:
      - 30000:32767
    protocol: UDP
    source: {}
  selector: ibm.role=='worker_public'
  order: 1100
  types:
  - Ingress

Wenden Sie die Richtlinie an.

Linux:

calicoctl apply -f filepath/deny-nodeports.yaml

Unter Windows und OS X:

calicoctl apply -f filepath/deny-nodeports.yaml --config=filepath/calicoctl.cfg

Beispielausgabe

Successfully applied 1 'GlobalNetworkPolicy' resource(s)

Stellen Sie anhand der Werte aus Ihrem Spickzettel sicher, dass Sie nicht auf die öffentliche IP-Adresse und den Knotenport des Workerknotens zugreifen können.
```
curl  --connect-timeout 10 <worker_IP>:<NodePort>
```
Die Verbindung überschreitet das Zeitlimit, da die von Ihnen erstellte Calico-Richtlinie Datenverkehr zu den Knotenports blockiert.
```
curl: (28) Connection timed out after 10016 milliseconds
```
Ändern Sie die Richtlinie für externen Datenverkehr der Lastausgleichsfunktion, die Sie in der vorherigen Lerneinheit erstellt haben, von Cluster in Local. Local stellt sicher, dass die Quellen-IP Ihres Systems beibehalten wird, wenn Sie den Befehl 'curl' im nächsten Schritt auf die externe IP der Lastausgleichsfunktion anwenden.
```
kubectl patch svc webserver-lb -p '{"spec":{"externalTrafficPolicy":"Local"}}'
```
Prüfen Sie mithilfe des Werts aus Ihrem Spickzettel, ob Sie weiterhin öffentlich auf die externe IP-Adresse der NLB zugreifen können.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
Beispielausgabe
```
Hostname: webserver-855556f688-76rkp
Pod Information:
    -no pod information available-
Server values:
    server_version=nginx: 1.13.3 - lua: 10008
Request Information:
    client_address=1.1.1.1
    method=GET
    real path=/
    query=
    request_version=1.1
    request_scheme=http
    request_uri=http://<loadbalancer_IP>:8080/
Request Headers:
    accept=*/*
    host=<loadbalancer_IP>
    user-agent=curl/7.54.0
Request Body:
    -no body in request-
```
Im Abschnitt für die Anforderungsinformationen (Request Information) der Ausgabe lautet die Quellen-IP-Adresse z. B. client_address=1.1.1.1. Die Quellen-IP-Adresse ist die öffentliche IP des Systems, das Sie verwenden, um den Befehl 'curl' auszuführen. Wenn Sie eine Verbindung zum Internet über einen Proxy oder ein VPN herstellen, kann nämlich andernfalls der Proxy oder das VPN die tatsächliche IP-Adresse Ihres Systems verdecken. In beiden Fällen wird die Quellen-IP-Adresse des Systems von der NLB als IP-Adresse des Clients interpretiert.
Kopieren Sie die Quellen-IP-Adresse Ihres Systems (client_address=1.1.1.1 in der Ausgabe des vorherigen Schritts) in Ihren Spickzettel, um sie in späteren Lerneinheiten zu verwenden.

Super! Zu diesem Zeitpunkt wird Ihre App nur über den öffentlichen NLB-Port im öffentlichen Internet zugänglich gemacht. Der Datenverkehr an die öffentlichen Knotenports ist blockiert. Ein Teil Ihres Clusters ist für unerwünschten Datenverkehr gesperrt.

Als Nächstes können Sie Calico-Richtlinien erstellen und anwenden, um nur den Datenverkehr von bestimmten Quellen-IPs zuzulassen.

Eingehenden Datenverkehr von einer bestimmten IP an die Netzlastausgleichsfunktion (NLB) zulassen

Sie beschließen nun, den Datenverkehr zum Cluster der PR-Firma vollständig zu sperren und den Zugriff zu testen, indem Sie nur die IP-Adresse Ihres eigenen Computers zulassen.

Zuerst müssen Sie wie schon bei den Knotenports den gesamten eingehenden Datenverkehr an die NLB, über die die App zugänglich gemacht wird, blockieren. Anschließend können Sie eine Richtlinie erstellen, mit der die IP-Adresse Ihres Systems zugelassen wird. Am Ende von Lerneinheit 3 ist der gesamte Datenverkehr zu den öffentlichen Knotenports und der NLB blockiert und nur Datenverkehr von der als zulässig angegebenen IP-Adresse Ihres Systems ist erlaubt.

Erstellen Sie in einem Texteditor eine höherwertige Richtlinie des Typs 'Pre-DNAT' mit dem Namen deny-lb-port-80.yaml, um den gesamten TCP- und UDP-Datenverkehr zurückzuweisen, der von beliebigen Quellen-IPs an die IP-Adresse und den Port der NLB fließt. Ersetzen Sie <loadbalancer_IP> durch die öffentliche IP-Adresse der NLB aus Ihrem Cheat-Sheet.

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: deny-lb-port-80
spec:
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Deny
    destination:
      nets:
      - <loadbalancer_IP>/32
      ports:
      - 80
    protocol: TCP
    source: {}
  - action: Deny
    destination:
      nets:
      - <loadbalancer_IP>/32
      ports:
      - 80
    protocol: UDP
    source: {}
  selector: ibm.role=='worker_public'
  order: 800
  types:
  - Ingress

Wenden Sie die Richtlinie an.

Linux:

calicoctl apply -f filepath/deny-lb-port-80.yaml

Unter Windows und OS X:

calicoctl apply -f filepath/deny-lb-port-80.yaml --config=filepath/calicoctl.cfg

Überprüfen Sie mithilfe des Werts auf dem Spickzettel, ob Sie nun nicht auf die öffentliche IP-Adresse der NLB zugreifen können. Die Verbindung überschreitet das Zeitlimit, da die von Ihnen erstellte Calico-Richtlinie den Datenverkehr an die NLB blockiert.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
Erstellen Sie in einem Texteditor eine niedrigwertige Richtlinie vom Typ 'Pre-DNAT' mit dem Namen allowlist.yaml, um Datenverkehr von der IP Ihres Systems an die IP-Adresse und den Port der NLB zuzulassen. Ersetzen Sie anhand der Werte aus Ihrem Cheat-Sheet <loadbalancer_IP> durch die öffentliche IP-Adresse der NLB und <client_address> durch die öffentliche IP-Adresse der Quellen-IP Ihres Systems. Wenn Sie die IP Ihres Systems vergessen haben, können Sie den Befehl curl ifconfig.co ausführen.
```
apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: allowlist
spec:
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Allow
    destination:
      nets:
      - <loadbalancer_IP>/32
      ports:
      - 80
    protocol: TCP
    source:
      nets:
      - <client_address>/32
  selector: ibm.role=='worker_public'
  order: 500
  types:
  - Ingress
```

Wenden Sie die Richtlinie an.

Linux:

calicoctl apply -f filepath/allowlist.yaml

Unter Windows und OS X:

calicoctl apply -f filepath/allowlist.yaml --config=filepath/calicoctl.cfg

Die IP-Adresse Ihres Systems wird jetzt zugelassen.

Überprüfen Sie mithilfe des Werts auf dem Spickzettel, ob Sie nun auf die öffentliche IP-Adresse der NLB zugreifen können.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
Wenn Sie über Zugriff auf ein anderes System verfügen, das eine andere IP-Adresse aufweist, können Sie versuchen, von diesem System aus auf die NLB zuzugreifen.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
Die Verbindung überschreitet das Zeitlimit, weil die IP-Adresse des Systems nicht zugelassen ist.

Zu diesem Zeitpunkt ist der gesamte Datenverkehr an die öffentlichen Knotenports und die NLB blockiert. Es ist nur Datenverkehr von als zulässig angegebenen IP-Adresse Ihres Systems möglich.

Eingehenden Datenverkehr von bestimmten IPs an die Netzlastausgleichsfunktion (NLB) zurückweisen

In der vorherigen Lerneinheit haben Sie den gesamten Datenverkehr blockiert und nur einige wenige IP-Adressen zugelassen. Dieses Szenario ist günstig für Testzwecke, wenn Sie den Zugriff auf nur einige wenige kontrollierte Quellen-IP-Adressen beschränken wollen. Die PR-Firma hat jedoch Apps, die in hohem Maße öffentlich verfügbar sein sollen. Sie müssen sicherstellen, dass der gesamte Datenverkehr zulässig ist, allerdings mit Ausnahme des ungewöhnlichen Datenverkehrs, der von einigen wenigen IP-Adressen stammt. In einem Szenario wie diesem ist die Verwendung einer Abweisungsliste nützlich, denn eine solche Liste kann dabei helfen, Angriffe zu verhindern, die von einer kleinen Gruppe von IP-Adressen ausgehen.

In dieser Lerneinheit blockieren Sie Datenverkehr, der von der Quellen-IP-Adresse Ihres eigenen Systems stammt. Am Ende von Lerneinheit 4 ist der gesamte Datenverkehr an die öffentlichen Knotenports blockiert und der gesamte Datenverkehr an die öffentliche NLB ist zulässig. Nur der Datenverkehr von Ihrer speziellen System-IP-Adresse zur Netzlastausgleichsfunktion (NLB) wird blockiert.

Bereinigen Sie die Richtlinien mit Zulassungslisten, die Sie in der vorherigen Lerneinheit erstellt haben.
- Linux:
```
calicoctl delete GlobalNetworkPolicy deny-lb-port-80
```
```
calicoctl delete GlobalNetworkPolicy allowlist
```
- Unter Windows und OS X:
```
calicoctl delete GlobalNetworkPolicy deny-lb-port-80 --config=filepath/calicoctl.cfg
```
```
calicoctl delete GlobalNetworkPolicy allowlist --config=filepath/calicoctl.cfg
```
Nun ist der gesamte eingehende TCP- und UDP-Datenverkehr von beliebigen Quellen-IPs an die IP-Adresse der NLB und an den Port ist erneut zulässig.

Wenn Sie den gesamten TCP- und UDP-Datenverkehr von der Quellen-IP-Adresse Ihres Systems an die IP-Adresse und den Port der NLB zurückweisen möchten, erstellen Sie in einem Texteditor eine niedrigwertige Richtlinie vom Typ 'Pre-DNAT' mit dem Namen blocklist.yaml. Ersetzen Sie anhand der Werte aus Ihrem Cheat-Sheet <loadbalancer_IP> durch die öffentliche IP-Adresse der NLB und <client_address> durch die öffentliche IP-Adresse der Quellen-IP Ihres Systems.

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: blocklist
spec:
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Deny
    destination:
      nets:
      - <loadbalancer_IP>/32
      ports:
      - 80
    protocol: TCP
    source:
      nets:
      - <client_address>/32
  - action: Deny
    destination:
      nets:
      - <loadbalancer_IP>/32
      ports:
      - 80
    protocol: UDP
    source:
      nets:
      - <client_address>/32
 selector: ibm.role=='worker_public'
 order: 500
 types:
 - Ingress

Wenden Sie die Richtlinie an.

Linux:

calicoctl apply -f filepath/blocklist.yaml

Unter Windows und OS X:

calicoctl apply -f filepath/blocklist.yaml --config=filepath/calicoctl.cfg

Die IP-Adresse Ihres Systems wird jetzt geblockt.

Überprüfen Sie mithilfe des Werts auf Ihrem Spickzettel von Ihrem System aus, ob Sie auf die IP der NLB tatsächlich nicht zugreifen können, weil die IP-Adresse Ihres Systems blockiert wird.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```
An diesem Punkt ist der gesamte Datenverkehr an die öffentlichen Knotenports blockiert und der gesamte Datenverkehr an die öffentliche NLB ist zulässig. Nur der Datenverkehr von Ihrer speziellen System-IP-Adresse zur Netzlastausgleichsfunktion (NLB) wird blockiert.

Ganz hervorragend! Sie haben den Datenverkehr in Ihre App erfolgreich gesteuert, indem Sie Quellen-IP-Adresse anhand von Calico-Richtlinien des Typs 'Pre-DNAT' blockiert haben.

Blockierten Datenverkehr von bestimmten IP-Adressen an die Netzlastausgleichsfunktion (NLB) protokollieren

In der vorherigen Lerneinheit haben Sie den Datenverkehr von Ihrer System-IP an die NLB blockiert. In dieser Lerneinheit erfahren Sie, wie die verweigerten Datenverkehrsanforderungen protokolliert werden.

In diesem Beispielszenario möchte die PR-Firma, für die Sie arbeiten, dass Sie einen Protokollierungspfad für ungewöhnlichen Datenverkehr einrichten, der kontinuierlich von einer Ihrer Netzwerkrichtlinien abgelehnt wird. Um die potenzielle Sicherheitsbedrohung zu überwachen, richten Sie eine Protokollierung ein, um jeden Zeitpunkt aufzuzeichnen, zu dem Ihre Richtlinie mit Blockierliste den Versuch einer Aktion für die NLB-IP zurückweist.

Erstellen Sie eine Calico-Netzrichtlinie mit dem Namen log-denied-packets. Diese Protokollrichtlinie verwendet denselben Selektor wie die Richtlinie blocklist, wodurch diese Richtlinie zur Calico-'Iptables'-Regelkette hinzugefügt wird. Durch die Verwendung einer niedrigen Folgenummer (z. B. 300) können Sie sicherstellen, dass diese Regel innerhalb der Regelkette 'Iptables' vor der Richtlinie für Sperrlisten hinzugefügt wird. Pakete aus Ihrer IP werden von dieser Richtlinie protokolliert, bevor sie einen Abgleich mit der Richtlinienregel blocklist versuchen und zurückgewiesen werden.

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
    name: log-denied-packets
 spec:
  applyOnForward: true
  preDNAT: true
  ingress:
  - action: Log
    destination:
      nets:
      - <loadbalancer_IP>/32
      ports:
      - 80
    protocol: TCP
    source:
      nets:
      - <client_address>/32
  - action: Log
    destination:
      nets:
      - <loadbalancer_IP>/32
      ports:
      - 80
    protocol: UDP
    source:
      nets:
      - <client_address>/32
  selector: ibm.role=='worker_public'
  order: 300
  types:
  - Ingress

Wenden Sie die Richtlinie an.

Linux:

calicoctl apply -f /log-denied-packets.yaml

Unter Windows und OS X:

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

Generieren Sie Protokolleinträge durch Senden von Anforderungen von Ihrer System-IP an die NLB-IP. Diese Anforderungspakete werden protokolliert, bevor sie verweigert werden.
```
curl --connect-timeout 10 <loadbalancer_IP>:80
```

Suchen Sie nach Protokolleinträgen, die in den Pfad /var/log/syslog geschrieben werden. 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

Gut gemacht! Sie haben die Protokollierung so konfiguriert, dass der blockierte Datenverkehr ohne großen Aufwand überwacht werden kann.

Vorgehensweise zum Bereinigen der Blockierliste und der Protokollrichtlinien:

Bereinigen Sie die Richtlinie blocklist.

Linux:

calicoctl delete GlobalNetworkPolicy blocklist

Unter Windows und OS X:

calicoctl delete GlobalNetworkPolicy blocklist --config=filepath/calicoctl.cfg

Bereinigen Sie die Protokollrichtlinie.

Linux:

calicoctl delete GlobalNetworkPolicy log-denied-packets

Unter Windows und OS X:

calicoctl delete GlobalNetworkPolicy log-denied-packets --config=filepath/calicoctl.cfg

Weitere Schritte

Weitere Informationen zur Steuerung des Datenverkehrs mithilfe von Netzrichtlinien.
Weitere Beispiele für Calico-Netzrichtlinien, die den Datenverkehr zu und von Ihrem Cluster steuern, finden Sie in den Calico-Lernprogrammen.