Cloud Native News #2: Konferenzeindrücke

Serverless

Mit zunehmender Reife und einem größerem Funktionsumfang von Cluster-Orchestratoren wie Kubernetes wächst die Komplexität von Anwendungen, die gegen den Cluster-Orchestrator als PaaS-Schnittstelle gebaut sind. Damit gewinnt die Abstraktion der Abstraktion an Bedeutung: Hinter Serverless oder auch Function-as-a-Service (FaaS) steckt die Idee, kleine, zustandslose Funktionen direkt auszuführen, ohne sich um Infrastruktur, Container oder Orchestrierung kümmern zu müssen. Diese Funktionen spielen in einer Cloud-Native-Architektur gerade als Integrationsschicht zwischen Clients und den Microservices eine wichtige Rolle.

Wer nicht die etablierten Serverless-Produkte großer Cloud-Provider nutzen und sich damit an einen Hersteller binden will, findet im Kubernetes-Universum drei interessante Projekte: OpenFaaS, Fission und Kubeless, die sich in ihrem Reifegrad, den unterstützten Programmiersprachen und in der Art der Kubernetes-Integration unterscheiden.

Cloud-Native-Security

Es tut sich gerade viel im Bereich Cloud-Native-Security, also Sicherheitstechniken, die speziell für den Einsatz auf Cloud-Native-Plattformen wie Kubernetes ausgelegt sind. Das verwundert nicht, denn der Bedarf ist groß, da viele IT-getriebene Unternehmen bei der Sicherheit noch die größten Zweifel auf ihrem Weg in die Cloud haben.

Identität ist die Grundvoraussetzung für die wichtigen IT-Security-Säulen Authentifizierung und Autorisierung. Das Identifizieren von Benutzer übernehmen Systeme wie OpenID Connect zuverlässig. Offen bleibt jedoch die Frage, wie Software mit der Identität bei einer Maschine-zu-Maschine-Kommunikation in einem Microservices-System umgeht. Notwendig ist ein Konzept für die Identität der kommunizierenden Workloads. Das Secure Production Identity Framework for Everyone (SPIFFE) bietet einen Standard, der Workload-Identität interoperabel umsetzt. SPIFFE besteht aus einem Standard für Identitäten (SPIFFE ID), einem Standard, um diese Identitäten als kryptographische Dokumente auszudrücken (SPIFFE Verifiable Identity Document, SVID) und einer API, um SVIDs auszustellen und zu verteilen. Dazu gibt es mit SPIRE eine Referenzimplementierung.

In größeren Umgebungen stellt sich die Frage, wie sich Zugriffsbeschränkungen auf Cluster-Ressourcen umsetzen lassen. Kubernetes bietet dafür seit Version 1.8 Role-Based Access Control, womit Administratoren auf der Ebene Orchestrator effektiv Berechtigungskonzepte umsetzen können.

Für allgemeinere Problemstellungen gibt es OPA, den Open Policy Agent (OPA) als Baustein für Rule-Based Access Control. OPA ermöglicht es, beliebig einfache oder komplexe Policies umzusetzen und bietet eine einfache domänenspezifische Sprache (Domain-Specific Language, DSL) für Policies sowie einen Dienst, um Policies automatisch auszuwerten.

Produkte für Container-Sicherheit sind die Virenscanner für die Cloud. Sie helfen, das Schutzniveau zu erhöhen und bieten in verschiedenen Kombinationen und Ausbaustufen die Überprüfung von Containern auf Sicherheitslücken, Laufzeitschutz, die Überprüfung und Durchsetzung von Compliance-Regeln sowie Zugriffskontrolle und Transparenz über die Netzwerkkommunikation. Nennenswerte Produkte sind Twistlock, Aquasec und der Newcomer Alcide. Eine Übersicht, wie man auch mit Kubernetes-Bordmitteln einen gewissen Grundschutz erzielt, zeigen die Folien einer weiteren KubeCon-Präsentation.

