Service Mesh Consulting
Assessment

Service Mesh Consulting

Wir sichern Kubernetes-Cluster in regulierten Branchen mit Istio Service Mesh.

Am Anfang steht eine Befundliste aus deinem Cluster. Im Posture Check liest dein Team die laufende Konfiguration mit unserem Collection-Kit aus. Wir werten sie aus und hinterlegen zu jedem Befund einen Config-Beleg. Läuft bei dir noch kein Mesh, zeigt der Pre-Mesh-Check mit demselben Kit, welche Lücken ein Mesh schließen würde.

Strategiegespräch anfragen Beispielbefund ansehen
Policies erlauben oder sperren Service-Verkehr, ohne Policy kommt jeder Aufruf durch, und der Posture Check hält diese Lücke als Befund mit Zeitstempel fest.
13
Prüfbereiche im Posture Check
90
Minuten Readout mit deinem Team
0
Zugriffe von uns auf deinen Cluster im Posture Check
1.4
Istio-Version, seit der wir Service Meshes betreiben

Symptome im Alltag des Platform-Teams

Ein fehlendes oder falsch konfiguriertes Service Mesh fällt selten als Ausfall auf. Es kostet Zeit und Nerven an Stellen, die jedes Platform-Team kennt.

Das Wissen hängt an ein, zwei Leuten
Netzwerk- und Security-Wissen liegt bei wenigen Köpfen. Fällt einer aus oder kündigt, steht die Weiterentwicklung still.
Der Ingress ist Eigenbau
Gewachsene Nginx-Configs und Skripte tragen den Verkehr. Jedes Update wird zum Risiko für den laufenden Betrieb.
Das Audit fragt nach dem Verkehr im Cluster
Ob Verbindungen zwischen Workloads verschlüsselt sind und wer wen erreichen darf, lässt sich nicht belegen. Zero-Trust steht im Konzept, in der Konfiguration ist davon wenig zu sehen.

Leistungen vom Befund bis zum Betrieb

Jede Station steht für sich. Nach jeder entscheidest du, ob ihr weitergeht oder selbst übernehmt.

  1. Posture Check Einstieg

    Befundliste aus deinem Cluster, jeder Punkt mit Config-Beleg, dazu ein Readout von 90 Minuten. Ohne Mesh heißt er Pre-Mesh-Check.

  2. Readiness Assessment

    Die ganze Mesh-Posture mit Report, priorisierter Roadmap und Workshop am Setup. Beauftragt ihr es binnen 90 Tagen nach dem Check, rechnen wir den Check vollständig an.

  3. Dein Team am Steuer

    Architektur-Mentoring und begleitete Sprints, bis euer Platform-Team das Mesh selbst betreibt und weiterentwickelt.

  4. Governance im Betrieb

    Policies als Code, automatisiert ausgerollt und überwacht, damit Abweichungen auffallen, bevor eine Prüfung sie findet.

Preis und Termin klären wir im Strategiegespräch. Du fragst es über das Assessment an, ein Formular in sechs Schritten.

Die Methodik des Posture Checks

Vier Schritte, jeder mit Lieferobjekt und Abnahmekriterium. Der Pre-Mesh-Check läuft genauso.

SchrittWas passiertLieferobjektAbnahme
Scoping30 Minuten Wir legen Cluster und Namespaces fest und klären die Nachweisfrage: Wer verlangt bei euch was, und bis wann? Scope auf einer Seite: Cluster, Umfang, Anlass, Termin fürs Readout. Du bestätigst den Scope schriftlich. Was nicht drinsteht, prüfen wir nicht.
Collection-Kit Dein Team führt das Kit mit Leserechten aus. Es sammelt Mesh-Ressourcen, MeshConfig, NetworkPolicies, Ingress und Service-Accounts. Kit mit Anleitung. Die Ausgabe liegt bereinigt als Archiv bei dir. Dein Team hat die Ausgabe gesehen und gibt sie frei. Nur die bereinigte Ausgabe verlässt dein Haus.
Auswertung Wir werten die Ausgabe gegen unseren Befundkatalog aus: 13 Prüfbereiche bei laufendem Mesh, die typischen Lücken bei einem Cluster ohne Mesh. Befundliste nach Schweregrad, jede Zeile mit Config-Beleg, Quelle und Datum. Ein Befund ohne Config-Beleg kommt nicht auf die Liste.
Readout90 Minuten Remote, mit den Leuten, die das Mesh betreiben, und gern mit der Person, die den Nachweis braucht. Die besprochene Befundliste mit einer Empfehlung zum nächsten Schritt. Du weißt, welcher Befund zuerst drankommt und ob ihr das Readiness Assessment braucht.

