Option 1: Deaktivieren des Schutzes für ausgehenden Datenverkehr beim Erstellen eines Clusters

Diese Option erlaubt alle ausgehenden Netzwerkverbindungen.

• Wählen Sie in der Konsole die Option Ausgehenden Datenverkehr zulassen aus.
• Wenn Sie in der CLI einen Cluster mit dem Befehl cluster create vpc-gen2 erstellen, geben Sie die Option --disable-outbound-traffic-protection an.
• Geben Sie in Terraform die Option disable_outbound_traffic_protection = true.
• Geben Sie in der API die Option disableOutboundTrafficProtection=true.

Option 2: Ausgehenden Datenverkehr über eine benutzerdefinierte Sicherheitsgruppe zulassen

Erstellen Sie vor dem Erstellen Ihres Clusters eine benutzerdefinierte Sicherheitsgruppe in Ihrem VPC, die den Zugriff auf die externe Site oder den externen Dienst ermöglicht, auf den Ihr Cluster zugreifen muss. Fügen Sie diese Sicherheitsgruppe dann während der Clustererstellung Ihrem Cluster hinzu.

• Geben Sie in der Konsole Ihre benutzerdefinierte Sicherheitsgruppe an.
• Wenn Sie in der CLI einen Cluster mit dem Befehl cluster create vpc-gen2 erstellen, geben Sie die Option --cluster-security-group <security-group-ID> an und schließen Sie Ihre benutzerdefinierte Sicherheitsgruppen-ID ein.
• Geben Sie in Terraform die Option security_groups an und schließen Sie Ihre benutzerdefinierte Gruppe ein.

Option 1: Deaktivieren des Schutzes für ausgehenden Datenverkehr über die CLI

Diese Option erlaubt alle externen Netzwerkverbindungen.

ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER

Option 2: Hinzufügen einer Sicherheitsgruppenregel zur Standardsicherheitsgruppe der Cluster-Worker

Sie können der Cluster-Worker-Sicherheitsgruppe ( kube-<clusterID> ) eine Sicherheitsgruppenregel hinzufügen, die den Zugriff auf die bestimmte externe Site ermöglicht. Wiederholen Sie diesen Schritt für jede Site oder jedes Subnetz, auf das Ihr Cluster zugreifen muss. Weitere Informationen finden Sie in Beispielszenarien für die selektive Zulassung ausgehenden Datenverkehrs.

ibmcloud is sg-rulec kube-CLUSTERID outbound icmp_tcp_udp --remote IP-ADDRESS-OR-SUBNET

Zugriff auf Images aus externen Container-Registries wie DockerHub oder quay.io

Um auf Images aus Registern wie DockerHub oder quay.io oder registry.redhat.com zuzugreifen, wählen Sie eine der folgenden Optionen.

• Deaktivieren Sie den Schutz für ausgehenden Datenverkehr.

  ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER
  

• Spiegeln Sie die Bilder, die Ihre App benötigt, auf icr.io. Ziehen, taggen und pushen Sie diese Bilder nach IBM Cloud Container Registry. Weitere Informationen finden Sie unter Übertragen von Bildern in IBM Cloud Container Registry.

Ausgehenden Datenverkehr zu Red Hat Marketplace und OperatorHub zulassen

Die folgenden Schritte aktivieren den gesamten ausgehenden Datenverkehr. Wenn Sie diese Funktion nicht aktivieren möchten, können Sie Spiegeln Sie die Bilder unter Red Hat Marketplace und OperatorHub, die Ihre App benötigt auf Ihre eigene Adresse icr.io umleiten.

1. Deaktivieren Sie den Schutz für ausgehenden Datenverkehr.

   ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER
   

2. Patchen Sie OperatorHub auf Ihrem Cluster, um den Start der Pods zu ermöglichen.

   oc patch OperatorHub cluster --type json -p '[{"op": "remove", "path": "/spec/disableAllDefaultSources"}]'
   

