Verprobung Open Telekom Cloud – Die Speerspitze der EU-Cloudanbieter?

Einleitung

Seit 2016 bietet die Telekom in den Rechenzentren der Tochter T-Systems Cloud-Produkte an, die den strengsten Datenschutzrichtlinien entsprechen und sich technisch auf dem Niveau der Hyperscaler bewegen sollen. Im Kern stützt man sich dabei auf die Open Source Software “Open Stack”. Allerdings ist es ein offenes Geheimnis, dass die Telekom sich Huawei als Technologiepartner ins Boot geholt hat und die OTC keine vollständige Eigenentwicklung ist, sondern im Großteil auf der Huawei Cloud basiert. Was dies für die Nutzbarkeit, den Feature Umfang und die Sicherheit bedeutet sowie ob dieser Umstand den Gesamteindruck trüben kann, wollen wir im Laufe dieses Artikels aufzeigen.

Unser Vorgehen bei der Verprobung

Im Rahmen unserer Verprobung hat sich unser Team daran gemacht eine für diesen Zweck aufgesetzte, standardisierte Beispielapplikation zu deployen und lauffähig zu machen. Hierbei konnten wir die Services der Open Telekom Cloud hands-on verproben und einiges an Erfahrung sammeln bezüglich ihrer Funktionalität und Usability, auf welche wir insbesondere im Kapitel der weichen Faktoren genauer eingehen wollen.

Unsere Beispielanwendung besteht aus vier Microservices und einem Browser-Frontend. Die Services nutzen sowohl MongoDB als auch Redis als Storage und kommunizieren über Kafka bzw. REST-Schnittstellen miteinander. Die einzelnen Komponenten werden als Container-Image paketiert und in innerhalb eines Kubernetes Cluster deployed. Mit diesem Setup bilden wir ein typisches Anwendungsszenario ab, wie es auch in unseren Kundenprojekten häufig zum Einsatz kommt. Das Ziel ist es dabei, möglichst viele der benötigten Infrastrukturkomponenten über die Managed Services der OTC abzudecken.

Ersteindruck der Open Telekom Cloud

Wie bei anderen Cloud Anbieter werden auch in der OTC alle erstellten Cloud Ressourcen einem „Projekt“ zugeordnet. Eine kleine Besonderheit ist die zusätzliche übergeordnete Ebene der Domains bzw. Tennants. So kann eine Domäne aus mehreren Projekten bestehen. Nutzern wird dann anschließend vom Besitzer der Domäne Zugriff auf die jeweiligen Projekte (oder auch die ganze Domäne) gestattet. Nachdem alle erforderlichen Rechte verteilt sind, kann man sich auf der „Console“, also der Management UI der OTC anmelden.

Ist man bereits mit der UI eines der Big-3 vertraut, so wird einem auch das Webinterface der OTC bekannt vorkommen. Es ist klar erkennbar, dass man sich bei der Gestaltung an der Konkurrenz aus den USA orientiert hat. Ebenso lösen die Benennungen der hauseigenen Services wie beispielsweise „Elastic Cloud Server (ECS)“, „Elastic Volume Service (EVS)“ oder „Virtual Private Cloud (VPC)“ ungewollt Erinnerungen an das letzte Projekt mit einem bekannten Hyperscaler aus. Allerdings ist diese Vertrautheit kein schlechter erster Eindruck, immerhin handelt es sich bei Konsistenz und Standardisierung um wichtige Aspekte des Usability Engineerings.

In der Fülle der angebotenen Dienste fällt unser erster Fokus auf die Basisprodukte einer Cloud: Virtuelle Maschinen, Storage und Networking. Hier gibt es wenig Überraschungen. VMs lassen sich in unterschiedlichen Dimensionierungen („Flavors“) starten und durch eine breite Palette von Betriebssystemen bestücken. Die OTC bietet insgesamt sechs verschiedene Verfügbarkeitszonen verteilt auf vier Rechenzentren, von denen zwei in Deutschland liegen und weitere zwei in den Niederlanden nahe Amsterdam. Entsprechend lässt sich auch eine gewisse Geo-Redundanz umsetzen.

Alle erzeugten VMs lassen sich mit dem VPC-Service in privaten isolierten Netzwerken verbinden. Für den Zugriff von außerhalb auf das private Netz gibt es verschiedene Möglichkeiten. Hier stellt die OTC sowohl einen VPN-Service zur Verfügung als auch ein Direct-Connect Feature, mit welchem sich das eigene Rechenzentrum auch physisch mit der Open Telekom Cloud verbinden lässt. Für die Verbindung mit dem Internet lässt sich ein Gateway an das private Netz anstecken und mit einer öffentlichen IP versehen. Per SNAT/DNAT Regeln oder Load Balancer wird der Traffic dann zwischen den Netzen geroutet.