Nicht enthalten: ein gestalteter Report, eine Roadmap mit Aufwänden, ein Workshop am Setup und die Umsetzung. Report, Roadmap und Workshop gehören zum Readiness Assessment.

Auszug aus einer Befundliste

Alle Werte in dieser Befundliste sind Beispielwerte und stammen aus keinem Kundencluster.

Der Norm-Bezug ordnet einen Befund dem Thema einer Vorgabe zu. Ob ihr eine Vorgabe erfüllt, bewertet der Check nicht.

Befundliste aus dem Posture Check
Aktenzeichen
PC-2026-0914
Stand
14.09.2026
Auszug
Befunde 4 und 5
Werte
Beispielwerte
Befund
PC-04
Erhoben
Bereich
mTLS-Posture
Schweregrad
hoch

Im Namespace payments steht die PeerAuthentication auf PERMISSIVE. Damit nehmen die 8 Workloads mit Sidecar weiter Verbindungen im Klartext an. Die übrigen 3 von 11 laufen ohne Sidecar und sind nicht im Mesh.

Config-Beleg aus dem Collection-Kit, bereinigt. Quelle: kubectl get peerauthentication default -n payments -o yaml

apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: payments
spec:
  mtls:
    mode: PERMISSIVE
Norm-Bezug
DORA: Verschlüsselung interner Netzverbindungen
NIS2: Konzepte und Verfahren für den Einsatz von Kryptografie
Empfehlung
Die 3 Workloads zuerst ins Mesh holen, dann den Namespace auf STRICT stellen. Reihenfolge und Risiko besprechen wir im Readout.
Befund
PC-05
Erhoben
Bereich
Autorisierung
Schweregrad
mittel

Für payments-api existiert keine AuthorizationPolicy. Damit lässt Istio jeden Aufruf des Dienstes zu, wegen PC-04 auch von Workloads ohne Sidecar im Klartext.

Config-Beleg aus dem Collection-Kit, bereinigt. Quelle: kubectl get authorizationpolicy -n payments -o yaml, im Root-Namespace istio-system ebenso leer

apiVersion: v1
items: []
kind: List
metadata:
  resourceVersion: ""
Norm-Bezug
BSI IT-Grundschutz, Baustein APP.4.4 Kubernetes: Netztrennung zwischen Namespaces, bei erhöhtem Schutzbedarf Mikro-Segmentierung

Einblicke in zwei Projekte, anonymisiert

Kundennamen und Logos zeigen wir nicht, das schließen die NDAs aus. Beide Fälle folgen demselben Raster.

Kurzgutachten Fall A

2.000+
Entwickler auf der Plattform
Branche
Öffentlicher Sektor
Größe
2.000+ Entwickler
Ausgangslage
Über Jahre gewachsener Ingress mit vielen eigenen Skripten. Die nächste Prüfung stand bevor.
Befund
Ingress-Regeln ohne gemeinsamen Standard, mTLS-Policies nicht automatisiert.
Ergebnis
Istio ist ausgerollt und die mTLS-Policies laufen automatisiert. Das Audit wurde bestanden. Produktive Namespaces mit mTLS im Modus STRICT: 100 %Beispielwert
Dauer
9 MonateBeispielwert

Kurzgutachten Fall B

