Service-Mesh: Istio 1.7 erweitert VM-Support und bietet mehr Sicherheit

Inhaltsverzeichnis

Das Istio-Team hat Version 1.7 der Service-Mesh-Plattform veröffentlicht. Der Fokus des Updates liegt auf der Steigerung der Sicherheit. Neben Neuerungen für die Validierung der Trust Domain arbeiten die Entwickler hinter Istio weiter daran, die Unterstützung für nicht in Kubernetes laufende Workloads auszubauen.

Für mehr Sicherheit

Hinsichtlich der Sicherheit bringt das Update einige Neuerungen mit. Beispielsweise lassen sich Destination-Rule-Zertifikate, die als Dateien gemountet sind, nun mithilfe des Safety Data Sheet (SDS) verteilen. Darüber hinaus ist es möglich, für Egress Gateways, die Origination via TLS/mTLS (Mutual TLS) durchführen, Client-Zertifikate als Secrets bereitzustellen.

Das Istio-Team hat darüber hinaus die Validierung der Trust Domain überarbeitet. Dadurch lässt sich neben dem bisherigen HTTP- nun auch der TCP-Verkehr validieren. Die Trust Domain Validation hält zudem Support für trustDomainAliases in der MeshConfig-Ressource bereit. Entwickler können zudem mit Istio 1.7 über die Elliptische-Kurven-Kryptographie (ECC) mit der Zertifizierungsstelle kommunizieren. Das Istio-Team erhofft sich damit hohe Sicherheit bei gleichzeitig hoher Effizienz. Neben einigen Fehlerbehebungen mit dem Istio-Gateway und mTLS hat das Entwicklerteam an der Bereitstellungen von Gateway gearbeitet. Die Service-Mesh-Plattform führt sie ab sofort standardmäßig als "non-root" aus.

Neuerungen für bessere Bedienbarkeit

Um Istio in der Bedienung handlicher zu machen, bringt das Update Neuerungen für das Analysewerkzeug istioctl. Neben einer Warnung bei der Verwendung von potenziell unsicheren DestinationRule-Konfigurationen erhalten Entwickler einen Hinweis, wenn sie auf veraltete Mixer-Ressourcen zurückgreifen. Individuelle Einstellungen zur Nutzung des Analyse-Tools müssen regelmäßige Istio-Anwender nun nicht mehr vor jeder Nutzung vornehmen, sie lassen sich durch das Update im Home-Verzeichnis – oder an einer anderen passenden Stelle – speichern.

Um die Zuverlässigkeit bei Implementierungen zu erhöhen, bei denen eine Anwendung direkt nach dem Start über den Proxy auf Ressourcen zugreift, bietet Istio die Möglichkeit, den Start der Anwendungen bis nach dem Start des Sidecars zu verzögern. Darüber hinaus hat das Team hinter der Service-Mesh-Plattform die Metriken des Istio-Agenten offengelegt, damit Entwickler den Prozess besser beobachten können.

VM-Support und Sicherheit

Das Istio-Team hat sich für das Jahr 2020 zum Ziel gesetzt, die Unterstützung für nicht in Kubernetes laufende Workloads auszubauen. Mit Istio 1.6 unternahm das Team erste Schritte auf diesem Weg. Mit der neuen API WorkloadEntry sollen sich nicht auf Kubernetes basierende Workloads leichter in Istio darstellen lassen. Dafür werden virtuelle Maschinen (VMs) oder Bare-Metal-Workloads auf dieselbe Ebene wie ein Kubernetes-Pod gehoben. Entwickler können einen Service definieren, der neben den Pods auch von VMs unterstützt wird. VM-Workloads können auf diese Weise zu einem Kubernetes-Cluster migriert werden, ohne den Traffic von und zu diesem zu unterbrechen.

Version 1.7 knüpft an dieser Stelle an und bringt Neuerungen im Alpha-Status. Dazu zählt beispielsweise, dass Arbeitslasten, die auf VMs im Mesh laufen, einen sicheren Bootstrapping-Prozess erhalten, zusammen mit einer automatischen Zertifikatsrotation. Zusätzlich können Entwickler ab sofort den Proxy-Status für VM-basierte Arbeitslasten validieren, während die Validierung bisher nur für Kubernetes-basierte Arbeitslasten verfügbar war.

Das Update entfernt außerdem ungültige Metriken der Steuerebenen und unterbindet die standardmäßige Installation von Telemetrie-Add-ons. Nähere Informationen zu Istio 1.7 finden sich in den Release Notes.

(mdo)