Als Standardblockspeicher dient der “EVS”-Dienst der OTC. Ein dicker Pluspunkt ist die Möglichkeit der Festplattenverschlüsselung mit eigenem Key, sodass der Dienst auch für kritische Systeme im Financial Bereich eingesetzt werden kann. Für einfache Szenarien stellt die OTC einen Standard-Key bereit, der nicht durch den User generiert wird. Neben dem klassischen Blockspeicher gibt es noch ein NFS-basierten Storage mit dem Namen „SFS“ bzw. „SFS Turbo“ und ein S3-kompatibles Speichersystem. Den Abschluss bildet ein dediziertes Backup und Recovery System, mit dem sich Festplatten regelmäßig sichern lassen. Bei verschlüsselten Festplatten werden ebenfalls die Backups verschlüsselt.

In der Summe lässt sich an der Basis der OTC wenig aussetzen. Die genutzten Dienste funktionierten wie versprochen und überzeugten mit dem ein oder anderen netten Zusatzfeature wie zum Beispiel “Bring-Your-Own-Key”.

Managed Services

Nachdem die Basisprodukte einen grundsoliden Eindruck hinterließen, ging es weiter mit einem Deep Dive in einige ausgewählte Managed Services, die für den Betrieb unserer Beispielanwendung notwendig waren. Im Konkreten wurden folgende Dienste näher untersucht:

• Die Cloud Container Engine (CCE), mit dessen Hilfe wir ein Kubernetes Cluster erzeugt haben,
• der „Relational Database Service (RDS)“, mit dem eine PostgreSQL Datenbank erzeugt wurde,
• der „Distributed Message Service (DMS)“, ein Apache Kafka kompatibler Dienst,
• und der „Distributed Cache Service (DCS)“, ein Key-Value Store auf Basis von Redis.

Die CCE gibt es in zwei verschiedenen Versionen, die klassischen CCE-Cluster und ein augenscheinlich neues Produkt mit dem Namen „CCE Turbo“. Die genauen technischen Unterschiede sind uns allerdings im Laufe unserer Verprobung nicht klar geworden, zumal die Dokumentation an dieser Stelle wenig hilfreich ist. Diese wirbt allerdings stark für die Turbo Variante mit Marketing-Phrasen wie „Cloud Native 2.0“ und der Huawei „QingTian Architecture“, ohne tiefergehende Erklärung derselbigen. Maximale Verwirrung stiftet dann der Umstand, dass der eigentliche next-Gen Cluster Typ nur eine Kubernetes Version 1.19 anbietet, die zu dem Zeitpunkt unseres Tests bereits seit 2 Jahren “end of life” ist und keinen Support mehr erhält. Entsprechend fällt unsere Wahl dann auf den klassischen Cluster Typ, bei dem auch eine aktuelle Kubernetes Version verfügbar ist. Hier läuft dann auch alles reibungslos und der Cluster kann mit einzelnen Nodes oder automatisch skalierbaren Node-Pools erweitert werden. Etwas ernüchternd ist die Auswahl der verfügbaren Betriebssysteme für die Cluster Nodes. Hier standen zum Zeitpunkt unseres Tests nur zwei Varianten von „EulerOS“, einem auf RHEL basierenden OS von Huawei, und eine veraltete Version von CentOS zur Verfügung. Neuerdings soll hier aber auch das deutlich verbreitetere Ubuntu 22.04 zur Auswahl stehen, was wir allerdings nicht testen konnten. Die Komponenten des Kubernetes Clusters wie Deployments, ConfigMaps oder Secrets können über das OTC-Interface verwaltet werden. Ebenso gibt es ein rudimentäres Monitoring für die Cluster-Nodes und Workloads innerhalb des Clusters. Bei diesem Feature sorgte eine Übersichtsseite für kurze Verwunderung, da die Metriken mit chinesischen Zeichen beschriftet waren.