Um diese Änderungen später rückgängig zu machen und OperatorHub, führen Sie die folgenden Schritte aus.

1. Aktivieren Sie den Schutz für ausgehenden Datenverkehr.

   ibmcloud oc vpc outbound-traffic-protection enable --cluster CLUSTER
   

2. Patchen Sie OperatorHub auf Ihrem Cluster, um die Pods zu deaktivieren

   oc patch OperatorHub cluster --type json -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
   

Ausgehenden Datenverkehr zu Image Streams zulassen

Um auf Bild-Streams aus Ihrem Cluster zuzugreifen, wählen Sie aus den folgenden Optionen.

• Spiegeln Sie die benötigten Bilder in das Register icr.io. Weitere Informationen finden Sie unter Übertragen von Bildern in IBM Cloud Container Registry.

• Deaktivieren Sie den Schutz für ausgehenden Datenverkehr.

  ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER
  

• Fügen Sie der Sicherheitsgruppe kube-<clusterID> eine Sicherheitsgruppenregel für die IP-Adressen des Bilddatenstroms hinzu, den Sie verwenden möchten. Beachten Sie, dass sich die IP-Adressen für Bildstreams ändern können.

  ibmcloud is sg-rulec kube-vpegw-<clusterID> inbound tcp --port-min PORT  --port-max PORT --remote IP-OR-CIDR
  

Ausgehenden Datenverkehr für die Remote-Integritätsüberwachung mit Telemetrie zulassen

Um eine Remote-Integritätsüberwachung zu ermöglichen, müssen Sie den Schutz für ausgehenden Datenverkehr durch Ausführen des folgenden Befehls deaktivieren.

ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER

Zugriff auf 4.15 Cluster und die Webkonsole über die VPE

Sie können Kubernetes so konfigurieren, dass der Clusterzugriff über das private VPE-Gateway möglich ist. Diese Option ist sowohl für rein private als auch für öffentliche und private VPC-Cluster verfügbar. Da der Zugriff über den privaten Endpunkt erfolgt, muss der Kunde für den Zugriff auf den Cluster ein VPN vom Client zu seinem VPC einrichten.

Ab 4.15 Clustern ist eine zusätzliche Sicherheitsgruppenregel erforderlich, damit der VPE-Zugriff funktioniert. Die zusätzliche Sicherheitsgruppenregel wird sowohl für rein private Cluster als auch für Cluster mit öffentlichen und privaten Endpunkten benötigt.

1. Listen Sie Ihre VPN-Server auf.

   ibmcloud is vpn-servers
   

2. Holen Sie sich die Details Ihres VPN-Servers.

   ibmcloud is vpn-server SERVER
   

3. Holen Sie sich den Client-IP-Pool Ihres VPN-Servers.

   ibmcloud is vpn-server | grep "Client IP pool"
   

4. Holen Sie sich die Details Ihres Clusters und notieren Sie sich den VPE-Port.

   ibmcloud ks cluster get --cluster CLUSTERID
   

5. Starten Sie Ihr VPN auf dem Client.

6. Greifen Sie über VPE auf Ihren Cluster zu.

   ibmcloud ks cluster config --admin --cluster CLUSTERID --endpoint vpe
   

7. Pods auflisten. Beachten Sie, dass dieser Befehl fehlschlägt, da der Client nicht über das VPN über das VPE-Gateway auf den Cluster zugreifen kann.

   kubectl get pods -A
   

8. Fügen Sie dem kube-vpegw-<clusterID> für Ihr VPN eine Sicherheitsgruppenregel hinzu. Der Remotezugriff erfolgt in diesem Fall über die CIDR der VPN-Client-IP.

   ibmcloud is sg-rulec kube-vpegw-<clusterID> inbound tcp --port-min PORT  --port-max PORT --remote IP-OR-CIDR
   

   Beispielbefehl.

   ibmcloud is sg-rulec kube-vpegw-<clusterID> inbound tcp --port-min 30829  --port-max 30829 --remote 192.168.192.0/22
   

