Service-Mesh-Sicherheit
Was ist Service-Mesh-Sicherheit?
Service-Mesh-SicherheitSammlung von Identitäts-, Verschlüsselungs- und Autorisierungskontrollen, die ein Service Mesh bereitstellt, um Service-zu-Service-Traffic in Cloud-Native-Umgebungen abzusichern.
Service-Mesh-Sicherheit ist das Sicherheitsmodell von Meshes wie Istio, Linkerd, Consul und Cilium Service Mesh. Ein Sidecar- oder Node-Proxy neben jeder Workload setzt mTLS zwischen Services, automatische Zertifikatsrotation, feingranulare Autorisierung (Allow/Deny nach Quell-Identität, Pfad, Methode, JWT-Claims) und Traffic-Observability durch. Das Mesh verlagert Vertrauen von der Netzwerkposition auf die Workload-Identität und unterstützt Zero-Trust-Architekturen innerhalb von Kubernetes und Multi-Cluster-Umgebungen. Risiken sind Sidecar-Fehlkonfigurationen, kompromittierte Control Planes, schwache Zertifikatsstellen und Traffic, der das Mesh umgeht, wenn die Sidecar-Injection unvollständig ist. Schutz: CIS-Hardening, Policy-Review und Monitoring der Control Plane.
● Beispiele
- 01
Istio-AuthorizationPolicy beschränkt Aufrufe auf payments-service ausschließlich von checkout-service.
- 02
Linkerd Auto-mTLS zwischen allen Pods eines Namespace ohne Applikationsänderung.
● Häufige Fragen
Was ist Service-Mesh-Sicherheit?
Sammlung von Identitäts-, Verschlüsselungs- und Autorisierungskontrollen, die ein Service Mesh bereitstellt, um Service-zu-Service-Traffic in Cloud-Native-Umgebungen abzusichern. Es gehört zur Kategorie Cloud-Sicherheit der Cybersicherheit.
Was bedeutet Service-Mesh-Sicherheit?
Sammlung von Identitäts-, Verschlüsselungs- und Autorisierungskontrollen, die ein Service Mesh bereitstellt, um Service-zu-Service-Traffic in Cloud-Native-Umgebungen abzusichern.
Wie funktioniert Service-Mesh-Sicherheit?
Service-Mesh-Sicherheit ist das Sicherheitsmodell von Meshes wie Istio, Linkerd, Consul und Cilium Service Mesh. Ein Sidecar- oder Node-Proxy neben jeder Workload setzt mTLS zwischen Services, automatische Zertifikatsrotation, feingranulare Autorisierung (Allow/Deny nach Quell-Identität, Pfad, Methode, JWT-Claims) und Traffic-Observability durch. Das Mesh verlagert Vertrauen von der Netzwerkposition auf die Workload-Identität und unterstützt Zero-Trust-Architekturen innerhalb von Kubernetes und Multi-Cluster-Umgebungen. Risiken sind Sidecar-Fehlkonfigurationen, kompromittierte Control Planes, schwache Zertifikatsstellen und Traffic, der das Mesh umgeht, wenn die Sidecar-Injection unvollständig ist. Schutz: CIS-Hardening, Policy-Review und Monitoring der Control Plane.
Wie schützt man sich gegen Service-Mesh-Sicherheit?
Schutzmaßnahmen gegen Service-Mesh-Sicherheit kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.
Welche anderen Bezeichnungen gibt es für Service-Mesh-Sicherheit?
Übliche alternative Bezeichnungen: Mesh-Sicherheit, Sidecar-Sicherheit.
● Verwandte Begriffe
- cloud-security№ 559
Istio-Sicherheit
Sicherheits-Feature-Set des Istio-Service-Mesh: Workload-Identität via SPIFFE, automatisches mTLS und AuthorizationPolicy/RequestAuthentication für feingranulare Zugriffskontrolle.
- network-security№ 1262
Zero Trust Network
Eine Netzwerkarchitektur, die Nutzer, Geräte oder Dienste niemals automatisch vertraut und jede Verbindung kontinuierlich identitätsbasiert prüft.
- cloud-security№ 1248
Workload-Identität
Kryptografische Identität für einen Service, Container oder eine Funktion, mit der dieser sich gegenüber anderen Systemen ohne langlebige geteilte Secrets authentifiziert.
- cloud-security№ 1078
SPIFFE
Offener Standard zur Vergabe kryptografischer, portabler Identitäten an Workloads über URI-basierte SPIFFE-IDs und kurzlebige X.509- oder JWT-SVIDs.
- cloud-security№ 600
Kubernetes-Sicherheit
Schutz eines Kubernetes-Clusters – API-Server, Control Plane, Nodes, Workloads und Netzwerk – vor Fehlkonfiguration, Kompromittierung und lateraler Bewegung.
● Siehe auch
- № 1079SPIRE-Runtime
- № 756OPA (Open Policy Agent)
- № 839Policy as Code
- № 991Security as Code