Als Datenbanken werden für die Beispielanwendung sowohl eine PostgreSQL-Datenbank als auch ein Redis Key-Value-Store benötigt. Beides wird in der OTC als Managed Service zu Verfügung gestellt und sind entsprechend einfach aufzusetzen. Neben PostgreSQL werden noch MySQL und MSSQL als Managed Datenbanken unterstützt. Alle Produkte lassen sich entweder als Single-Node Setups anlegen oder direkt als Production-Ready Konfigurationen mit Failover Nodes bzw. Load-Balancing und konfigurierbaren Backups. Im Gegensatz zum Managed Kubernetes fehlen bei den Managed Datenbanken allerdings Möglichkeiten der Verwaltung über das OTC-Interface und Datenbank-Schemata bzw. User müssen über andere Wege verwaltet werden.

Zu guter Letzt werfen wir einen Blick auf das Managed Kafka bzw. “Distributed Message Service (DMS)”. Die erste Auffälligkeit ist auch hier, dass die zur Verfügung stehende Version 2.7 deutlich hinterherhinkt in Sachen Aktualität: Kafka 3.0 wurde bereits im September 2021 veröffentlicht und ist über zwei Jahre später immer noch nicht in der OTC verfügbar. Der offizielle Support von Kafka 2.7 ist zum Zeitpunkt dieses Artikels bereits vor mehreren Monaten ausgelaufen. Auch die Roadmap der OTC gibt keine Hinweise auf ein nahendes Release einer neueren Version. Immerhin funktioniert die angelegten Kafka-Instanz problemlos, auch wenn das TLS-Setup einen faden Beigeschmack hinterlässt – mehr dazu im nächsten Abschnitt. Auch für das Messaging bietet die OTC einige Management-Funktionen über das Interface an, mit Hilfe dessen Topics und User erstellt werden können oder sogar in Nachrichten einzelner Topics geschaut werden kann.

Insgesamt hinterlassen die Managed Services der OTC einen gemischten Eindruck: Grundsätzlich funktionieren die Produkte wie angeboten und bieten mit wenigen Klicks produktionsfähige Setups. Zusätzlich bietet das Interface für die meisten Dienste rudimentäre Management- und Monitoring-Funktionen an, was zumindest für uns eine kleine Überraschung war.
Allerdings zieht sich durch alle Dienste das Problem der veralteten Versionen, was insbesondere dann kritisch wird, wenn es keine Patches mehr gibt seitens des Herstellers. Zusätzlich ist die Auswahl der Managed Services sehr überschaubar, auch wenn die Roadmap für 2024 spannende aber längst überfällige Funktionen wie Serverless Compute Angebote, ein API Gateway und einen CDN-Service verspricht – hier hinkt die Telekom dem Angebot der Hyperscaler deutlich hinterher.

Security und Compliance

Die Telekom schmückt ihre Open Telekom Cloud mit zahlreichen Zertifizierungen. Neben den branchenüblichen Standard-Zertifizierung und einer Konzern-internen Telekom-Zertifizierung, ist die OTC auch breit aufgestellt bezüglicher europäischer und deutscher Datenschutzanforderungen. Die Telekom ist sehr aktiv, wenn es um Initiativen wie z.B. Gaia-X oder das deutsche „Trusted Cloud“-Siegel geht. Weiterhin richtet sich die OTC auch nach den gesetzlichen Auflagen für Sozialdaten oder Berufsgeheimnisträger (z.B. Rechtsanwählte, Ärzte, Wirtschaftsprüfer oder Rechtsabteilungen in Unternehmen). Die Telekom verpflichtet sich hierfür vertraglich zur Einhaltung der gesetzlichen Vorgaben aus § 203 StGB und § 35 SGB I.

Mit dem Key Management Service (KMS) bietet die OTC einen Managed Service für die Verwaltung und Nutzung von kryptographischen Schüsseln an. Dieser kann mit generierten oder auch eigenen (Bring your own Key) Schlüsseln verwendet werden, um Encryption-at-Rest für viele Infrastruktur-Services zu ermöglichen. Die hinterlegten Schlüssel können aus dem KMS nicht ausgelesen werden, stattdessen müssen alle kryptographischen Operationen, also Ver-/Entschlüsselung oder Signierung, durch das KMS ausgeführt werden. Eine vollständige Lösung zur sicheren Verfahrung von Credentials und Secrets, die man ggf. von AWS, Azure und GCP gewohnt ist, ist das KMS daher nicht.

