Netzwerkregeln

Fügen Sie eine Regel mit ‘+’ entweder unter einer anderen Regel in der rechten Spalte oder mit der Schaltfläche unten rechts hinzu.

In einem Kubernetes-Cluster kann eine Anwendung durch NodePort-, LoadBalancer- oder Ingress-Dienste nach außen exponiert werden. Diese Dienste ersetzen typischerweise die Quell-IP, während sie das Source NAT (SNAT) auf den Paketen durchführen. Da die ursprüngliche Quell-IP maskiert wird, verhindert dies, dass SUSE® Security erkennt, dass die Verbindung tatsächlich von "extern" stammt.

Um die ursprüngliche Quell-IP-Adresse zu erhalten, muss der Benutzer die folgende Zeile zu den exponierten Diensten im Abschnitt 'spec' des externen Load Balancers oder Ingress-Controllers hinzufügen. (Ref: https://kubernetes.io/docs/tutorials/services/source-ip/)

Viele Implementierungen von LoadBalancer-Diensten und Ingress-Controllern fügen die Zeile X-FORWARDED-FOR zum HTTP-Anforderungsheader hinzu, um die echte Quell-IP an die Backend-Anwendungen zu kommunizieren. Dieses Produkt kann dieses Set von HTTP-Headern erkennen, die ursprüngliche Quell-IP identifizieren und die Richtlinie entsprechend durchsetzen.

Diese Verbesserung hat in einigen Setups unerwartete Probleme verursacht. Wenn die obige Zeile zu den exponierten Diensten hinzugefügt wurde und SUSE® Security Netzwerkrichtlinien so erstellt wurden, dass sie erwarten, dass die Netzwerkverbindungen von internen Proxy-/Ingress-Diensten kommen, da wir jetzt erkennen, dass die Verbindungen von "extern" zum Cluster stammen, könnte normaler Anwendungsverkehr Warnungen auslösen oder blockiert werden, wenn die Anwendungen im "Schutz"-Modus sind.

Ein Schalter ist verfügbar, um diese Funktion zu deaktivieren. Das Deaktivieren teilt SUSE® Security mit, dass die Verbindung nicht als "extern" über die X-FORWARDED-FOR-Header identifiziert werden soll. Standardmäßig ist dies aktiviert, und der X-FORWARDED-FOR-Header wird zur Durchsetzung der Richtlinie verwendet. Um es zu deaktivieren, gehen Sie zu Einstellungen → Konfiguration und deaktivieren Sie die Einstellung "Richtlinienübereinstimmung basierend auf X-Forwarded-For".

Die Funktionalität zur Durchsetzung von Egress-Netzwerkrichtlinien wurde in Version 5.1.0 für Pods zu ServiceEntry-Zielen, die mit Istio deklariert sind, hinzugefügt. Typischerweise definiert ein ServiceEntry, wie ein externer Dienst, der über den DNS-Namen angesprochen wird, in eine Ziel-IP aufgelöst wird. Vor v5.1 konnte SUSE® Security keine Regeln für Verbindungen zu einem ServiceEntry erkennen und durchsetzen, sodass alle Verbindungen als extern klassifiziert wurden. Mit 5.1 können Regeln für spezifische ServiceEntry-Ziele durchgesetzt werden. Implizite Verstöße werden für neu sichtbaren Verkehr gemeldet, wenn keine Erlaubnisregeln existieren. Diese Regeln können im Entdeckungsmodus erlernt und automatisch erstellt werden. Um diesen Verkehr zuzulassen, können Sie die Gruppe in den Entdeckungsmodus versetzen oder eine benutzerdefinierte Gruppe mit Zieladressen (oder DNS-Namen) erstellen und eine neue Netzwerkrichtlinie für dieses Ziel hinzufügen, um den Verkehr zuzulassen.

Benutzerdefinierte Gruppen können adressenbasierte Gruppen für virtuelle Hosts unterstützen. Dies ermöglicht einen Anwendungsfall, bei dem zwei verschiedene FQDN-Adressen auf die gleiche IP-Adresse aufgelöst werden, aber unterschiedliche Regeln für jeden FQDN durchgesetzt werden sollten. Eine neue benutzerdefinierte Gruppe mit ‘address=vh:xxx.yyy’ kann unter Verwendung des ‘vh:’ Indikators erstellt werden, um diesen Schutz zu aktivieren. Eine Netzwerkrichtlinie kann dann die benutzerdefinierte Gruppe als ‘From’ Quelle basierend auf dem virtuellen Hostnamen (anstatt der aufgelösten IP-Adresse) verwenden, um unterschiedliche Regeln für virtuelle Hosts durchzusetzen.