Ebenfalls zu beobachten ist, dass Vault immer mehr zum Standard für die Verwaltung und die Bereitstellung von Secrets wird. Es gibt zwar diverse Alternativen wie Keywhiz, die aber weitestgehend unbekannt und weit weniger gut in das Cloud-Native-Ökosystem integriert sind.

Service Meshes

Ein Service Mesh ist eine Infrastrukturschicht, die die Service-zu-Service-Kommunikation übernimmt. Service Meshes greifen im Gegensatz zu klassischen Software-Defined Networks wie der Kombination aus Flannel und Calico nicht in die Transportschicht ein. Das Mesh läuft zwischen Transportschicht und Applikation.

Ein Service Mesh besteht aus Proxies, die als Botschafter für die Applikationen dienen und einer Kontrollschicht, die die Proxies steuert. Die Kommunikation zwischen Anwendung und Proxy bleibt lokal, und die Kommunikation zwischen den Proxies ist automatisch abgesichert. Damit lassen sich Querschnittsaspekte wie Identität, Authentifizierung und Autorisierung von Workloads, Resilienz, Traffic-Management und Observability elegant und transparent umsetzen.

Istio ist der aufstrebende Star unter den Service Meshes. Es nutzt Envoy als Proxy und sichert Verbindungen SPIFFE-konform mit mTLS. Istio steht am Anfang. In der aktuellen Version 0.3.0 ist noch kein Feature stabil, und die meisten sind als Alpha gekennzeichnet. Da Lyft, Google und IBM das Projekt treiben, besteht jedoch kein Zweifel, dass Istio schnell reifen wird. Wer schon jetzt mit Istio spielen will, dem sei das zugehörige Google Codelab empfohlen.

Aktuell unterstützt Istio lediglich Kubernetes; der Support für Cloud Foundry und Mesos ist geplant. Für die nahe Zukunft steht außerdem die Integration von Services außerhalb des Mesh an.

Neben Istio lohnt es sich, Conduit im Blick zu behalten. Dabei handelt es sich um ein neues, experimentelles Service Mesh von den Machern von Linkerd mit einem besonders schlanken, in Rust geschriebenen Proxy.

Die CNCF-Projekte werden erwachsen

Neben vier neuen 1.0-Versionen gibt es auch bei Prometheus und Kubernetes wesentliche Neuerungen:

  • CoreDNS 1.0 bringt im Wesentlichen Verbesserungen bei Der Performance und dem Funktionsumfang des Kubernetes-Plugins.
  • Containerd 1.0 ist betriebsreif. Mit dabei sind unter anderem ein neues Laufzeitmodell, Image-Push/Pull durch den Client, ein überarbeitetes Storage-System, Unterstützung für Metadaten und eine API mit Rich Client.
  • Fluentd 1.0 unterstützt Multiprozess-Workers, Windows, sowie Genauigkeiten kleiner einer Sekunde. Zudem bringt es eine Plug-in-API sowie neue Datenverwaltungs- und Netzwerkfunktionen.
  • Jaeger 1.0 bringt eine überarbeitete Nutzerschnittstelle, eine bessere Navigation, Prometheus als Default, eine frühe Version des C++-Clients und Abwärtskompatibilität mit Zipkin. Generell ist festzustellen, dass Jaeger den bisherigen Platzhirschen Zipkin deutlich überholt. Das ist kein Wunder bei zehn Vollzeitentwicklern, die bei Uber an Jaeger arbeiten.
  • Prometheus 2.0 hat eine neue Zeitreihen-DB. Aufbauend auf den Ideen von Chronix bringt die neue Datenbank deutliche Performanceverbesserungen mit sich.
  • Kubernetes 1.9 kennzeichnet StatefulSet, DaemonSet, ReplicaSet und Deployment-APIs als stabil und damit als uneingeschränkt für die Produktion geeignet. Dazu gibt es Beta-Support für Windows-Container und Alpha-Support für das Container Storage Interface (CSI) [25], das Entwickler allerdings noch von Hand aktivieren müssen.