Im Kern steht oft die Frage nach dem Datenschutz. Oft scheint vielen das Risiko zu groß, dass ihre sensiblen Daten in der Cloud veruntreut oder mitgelesen werden könnten. Die Cloud-Anbieter begegnen solchen Bedenken mit kunden-individuellen Sicherheitskonzepten, die mal mehr, mal weniger tragfähig sind.
Etwa Methoden wie „Encryption at rest“, also das Verschlüsseln der Daten auf den Festplatten der Systeme. Was zunächst einen gewissen Diebstahlschutz suggeriert, erfordert rein technisch, dass der Schlüssel und das Schloss sehr dicht beieinanderliegen müssen, was eine sehr genaue und kritische Überprüfung nicht nur des Konzepts selbst, sondern auch der Anwendung im praktischen Betrieb nötig macht. Ähnliches gilt für die Daten-Transportwege – denn nicht selten müssen die Schnittstellen der Systeme für den Cloud-Betrieb extra gehärtet werden.
All dies sind wichtige Aspekte auf dem Weg in einen sicheren Cloud-Betrieb. Unternehmen, die ihre Applikationen schon länger in potenziell unsichereren Umgebungen betreiben, oder die ohnehin hohe Sicherheitsstandards haben, sind hier im Vorteil, weil sie zum einen über mögliche Angriffsvektoren informiert sind, zum anderen wissen, wie ihnen wirkungsvoll begegnet werden kann.
Erhöhte Sicherheit durch Einsatz von Kubernetes
Dort, wo noch großes Potenzial in puncto IT-Security besteht, kann mit den Kubernetes-Bordmitteln viel Sicherheit geschaffen werden. Ein Beispiel sind Kubernetes Secrets, die inzwischen auch von den meisten Cloud-Anbietern angeboten werden. Diese sorgen dafür, dass sensible Daten nur innerhalb des entsprechenden Clusters verfügbar sind und nur von berechtigten Ressourcen konsumiert werden dürfen. Der Cluster speichert die Daten auf Wunsch zusätzlich verschlüsselt in der eigenen Datenbank. Zusammen mit der generellen base64-Codierung werden diese Daten also dreimal verändert, bis sie unkenntlich zur Ablage kommen.
Sollten Applikationen mit unsicherer Kommunikation auf Kubernetes portiert werden, bietet sich neben der generell empfohlenen Härtung der Transportwege zudem der Einsatz einer Container-Netzwerk-Schnittstelle wie Weave Net an. Dies ermöglicht den Kubernetes Workloads eine verschlüsselte Kommunikation über alle Knoten des Clusters hinweg.
Den genannten Beispielen ist eines gemein: Sie verlangen eine Konfiguration und Erweiterung des Kubernetes-Clusters. In aller Regel stellt dies den Kubernetes-Administrator vor keine größeren Herausforderungen – insbesondere dann nicht, wenn es sich um eine „normale“ Installation eines Kubernetes-Clusters handelt. Aber was genau ist eine „normale“ Installation von Kubernetes eigentlich?
Skalierbarkeit ist Key
Ein Kubernetes-Cluster besteht aus individuellen Komponenten, die alle installiert und konfiguriert werden möchten. Nicht selten besteht ein Cluster aus einer Vielzahl von Konfigurationsparametern. Hinzu kommen Client-Server-Zertifikate, die zur gegenseitigen Authentifizierung für jede einzelne Komponente ausgestellt werden müssen. All das ist täglich Brot für den Kubernetes-Administrator, doch der Aufwand wächst mit den Anforderungen. Für eine hochverfügbare Anwendung etwa müssen Komponenten wie der API-Server und die ETCD-Datenbank entsprechend häufig konfiguriert werden.
Wer tiefer in die Materie einsteigen will, dem sei an dieser Stelle Kelsey Hightowers Tutorium „Kubernetes The Hard Way” [High] ans Herz gelegt. Zwar wendet Hightower als Google-Mitarbeiter Kubernetes konsequenterweise in der Google Cloud an, dennoch gewährt seine Anleitung einen detaillierten Einblick in die Konfiguration von Kubernetes-Komponenten.
Gleichwohl ist Hightowers Weg zum Kubernetes-Cluster für die meisten Fälle zu langwierig und insgesamt zu statisch für ein Setup in der Cloud. Zwar lässt sich alles per „Infrastructure as Code“ umsetzen und man erreicht eine gewisse Portabilität. Jedoch erfüllt das Setup nicht die nötigen Standards in puncto Skalierbarkeit. Hier wünschen sich viele Kunden ein elastisches Cluster, das auf die schwankende Datenlast dynamisch mit mehr oder weniger Rechenleistung und Arbeitsspeicher in Form neuer Cluster-Konten reagieren kann, und zwar ohne dass es dazu einen menschlichen Anstoß braucht, sprich automatisch.
Aber egal, welches Kubernetes-Bootstraping man verwendet oder welchen Kubernetes-Service man einkauft, die Antwort von Kubernetes hierauf bleibt die gleiche: Der Cluster Autoscaler sorgt dafür, dass immer die richtige Anzahl von Knoten für die Bewältigung der Cluster-Aufgaben verfügbar ist. Einfach ausgedrückt überwacht der Autoscaler die aktuellen Workloads im Cluster; sobald ein Workload nicht mehr gestartet werden kann, weil kein Knoten mit freien Kapazitäten mehr vorhanden ist, wird automatisch ein neuer Knoten gestartet und in den Cluster integriert. Für die Skalierung nach unten werden die Knoten wiederum auf ihre Auslastung hin überwacht; sollten sie nicht voll ausgelastet sein, werden sie aus dem Cluster herausgelöst und gelöscht.
Doch in welchen Fällen benötigt der Cluster überhaupt mehr Rechenleistung? Um, zukunftsfähige und skalierbare Softwarelösungen zu bauen, müssen auch die Workloads selbst skalierbar sein. Deshalb messen wir bei Frontend-Applikationen stets die aktuelle Verbindungslast, um zu erkennen, ob wir gegebenenfalls eine weitere Instanz der Applikation benötigen. Die nötigen Metriken dafür werden von Kubernetes zur Verfügung gestellt und von einem Horizontal Pod Autoscaler ausgewertet. Dieser skaliert die Applikation auf Basis der betreffenden Metrik – et voilà: Die Applikation steht immer im passenden Umfang zur Verfügung.
Will man einen solchen Grad der Dynamik in einem Kubernetes-Cluster erreichen, ist man auf ein gut abgestimmtes Setup angewiesen. Und natürlich bieten sich die Kubernetes-Services hierfür förmlich an. Doch häufig kollidiert der Wunsch nach der einfachsten Lösung ebenfalls mit den eingangs erwähnten Sicherheitsvorgaben und Richtlinien.
Oft kann die vom Cloud-Betreiber angebotene Lösung deshalb entweder gar nicht oder nur teilweise genutzt werden, weil zentrale Kubernetes-Module nicht oder nur indirekt im Zugriff der Kunden liegen – was mit der Compliance oder den Datenschutzstandards deutscher Unternehmen oft nicht vereinbar ist.
Azure Kubernetes Service
Wie können wir dennoch einen gut eingepassten Kubernetes-Cluster betreiben? Wie können wir sicher sein, dass unsere sicherheitstechnischen Vorgaben eingehalten werden? Im Falle der Microsoft Azure Cloud lautet die derzeitige Antwort: Azure Kubernetes Service, kurz AKS. Aber was genau versteckt sich dahinter?
Um dafür ein Verständnis zu entwickeln, hilft es, sich die Vorteile und die hohe Glaubwürdigkeit von Open-Source-Lösungen bewusst zu machen. Deren Einfluss und Akzeptanz ist in den letzten Jahren deutlich angewachsen und wird sich weiter steigern. Ein Trend, dem sich auch Microsoft nicht länger verschließt. So legt Microsoft das Projekt AKS-Engine auf GitHub offen und stellt es inkl. der automatisierten Prozesse, die beim Bootstrapping eines AKS durchgeführt werden, zum freien Download zur Verfügung.
Im Unterschied zum AKS selbst werden also alle nötigen Kubernetes-Komponenten unserer Hoheit überlassen. Damit ergibt sich die Möglichkeit, die Daten unseres Masters und der ETCD-Datenbank zu überwachen und nötigenfalls weiter abzusichern. Auch können wir nach Wunsch das Basis-Ubuntu-AKS-Image verwenden, werden aber nicht dazu gezwungen.
Damit lassen sich die meisten Kundenvorgaben in Bezug auf Compliance und Sicherheit umsetzen. Zusätzlich können wir die Vorteile einer gut integrierten Lösung nutzen: So funktioniert etwa die dynamische Skalierung der Worker-Knoten genauso wie die Definition und Verwendung von Azure Disks/Files und Load Balancern.
Fazit
Die Antwort auf die eingangs gestellte Frage lautet also: Ja, Kubernetes für Azure ohne Azure Kubernetes Service (AKS) – das geht! Und natürlich gibt es neben der vorgestellten Lösung noch unzählige andere Möglichkeiten, Kubernetes innerhalb der Azure Cloud zu betreiben. Für uns jedoch bietet die AKS-Engine genau den richtigen Rahmen, um den Erfordernissen unseres Projekts gerecht zu werden.
Literatur und Links
[High]
K. Hightowers, Kubernetes The Hard Way,
https://github.com/kelseyhightower/kubernetes-the-hard-way