2
Architekten mit dem gesamten Netzwerk-Security-Wissen
0
externe Abhängigkeiten im Betrieb nach dem Mentoring
Branche
Finanzdienstleistung, streng reguliert
Größe
Platform-Team mit 14 EngineersBeispielwert
Ausgangslage
Das Wissen über die Netzwerk-Security im Cluster lag bei zwei Architekten.
Befund
Zwei Personen als Single Point of Failure, die interne Governance ließ sich so nicht skalieren.
Ergebnis
Nach dem Architektur-Mentoring steuert das interne Platform-Team das Mesh selbst, ohne externe Abhängigkeit im Betrieb. Personen, die das Mesh eigenständig betreiben: von 2 auf 6Beispielwert
Dauer
6 MonateBeispielwert

Vertraulichkeit gehört zu unserer Arbeit. Deshalb zeigen wir ausgewählte Projektsituationen ohne Kundennamen oder identifizierende Details. Ergänzende Beispielkennzahlen sind als „Beispielwert“ gekennzeichnet.

Zahlen mit dem Zusatz „Beispielwert“ sind frei gewählt und stammen aus keinem Kundenprojekt. Sie zeigen nicht, was bei dir erreichbar ist.

Aus dem Maschinenraum

Porträt des Senior-Ingenieurs für Service-Mesh-Architektur

Ein Mesh in Produktion sieht selten so aus wie seine Doku. Der Check zeigt dir den Ist-Zustand, belegt in der Config und nicht in Folien, damit du mit deinem Team über Fakten entscheidest. Und jeden Mesh-Check nehme ich immer auch persönlich ab: Uli Renz, vom Scoping bis zum Readout.

  • Service Meshes im Betrieb seit Istio 1.4
  • Praxis in streng regulierten Umgebungen

Vom Kontakt zum Check

Das Formular fragt mehr als üblich, weil wir vor dem ersten Anruf wissen wollen, ob der Check zu deiner Lage passt.

Strategiegespräch anfragen

Lieber zuerst schreiben? info@istio-consulting.de

Assessment
sechs Schritte
Kontaktdaten, Ausgangslage, Team und Rahmen. Am Ende steht „Bewerbung absenden“.
Rückruf
binnen 48 Stunden, werktags
Wir melden uns telefonisch unter der Nummer aus dem Formular.
Strategiegespräch
etwa 10 Minuten
Wir klären, ob eine Zusammenarbeit für beide Seiten passt.
Check
nach Absprache
Wir vereinbaren den Termin fürs Scoping.

Was oft gefragt wird

Braucht ihr Zugang zu unserem Cluster?

Nein. Das Collection-Kit läuft bei dir, mit Leserechten. Wir bekommen nur die bereinigte Ausgabe, die dein Team vorher freigegeben hat.

Wir betreiben gar kein Mesh. Ergibt der Check trotzdem Sinn?

Ja, dafür gibt es den Pre-Mesh-Check. Ein Mesh ist kein Selbstzweck. Der Check zeigt, wie dein Cluster bei Segmentierung und Verschlüsselung im Transit dasteht und ob ein Mesh für euch der einfachere Weg dorthin wäre.

Kostet Istio spürbar Latenz?

Ein schlecht eingestelltes Mesh schon. Zwei der 13 Prüfbereiche betreffen den Overhead direkt: ob eine Sidecar-Resource die Konfiguration jedes Proxys auf die Dienste begrenzt, die er tatsächlich anspricht, und ob die Sidecars Requests und Limits haben.

Können wir Istio schrittweise einführen?

Ja. Üblich ist der Start am Ingress oder in unkritischen Namespaces. mTLS wird erst auf STRICT gestellt, wenn die Telemetrie zeigt, welcher Verkehr wo läuft. Welcher Namespace bei euch zuerst drankommt, steht nach dem Check in der Befundliste.

Was passiert nach dem Readout?

Du entscheidest. Ihr könnt die Liste selbst abarbeiten. Braucht ihr eine priorisierte Roadmap und einen Workshop am eigenen Setup, beauftragt ihr binnen 90 Tagen nach dem Check das Readiness Assessment, und wir rechnen den Check vollständig an.

Vertiefung: technische Cheatsheets unter istio-cheatsheet.de.