chen-keinan/mesh-kridikAutomatisierter Sicherheitsprüfer für Kubernetes-Cluster mit Istio-Service-Mesh, der Best Practices über OPA-Richtlinien durchsetzt und Remediation-Berichte für Fehlkonfigurationen erstellt.
Erhöhen Sie die Sicherheit Ihres Kubernetes-Service-Mesh !!
mesh-kridik ist ein Open-Source-Sicherheitsprüfer, der verschiedene Sicherheitsüberprüfungen auf einem Kubernetes-Cluster mit Istio-Service-Mesh durchführt und einen Sicherheitsbericht ausgibt.
Die Sicherheitsprüfungen sind die vollständige Umsetzung der Istio-Sicherheitsbest Practices
Die Sicherheitsüberprüfungen werden auf einem Kubernetes-Cluster mit Istio-Service-Mesh durchgeführt und nutzen OPA (Open Policy Agent) zur Durchsetzung von Sicherheitsregeln. Der ausgegebene Auditbericht enthält: die Grundursache des Sicherheitsproblems und einen vorgeschlagenen Lösungsvorschlag für das Sicherheitsproblem.
git clone https://github.com/chen-keinan/mesh-kridik
cd mesh-kridik
make build
Ohne Flags führt Mesh-Kridik alle Tests aus.
./mesh-kridik
Führen Sie Mesh-Kridik mit Flags aus, um Tests nach Bedarf auszuführen.
Usage: mesh-kridik [--version] [--help] <command> [<args>]
Available commands are:
-r , --report : run security checks and generate remediation report
-i , --include: execute only specific security check, example -i=1.1
-e , --exclude: ignore specific security check, example -e=1.1,2.0
Tests ausführen und einen Fehlerbericht sowie deren Behebungen generieren.
./mesh-kridik -r
Kube-kridik stellt einen Hook für Benutzer-Plugins zur Verfügung Beispiel :
go build -buildmode=plugin -o=~/<plugin folder>/<plugin>.so ~/<plugin folder>/<plugin>.go
cp ~/<plugin folder>/<plugin>.so ~/.kube-kridik/plugins/compile/<plugin>.so
Kube-kridik unterstützt diese Spezifikationen und kann leicht erweitert werden:
Diese Spezifikationen können leicht erweitert werden, indem die Spezifikationsdateien unter dem Ordner ~/.mesh-kridik/security/mesh/istio geändert werden.
| Name | Beschreibung | Auswirkung |
|---|---|---|
| Mutual TLS | Istio-Mutual-TLS-Proxys sind standardmäßig im permissiven Modus konfiguriert | Proxys akzeptieren sowohl Mutual-TLS- als auch Klartextverkehr |
| Istio Safer Authorization Policy Patterns | Verwenden Sie ALLOW-mit-positivem-Match- oder DENY-mit-negativem-Match-Muster | Diese Autorisierungsrichtlinien-Muster sind sicherer, da das schlechteste Ergebnis bei einer Richtlinienabweichung eine unerwartete 403-Ablehnung anstelle einer Umgehung der Autorisierungsrichtlinie ist. |
| Pfadnormalisierung in Autorisierungsrichtlinie | Der Durchsetzungspunkt für Autorisierungsrichtlinien ist der Envoy-Proxy anstelle des üblichen Ressourcenzugriffspunkts in der Backend-Anwendung | Eine Abweichung kann entweder zu unerwarteter Ablehnung oder zu einer Richtlinienumgehung führen |
| TLS-Ursprung für Egress-Verkehr | Verwendung von DestinationRule auf Service ServiceEntry für Egress-Verkehr | Wird TLS-Ursprung für den Egress-Verkehr zu einem externen Dienst nicht verwendet, wird dieser als Klartext gesendet. |
| Protokollerfassung | Das Dienstprotokoll explizit deklarieren | Eine fehlgeschlagene Erfassung kann zu unerwartetem Verkehrsverhalten führen |
| CNI-Unterstützung | Transparente Verkehrserfassung durch Istio | Nicht der gesamte Netzverkehr wird erfasst |
| Zu breite Hosts | Zu breite Host-Einstellungen im Gateway vermeiden | Kann potenzielle Offenlegung unerwarteter Domänen verursachen |
| Gateway-Erstellungsberechtigungen einschränken | Die Erstellung von Gateway-Ressourcen auf vertrauenswürdige Cluster-Administratoren beschränken | Kann zur Erstellung von Gateways durch nicht vertrauenswürdige Benutzer führen |
| Ein Limit für Downstream-Verbindungen konfigurieren | Aktualisieren Sie global_downstream_max_connections in der ConfigMap entsprechend der Anzahl gleichzeitiger Verbindungen, die von einzelnen Gateway-Instanzen in Ihrer Bereitstellung benötigt werden. Sobald das Limit erreicht ist, beginnt Envoy, TCP-Verbindungen abzulehnen. | Keine Begrenzung der Anzahl von Downstream-Verbindungen kann von einem böswilligen Akteur ausgenutzt werden |
| Drittanbieter-Servicekonto-Token konfigurieren | Es wird empfohlen, Drittanbieter-Token zu konfigurieren, da die Eigenschaften des Erstanbieter-Tokens weniger sicher sind | Die Eigenschaften des Erstanbieter-Tokens sind weniger sicher und könnten zu einer Authentifizierungslücke führen |
| Steuerungsebene | Istiod legt standardmäßig einige unauthentifizierte Klartext-Ports aus Bequemlichkeit offen | Legt den XDS-Dienstport 15010 und den Debug-Port 8080 über unauthentifizierten Klartext offen |
| Datenebene | Der Proxy legt eine Vielzahl von Ports offen | Die Anwendungen, die im selben Pod wie der Proxy ausgeführt werden, haben Zugriff; es gibt keine Vertrauensgrenze zwischen Sidecar und Anwendung |
| Grenzen der Verkehrserfassung verstehen | Sicherung des Egress-Verkehrs durch Festlegen des meshConfig.outboundTrafficPolicy.mode | Der Zugriff auf externe Dienste wird nicht kontrolliert |