9. Pods auflisten.

   kubectl get pods -A
   

Ausgehenden Datenverkehr für Webhooks zulassen

Wenn Sie Webhooks verwenden, die einen URL oder einen Dienst außerhalb des Clusters kontaktieren, müssen Sie Sicherheitsgruppenregeln hinzufügen, die den ausgehenden Datenverkehr von Ihren Cluster-Arbeitern zum URL oder externen Dienst zulassen. Alternativ können Sie den Schutz für ausgehenden Datenverkehr vollständig deaktivieren.

Normalerweise erfordern Zulassungs-Webhooks, die Cluster-Dienstreferenzen verwenden, keine Änderungen.

Im folgenden Beispiel erfordert ein Zulassungs-Webhook, der eine Verbindung zu einem Clusterdienst herstellt, normalerweise keine Änderungen, da der Master über die standardmäßig zulässige Konnectivity-Verbindung eine Verbindung zum Dienst herstellt. Eine Ausnahme wäre, wenn die Pods, die diesen Clusterdienst implementieren, eine Verbindung zu einem URL oder einem externen Dienst herstellen müssen. Wenn ja, dann erlauben Sie diesen Pods den Zugriff auf den URL oder den externen Dienst, wie in diesem Beispiel gezeigt.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: my-cluster-service.webhook.io
webhooks:
- admissionReviewVersions:
  - v1
  clientConfig:
    caBundle: ABCDEFG...
    service:
      name: my-admission-webhook
      namespace: default
      path: /validate
      port: 443
...

Wenn Ihre Zulassungs-Webhooks jedoch eine URL verwenden, sind zusätzliche Sicherheitsgruppenregeln erforderlich.

Beispiel für einen Webhook, der sich mit einer URL verbindet.

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  name: my-url.webhook.io
webhooks:
- admissionReviewVersions:
  - v1
  clientConfig:
    caBundle: ABCDEFG...
    url: https://webhook.ibm.com:20001/validate
...

Um den Zugriff auf den externen URL oder Dienst für Ihren Webhook zu ermöglichen, können Sie eine der folgenden Optionen wählen

• Deaktivieren Sie den Schutz für ausgehenden Datenverkehr, indem Sie den folgenden Befehl ausführen.

  ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER
  