Negativ aufgefallen sind uns auch die TLS-Zertifikate der Managed Services. Zwar kann eine TLS-Verschlüsselung einfach und reibungslos aktiviert werden, allerdings gibt es keine Möglichkeit eigene Zertifikate und Trust-Chains zu verwenden. Daher waren wir gezwungen die bereitgestellten Zertifikate der OTC zu verwenden, auch wenn diese ohne Umwege von einer chinesischen oder Huawei CA ausgestellt wurden. Da es hier offenbar an Sorgfalt mangelte bei der Übernahme der Cloud-Komponenten von Huawei, fällt es uns schwer den Zertifkatsprozessen der OTC zu vertrauen. Für die Verarbeitung von sensiblen Daten sehen wir zumindest die chinesischen Zertifikate als kritisch an.

Dokumentation und Developer/User Experience

Zur Automatisierung des Infrastruktur-Aufbaus bietet die OTC einen eigenen Terraform-Provider. Grundsätzlich konnten wir hiermit alle benötigten Komponenten auch in Code überführen, nachdem wir diese zunächst testweise per UI angelegt hatten. Code-Beispiele in der UI, wie wir es bei OVHCloud gesehen hatten, oder in der Dokumentation wie es sie zum Beispiel bei Google gibt, sind bei der OTC leider nicht zu finden, wodurch man vollständig auf die Dokumentation und Trial & Error angewiesen ist. Besonders die Dokumentation sorgte an der ein oder anderen Stelle für graue Haare, weil sie entweder nicht ausführlich genug war oder die aufgezeigten Beispiele keine Hilfe boten. Generell bewegt sich die API der OTC sehr nahe an OpenStack und ergänzt diese um eigene Endpunkte, beispielsweise für das Managed Kubernetes.

Neben dem Terraform-Provider gibt es noch die offizielle OpenStack CLI, um aus der Kommandozeile mit der OTC zu interagieren. Durch eine Extension lässt sich die CLI um OTC-spezifische Komponenten ergänzen, die nicht aus dem OpenStack Kern kommen. Das Kommandozeilen-Tool ist stark anhand der API aufgebaut, wodurch die Developer Experience begrenzt ist. Nichtsdestotrotz ist die CLI mit ihrem Funktionsumfang ein Alleinstellungsmerkmal im Vergleich zu den anderen EU Cloud Providern, die wir uns bis dato angeschaut haben.

Die Dokumentation der OTC ist grundsätzlich nur auf Englisch verfügbar und wird im open-source Stil über GitHub verwaltet, sodass theoretisch auch User Änderungen beisteuern können. Im Zuge unserer Verprobung hat sich die Dokumentation als wenig hilfreich erwiesen, da die Beispiele häufig sehr generisch oder unvollständig sind. Für Verwunderung sorgen auch hier Screenshots aus dem Interface der Huawei Cloud, sodass nahe liegt, dass die Inhalte ohne große Sorgfalt aus Fernost übernommen wurden.

Fazit / Ausblick

Die Public Cloud der Telekom hinterlässt bei uns einen durchwachsenen Eindruck. Initial sind wir mit hohen Erwartungen gestartet, da sowohl das Marketing als auch die erste Erscheinung des Interfaces eine Cloud auf dem Niveau eines Hyperscalers versprechen. Der Ersteindruck verblasst allerdings schnell bei genauerem Hinsehen. Ursächlich hierfür sind die überholten Versionen der Managed Services, die ungepflegte Dokumentation und der sich durchziehende Einfluss des chinesischen Technologiepartners. Die chinesischen Schriftzeichen im Interface und die Screenshots der Huawei Cloud in der Dokumentation wären noch zu verschmerzen gewesen, aber das Nutzen von Huawei-signierten Root-Zertifikate lassen selbst bei Security-Laien die Alarmglocken schellen.

Was bleibt sind die diversen Zertifizierungen, welche definitiv ein nicht abzustreitendes Alleinstellungsmerkmal der Open Telekom Cloud sind. Hier stechen beispielsweise die Nutzungsmöglichkeit für Berufsgeheimnisträgern im Sinne des § 203 Strafgesetzbuch (StGB) und TISAX-Compliance hervor. Auch das Key Management mit der Möglichkeit eigene Schlüssel mitzubringen, gab es bei anderen EU-Clouds in dieser Form nicht.

Unterm Strich verschenkt die Telekom eine Menge Potential und Vertrauen durch fehlende Sorgfalt im Detail und ausbleibende Produktpflege. Der primäre Use-Case bleibt die Verarbeitung von sensiblen Daten in europäischen Rechenzentren bei einem Anbieter mit entsprechenden Zertifizierungen. Sobald dies keine Anforderung an das eigene Projekt ist, kann der Blick über den Atlantik oder auf eine andere EU-Cloud sicherlich nicht schaden.