Istio-Sicherheit
Was ist Istio-Sicherheit?
Istio-SicherheitSicherheits-Feature-Set des Istio-Service-Mesh: Workload-Identität via SPIFFE, automatisches mTLS und AuthorizationPolicy/RequestAuthentication für feingranulare Zugriffskontrolle.
Istio Security ist das Sicherheits-Subsystem des Istio-Service-Mesh. Die Control Plane (istiod) stellt SPIFFE-basierte X.509-Identitäten für jede Workload aus und konfiguriert Envoy-Sidecars, sodass mTLS zwischen Pods etabliert wird und kein Klartext-Ost-West-Traffic mehr existiert. PeerAuthentication-Policies erzwingen mTLS im Modus STRICT oder PERMISSIVE auf Namespace- oder Workload-Ebene. AuthorizationPolicy bietet Allow/Deny-Regeln über Quellidentitäten, Hosts, Pfade, Methoden und Bedingungen; RequestAuthentication validiert JWTs gegenüber Issuern. Betriebsrisiken sind ein falsch konfiguriertes PERMISSIVE-Setup, zu offene Allow-Policies und ungepatchte istiod-CVEs (z. B. CVE-2024-3727). Best Practice: STRICT mTLS, Default-Deny-Authorization-Policy und Audit von Policy-Änderungen.
● Beispiele
- 01
PeerAuthentication mtls.mode=STRICT im Namespace prod erzwingt mTLS für alle Pods.
- 02
Default-Deny-AuthorizationPolicy erlaubt reviews-service ausdrücklich, ratings-service aufzurufen.
● Häufige Fragen
Was ist Istio-Sicherheit?
Sicherheits-Feature-Set des Istio-Service-Mesh: Workload-Identität via SPIFFE, automatisches mTLS und AuthorizationPolicy/RequestAuthentication für feingranulare Zugriffskontrolle. Es gehört zur Kategorie Cloud-Sicherheit der Cybersicherheit.
Was bedeutet Istio-Sicherheit?
Sicherheits-Feature-Set des Istio-Service-Mesh: Workload-Identität via SPIFFE, automatisches mTLS und AuthorizationPolicy/RequestAuthentication für feingranulare Zugriffskontrolle.
Wie funktioniert Istio-Sicherheit?
Istio Security ist das Sicherheits-Subsystem des Istio-Service-Mesh. Die Control Plane (istiod) stellt SPIFFE-basierte X.509-Identitäten für jede Workload aus und konfiguriert Envoy-Sidecars, sodass mTLS zwischen Pods etabliert wird und kein Klartext-Ost-West-Traffic mehr existiert. PeerAuthentication-Policies erzwingen mTLS im Modus STRICT oder PERMISSIVE auf Namespace- oder Workload-Ebene. AuthorizationPolicy bietet Allow/Deny-Regeln über Quellidentitäten, Hosts, Pfade, Methoden und Bedingungen; RequestAuthentication validiert JWTs gegenüber Issuern. Betriebsrisiken sind ein falsch konfiguriertes PERMISSIVE-Setup, zu offene Allow-Policies und ungepatchte istiod-CVEs (z. B. CVE-2024-3727). Best Practice: STRICT mTLS, Default-Deny-Authorization-Policy und Audit von Policy-Änderungen.
Wie schützt man sich gegen Istio-Sicherheit?
Schutzmaßnahmen gegen Istio-Sicherheit kombinieren typischerweise technische Kontrollen und operative Praktiken, wie in der Definition oben beschrieben.
Welche anderen Bezeichnungen gibt es für Istio-Sicherheit?
Übliche alternative Bezeichnungen: Istio-mTLS, Istio-AuthorizationPolicy.
● Verwandte Begriffe
- cloud-security№ 1014
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.
- 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№ 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.
- 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№ 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