• Fügen Sie der Sicherheitsgruppe kube-<clusterID> ausgehende Sicherheitsgruppenregeln hinzu, um den Cluster-Workern die Verbindung zu ermöglichen. Im vorherigen Beispiel wird der Dienst webhook.ibm.com auf Port 20001 verwendet.

  1. Suchen Sie die IPs für den Zugriff auf URL mit Hilfe von dig.

      dig +short URL
      ```
      Beispielbefehl.
      ```sh {: pre}
      dig +short webhook.ibm.com
      ```
      Beispielausgabe
      ```sh {: screen}
      1.2.3.4
      4.5.6.7
      ```
  1. Erstellen Sie für jede zurückgegebene IP-Adresse eine Regel.
  
  ```sh {: pre}
      ibmcloud is sg-rulec kube-<clusterID> outbound icmp_tcp_udp --remote <IP-address-or-subnet>
      ```
      Beispielbefehle.
      ```sh {: pre}
      ibmcloud is sg-rulec kube-CLUSTERID outbound tcp --port-min 20001 --port-max 20001 --remote 1.2.3.4
      ibmcloud is sg-rulec kube-CLUSTERID outbound tcp --port-min 20001 --port-max 20001 --remote 4.5.6.7
      ```
  
  

Weitere Informationen finden Sie unter „Dynamische Zugangssteuerung“

Zulassen von ausgehendem Datenverkehr zu einem öffentlichen Dienst

Wenn der oder die externen Dienste, die von Ihrer Anwendung aufgerufen werden, über eine kleine Anzahl von IPs/CIDRs verfügen, die zum Hosten dieses Dienstes verwendet werden und sich nicht sehr oft ändern, können Sie in Ihrer Sicherheitsgruppe kube-clusterID selektiv ausgehenden Zugriff auf diese IPs oder CIDRs zulassen.

Das folgende Beispiel verwendet die APIs github.com bei api.github.com.

1. Suchen Sie die IPs programmgesteuert mit curl.

   curl -sS -H "Accept: application/vnd.github+json" https://api.github.com/meta | jq '.api'
   

2. Fügen Sie jeden der CIDRs, die Sie im vorherigen Schritt gefunden haben, als Ziel einer ausgehenden Sicherheitsgruppenregel für die Sicherheitsgruppe kube-clusterID hinzu. Alternativ können Sie eine benutzerdefinierte Sicherheitsgruppe erstellen, die Sie Ihren Cluster-Workern beim Erstellen des Clusters hinzufügen.

   ibmcloud is sg-rulec kube-<clusterID> outbound icmp_tcp_udp --remote <IP-address-or-subnet>
   

Weitere Informationen finden Sie unter Informationen zu den IP-Adressen GitHub's.

Überlegungen zu Hub-and-Spoke-VPCs mit Schutz für ausgehenden Datenverkehr

In einem Hub-and-Spoke-Modell wird nur der Hub-VPC-Cluster zur DNS-Auflösung verwendet. Die Spoke-Cluster greifen über den Hub auf DNS zu. Hub-and-Spoke-Cluster befinden sich meistens in verschiedenen VPCs, die über Transit Gateway verbunden sind.

In Clustern der Version 4.15 und höher funktioniert das Hub-and-Spoke-Modell nicht ohne Anpassungen der jeweiligen Sicherheitsgruppen. Diese Anpassungen ermöglichen Datenverkehr zwischen den Hub- und Spoke-VPCs.

1. Aktualisieren Sie die Cluster im Spoke-VPC, sodass sie auf das Hub-VPC zugreifen können, indem Sie der Sicherheitsgruppe kube-<clusterID> für jeden Spoke-Cluster Regeln hinzufügen. Stellen Sie sicher, dass Sie jedem VPC-Subnetz-CIDR, in dem die Hub-Cluster-Worker bereitgestellt werden, eine Ausgangsregel hinzufügen. Wenn beispielsweise ein Spoke mit einem einzelnen Hub verbunden ist und dieser Hub über Worker in drei Zonen verfügt, müssen der Sicherheitsgruppe kube-<clusterID> des Spokes drei Regeln hinzugefügt werden, eine für jedes Subnetz.

   ibmcloud is sg-rulec kube-<spoke-clusterID> outbound icmp_tcp_udp --remote <hub-subnet-CIDR>
   

2. Aktualisieren Sie die Hub-Cluster, um Datenverkehr von den Spokes zuzulassen, indem Sie Regeln zur gemeinsam genutzten VPE-Gateway-Sicherheitsgruppe des Hubs ( kube-vpegw-vpcID ) hinzufügen. Wenn Sie alternativ Ihre eigenen benutzerdefinierten Sicherheitsgruppen für die gemeinsam genutzten VPE-Gateways verwenden, fügen Sie stattdessen Regeln zu diesen benutzerdefinierten Sicherheitsgruppen hinzu.

3. Führen Sie den folgenden Befehl aus, um die VPE-Gateways zu finden, und sehen Sie sich dann die Details des Gateways an, um die zugehörige Sicherheitsgruppe zu finden. Notieren Sie sich die Sicherheitsgruppen-ID, um ihr im nächsten Schritt Regeln hinzuzufügen.

   ibmcloud is egs
   

4. Fügen Sie eine eingehende Regel von jedem VPC-Subnetz hinzu, in dem die Spoke-Worker bereitgestellt werden. Wenn beispielsweise Spokes in drei verschiedenen Zonen, aber in jeder dieser Zonen in einem einzigen Subnetz bereitgestellt werden, werden den gemeinsam genutzten VPE Gateway-Sicherheitsgruppen des Hubs drei Regeln hinzugefügt.

   ibmcloud is sg-rulec kube-vpegw-<hub-vpcID> inbound icmp_tcp_udp --remote <spoke-subnet-CIDR>
   

Temporären Datenverkehr zum Cluster-API-Server über das öffentliche Netzwerk zulassen

VPC-Cluster-Worker verwenden das private Netzwerk, um mit dem Cluster-Master zu kommunizieren. Bisher konnten die Cluster-Worker bei VPC-Clustern, bei denen der öffentliche Service-Endpunkt aktiviert war, auf das öffentliche Netzwerk zurückgreifen, um mit dem Cluster-Master zu kommunizieren, wenn das private Netzwerk blockiert oder nicht verfügbar war.

In Clustern ab Version 4.15 ist ein Fallback auf das öffentliche Netzwerk keine Option, da der öffentliche ausgehende Datenverkehr der Cluster-Worker blockiert ist. Möglicherweise möchten Sie den Schutz für ausgehenden Datenverkehr deaktivieren, um diese öffentliche Netzwerksicherungsoption zu ermöglichen. Es gibt jedoch eine bessere Alternative. Wenn stattdessen ein vorübergehendes Problem mit der Worker-zu-Master-Verbindung über das private Netzwerk besteht, können Sie zu diesem Zeitpunkt eine temporäre Sicherheitsgruppenregel zur Sicherheitsgruppe kube-clusterID hinzufügen, um ausgehenden Datenverkehr zum Cluster-Master-Port apiserver zuzulassen. Später, wenn das Problem behoben ist, können Sie die temporäre Regel entfernen.

Sie können eine der folgenden Optionen wählen, um den Datenverkehr über das öffentliche Netz zuzulassen, wenn das private Netz ausgefallen ist.

• Fügen Sie der Sicherheitsgruppe kube-clusterID eine Sicherheitsgruppenregel hinzu, um Datenverkehr zum API-Server zuzulassen.

  1. Holen Sie sich Ihre Clusterdetails und notieren Sie sich den API-Server-Port.

      ic ks cluster get --cluster <clusterID>
      ```
      Beispielausgabe, bei der der API-Server-Port `30685` ist.
  
      ```sh {: screen}
      Name:                           prestg-sbd-vpc-4.15
      ID:                             coekl4a107ovqfndhh60
      ...
      Public Service Endpoint URL:    https://c100-e.containers.cloud.ibm.com:30685
      Private Service Endpoint URL:   https://c100.private.containers.cloud.ibm.com:30685
      ...
      ```
  1. Fügen Sie eine ausgehende Sicherheitsgruppenregel von Ihrem `kube-<clusterID>` zu `0.0.0.0/0` hinzu, um den gesamten öffentlichen Netzwerkzugriff zuzulassen.
  ```sh {: pre}
      ibmcloud is sg-rulec kube-<clusterID> outbound tcp --port-min <API port> --port-max <API port> --remote 0.0.0.0/0
      ```
      Beispielbefehl mit einem API-Server-Port von `30685`.
      ```sh {: pre}
      ibmcloud is sg-rulec kube-<clusterID> outbound tcp --port-min 30685 --port-max 30685 --remote 0.0.0.0/0
      ```
  
  

• Deaktivieren Sie den Schutz für ausgehenden Datenverkehr.

  ibmcloud oc vpc outbound-traffic-protection disable --cluster CLUSTER
  

Überprüfung der Sysdig-Integration auf rein privaten RHCOS-Clustern

Wenn sich sysdig-agent Pods in CrashLoopBackOff auf einem privaten Cluster befinden, der RHCOS-Worker verwendet, können Sie entweder den Schutz des ausgehenden Datenverkehrs deaktivieren oder den Sysdig-Agenten aktualisieren, um den Treiber eBPF zu verwenden. Weitere Informationen finden Sie unter Warum sind sysdig-agent pods in CrashLoopBackOff auf einem privaten RHCOS-Cluster?