Stefan Tombers
Lead Developer
Florian Zeidler
Technical Expert
Petr Andreev
Technical Expert
Einleitung
Obwohl zumeist nur Experten bekannt, existiert die IBM Cloud bereits seit 2014, bis 2017 noch unter dem Namen Bluemix. Nachdem mittlerweile aber ein verstärkter Marktangang forciert wird, insbesondere in für uns relevanten Zielindustrien, haben auch wir uns einer Verprobung gewidmet,
IBM erhebt den Anspruch selbst höchsten Sicherheitsanforderungen gerecht zu werden und bietet sich insbesondere Regierungsorganisationen, Finanzinstituten, sowie anderen hochregulierten Marktteilnehmern an.
Die über 190 angebotenen Services reichen von den Standards, wie Kubernetes Cluster, gemanagten Datenbanken über AI, hybriden Betriebsmöglichkeiten zu hochsicheren Lösungen für Regierungsbehörden und andere sensible Bereiche (siehe IBM Cloud bei Wikipedia). Dabei werden bei Sicherheit und Datenschutz höchste Zertifizierungen vorgewiesen, z.B. FIPS-140-2 Stufe 4, oder ISO 27018 (siehe “Security und compliance” im Bereich Hyper Protect Crypto Services in der IBM Cloud Dokumentation).
Wie gut es IBM gelungen ist, die oft widersprüchlichen Anforderungen aus Benutzbarkeit und höchsten Sicherheitsstandards umzusetzen untersuchen wir im nachfolgenden Artikel.
Vorgehen beim Testen
Im Zuge unserer ausgiebigen Testphase haben wir uns entschlossen, eine speziell für diese Zwecke konfigurierte Beispielanwendung basierend auf der okteto/movies Anwendung in die IBM Cloud zu deployen und dort zu betreiben.
Diese Unternehmung erlaubte es unserem interdisziplinären Team, nicht nur die Leistungsangebote der IBM Cloud effektiv und zielgerichtet auszuprobieren, sondern auch umfangreiche praktische Erfahrungen in der Nutzung dieser Services und dem Zusammenspiel mit cloud-native Tooling (Terraform) zu sammeln.
Unsere Beispielanwendung umfasst vier Microservices, mit unterschiedlichen Tech-Stacks, und ein Browser-Frontend.
Zur Anwendung kommt eine Architektur, die sowohl PostgreSQL als auch Redis für die Datenhaltung nutzt und über Kafka Event Streams und REST-APIs die Kommunikation zwischen den Services regelt.
Die Einzelkomponenten werden als Docker-Container-Images verpackt und in einen Kubernetes Cluster deployt – ein Setup, das in vielen unserer Kundenprojekte ähnlich umgesetzt wird und uns somit erlaubt eine Aussage zu treffen, ob die IBM Cloud auch für unsere Kunden eine Option darstellen kann.
Unser Ziel ist es, die erforderlichen Infrastrukturkomponenten möglichst durch Managed Services der IBM Cloud umzusetzen und so eine robuste und skalierbare Basis für moderne Cloud-Anwendungen zu schaffen.
Eine Zone entspricht einem Rechenzentrum.
Bereiche mit 3 Zonen werden “multizone regions” genannt.
Also solche stehen “au-syd” (Sydney), “jp-osa” (Osaka), “jp-tok” (Tokyo), “eu-de” (Frankfurt), “eu-es” (Madrid), “eu-gb” (London), “ca-tor” (Toronto), “us-south” (Dallas), “us-east” (Washington DC) und “br-sao” (São Paulo) bereit.
Wir haben unsere Tests in der Geografischen Region “europe”, mit Fokus auf den Bereich “eu-de” (Frankfurt), Zone “eu-de-3” durchgeführt mit Blick auf die Standardanforderung unserer (deutschen) Kunden, dass ihre Anwendungen innerhalb Deutschlands gehostet werden sollen.
Ersteindruck der IBM Cloud
Die Oberfläche wirkt auf den ersten Blick aufgeräumt und zu Beginn zugängig. Die Namen der Produkte sind von anderen Cloud Providern bekannt oder erschließen sich von selbst.
Jedoch sind die Kategorien der Produkte für Leute mit Erfahrungen in anderen Clouds nicht immer eingängig. Hier fehlt aus unserer Sicht eine verbesserte, einheitliche Unterteilung der Produkte.
Die IBM Cloud besteht aus einer Vielzahl von Produkten und Services, die teilweise miteinander kombiniert werden können.
Im Infrastructure as a Service (IaaS) Segment bietet IBM mit “Classic Infrastructure” und “VPC Infrastructure” Zugriff auf Computing, Storage und Network Komponenten – entweder als Bare Metal oder virtualisiert.
Als Plattform as a Service (PaaS) stehen die Container Orchestrierungssysteme OpenShift und Kubernetes, sowie zahlreiche Managed Services zur Datenhaltung (z.B. PostgreSQL, MongoDB, etc.) und Integration (z.B. Kafka) zur Verfügung.
Im Bereich Serverless bzw. Function as a Service (FaaS) steht die IBM Code Engine bereit.
Bei der Auswahl der richtigen Produkte für die Erweiterung der vorhandenen Infrastruktur bietet der Katalog eine gute Übersicht. Dort können sämtliche verfügbaren Produkte eingesehen und gefiltert werden.
Gemäß dem Infrastructure as Code (IaC) Gedanken, beschreiben wir sämtliche Infrastruktur als Terraform Ressourcen.
Dazu verwenden wir den IBM eigenen Terraform Provider.
Managed Services
Ein funktionierender Kubernetes Cluster kann einfach über die IBM Cloud Web Oberfläche zusammengeklickt oder mit nur einer Terraform Ressource beschrieben und provisioniert werden. Dabei wird neben der Anzahl an gewünschten Worker Nodes auch die Hardwarekonfiguration ausgewählt, von cx2.2x4 mit 2 virtuellen CPUs und 4 GB RAM bis mx2.8x64 mit 8 virtuellen CPUs und 64 GB RAM. Die Preisgestaltung orientiert sich an diesen Parametern.
Um aus dem Kubernetes Cluster auf andere Managed Services (z.B. eine Managed PostgreSQL) zugreifen zu können, müssen diese gegenüber dem Cluster explizit sichtbar gemacht werden.
IBM nennt das, ein Binding herstellen.
Dabei wird u.a. ein Kubernetes Secret angelegt, dass alle notwendigen Parameter (Username, Password, Self-Signed SSL Server Certificate) für den Zugriff enthält.
Im Bereich Datenhaltung haben wir uns die Managed Services PostgreSQL und Redis angeschaut.
Hier kann beim Provisionieren die gewünschte Anzahl an dedizierten CPU Kernen, sowie RAM und Disk Größe bestimmt werden.
Die Preisgestaltung hängt von diesen Parametern ab. Da wir für unsere Beispielanwendung nicht viel Performance brauchen konfigurieren wir keine dedizierten CPU Kerne, wodurch unsere Datenbanken auf Shared Computing Ressourcen angewiesen sind.
Beim Downsizing der Redis überrascht, dass keine Disk Größe kleiner als 250 GB ausgewählt werden kann. Damit bleiben die Kosten in der Region eu-de nicht unter $350 pro Monat.
Die Managed Services zur Datenhaltung kommen von Haus aus mit einer sicheren Konfiguration.
Sie können nur per SSL angesprochen werden, was auch nicht abgeschaltet werden kann. Das Server Certificate ist self-signed von IBM.
Gut gefällt das einheitliche Interface zum Anlegen und Einspielen von Backups für die verschiedenen Datenbanken, neben PostgreSQL und Redis auch für die Managed Services MySQL, MongoDB und ElasticSearch.
Backups werden automatisch einmal pro Tag erstellt und für 30 Tage aufgehoben.
Manuelle Backups lassen sich ad-hoc durchführen.
Für das Einspielen eines Backups (Recovery) erstellt IBM Cloud immer eine neue Instanz des jeweiligen Managed Services.
Als Managed Service aus dem Bereich Integration wird Kafka verwendet, oder wie es in der IBM Cloud heißt: IBM Event Streams.
Die Kafka Instance und Topics lassen sich einfach via IBM Cloud Web Oberfläche oder mit Terraform konfigurieren.
Wie bei den Datenbanken hat auch der Managed Kafka ein von IBM signiertes SSL-Zertifikat.
Clients sind gezwungen zur Kommunikation das SASL SSL Protokoll zu nutzen.
Im Bereich Observability werden während unseres Tests im Juli 2024 Änderungen am Produktportfolio vorgenommen.
IBM Cloud Logs soll das neue Logging-System werden und ersetzt ab Q2 2025 die veralteten Systeme Log Analysis und Activity Tracker.
Die Auswertung erfolgt über eine gut strukturierte Oberfläche, die anderen Log Aggregatoren wie Logstash und Splunk ebenbürtig ist. Komplexe Abfragen können mit Ausdrücken in Lucene Syntax formuliert werden.
IBM Cloud Logs benötigt je einen Cloud Object Storage Bucket zum Speichern von Logs und Metriken. Für die Zuweisung dieser Buckets muss mangels passender Terraform Ressource auf die IBM Cloud Web Oberfläche zurückgegriffen werden.
Die Dokumentation zu Cloud Logs ist noch unvollständig. Häufig landet man über Links auf Seiten, die sich auf das veraltete Log Analysis Tool beziehen.
Die Logs aus dem Kubernetes Cluster und für alle Managed Services, wie PostgreSQL, Redis und Kafka in Cloud Logs zu sammeln ist uns innerhalb der verfügbaren Zeit nicht gelungen. Die Erwartung ist, dass die IBM eigenen Services und reinen Standard Logs im Kubernetes ohne größere Herausforderungen zukünftig in Cloud Logs sichtbar sind.
Analog zu S3 in der AWS Cloud bietet IBM mit dem Cloud Object Storage einen äquivalenten Dienst an.
Dateien bis 10 TB können hier abgelegt werden und unter anderem statische Webseiten ausgeliefert werden.
In der Integration mit der IBM Code Engine kann auch auf die Veränderung von Objekten im Bucket reagiert werden.
Die Objekte im Bucket können mit in IBM Key Protect hinterlegten Schlüsseln verschlüsselt werden.
Die Buckets lassen sich unabhängig voneinander konfigurieren.
Dabei sind die Preise abhängig von der gewählten Redundanz (Resiliency) und Standort (Location).
Das IBM eigene Key Management System heißt IBM Key Protect.
IBM Key Protect speichert symmetrische Schlüssel und erlaubt es eigene Schlüssel zu importieren (“Bring your own key” (BYOK)). Wir haben die Integration von IBM Key Protect mit Cloud Object Storage Buckets und dem Kubernetes Cluster getestet und erfolgreich die Verschlüsselung der Startlaufwerke in den Worker Nodes eingerichtet.
Mit IBM Cloud Hyper Protect Crypto Services steht ein Key Management in einem dedizierten Hardware Security Module (HSM) bereit.
Terraform Integration
Der eigene IBM Cloud Terraform Provider ist neben der IBM Cloud Web Oberfläche und der IBM Cloud CLI ein first class citizen. Im Rahmen der Tests können fast alle Cloud Ressourcen mit Terraform gemäß dem Infrastructure as Code Gedanken beschrieben werden. Lediglich im Kontext des IBM Cloud Logs gibt es zum Testzeitpunkt fehlende Terraform Ressourcen. Das Binding von Managed Services an den Kubernetes Cluster funktioniert auch bei wiederholten Versuchen nicht direkt. Der Terraform Provider läuft hier ohne besondere Vorkehrungen in einen Timeout, da die Erstellung der Ressourcen nicht schnell genug ist. Die Lösung ist explizit vorher einen ibm_ressource_key in Terraform selbst anzulegen. Hier war ein Ticket zur besseren Konfigurierbarkeit der Bindings nützliche Quelle um den Fehler zu umgehen, da die Dokumentation zum Testzeitpunkt dazu keinen Hinweis enthält. Da die IBM Cloud CLI ebenfalls in Timeouts läuft, vermuten wir eher ein IBM internes Problem als einen Fehler in der Logik des Terraform-Providers.
GitOps
Das DevOps Tool IBM Schematics soll den Entwickler Alltag vereinfachen: Damit lassen sich die Git Repositories mit dem eigenen Terraform-Code als Workspace hinterlegen. IBM Schematics liest die Terraform Skripte aus und erlaubt die Ausführung direkt in der IBM Cloud Web Oberfläche, auf Wunsch auch vollautomatisch. Für die Integration mit GitHub oder GitLab Git Repositories benötigt das Tool einen entsprechenden Access Token. Praktischerweise unterstützt es IBM Schematics, den Terraform State zentral in der Cloud zu speichern. Dieser lässt sich auch für das lokale Ausführen von Terraform nutzen. Zum Zeitpunkt der Tests unterstützt IBM Schematics lediglich Terraform bis einschließlich Version 1.6, welche etwa sechs Monate älter ist als die aktuelle Version 1.9. Der gewählte Beispiel Use Case war jedoch problemlos umsetzbar.
Das Feature Cost Estimator ist einen genaueren Blick wert: IBM Schematics erstellt vor dem Ausführen des Terraform-Plans eine Schätzung der monatlichen Kosten und zeigt diese an. Die Schätzung für die Beispielanwendung ist, während unserer Tests, etwa um den Faktor 4 zu niedrig. Es gelingt beispielsweise nicht die Kosten für die Redis Instanz zu berücksichtigen, hier werden Kosten von $ 0 angenommen. Auch bei anderen Services wurden die kostenrelevanten konfigurierten Parameter (CPU Kerne, RAM und Disk Größe) falsch aus dem Terraform-Skript übernommen. Beim Service Postgres unterscheidet sich der Preis für den Disk Storage dabei signifikant zwischen Cost Estimator ($0.1238/GB) und tatsächlicher Abrechnung ($0.6283/GB).
Security und Compliance
Die IBM Cloud verspricht im Rechenzentrumsbetrieb höchsten Sicherheitsansprüchen gerecht zu werden. Die Seite zum IBM Cloud Compliance Program listet zahlreiche Programme und Zertifizierungen. Darunter die branchenüblichen Zertifikate der ISO Normen ISO 27001:2013, ISO/IEC 27017:2015 zu Sicherheitsfragen, aber auch ISO 22301:2019, welches Managementvorkehrungen für die Aufrechterhaltung des Betriebs nachweist.
Fast alle sensiblen Bereiche dürfen in die IBM Cloud
Über die üblichen Zertifikate hinaus berücksichtigt die IBM Cloud zahlreiche staatliche Programme und Zertifizierungen, die vor allem auf den Betrieb im Gesundheits-, Finanz- und Regierungswesen abzielen. Die Compliance mit dem US Health Insurance Portability and Accountability Act (HIPAA) erlaubt die Verarbeitung von Gesundheitsdaten in den USA. FedRAMP listet die IBM Cloud als tauglich für IT-Projekte der US-Regierungen. Sogar das US Department of Defense darf einen Teil der verfügbaren IBM Cloud Produkte verwenden, die dem Cloud Computing Security Requirements Guide (CC-SRG), der Defense Information Systems Agency (DISA) genügen.
Im Finanzbereich folgen viele Komponenten dem Payment Card Industry Data Security Standard (PCI DSS), der das Prozessieren von Bezahlkartendaten erlaubt und die Empfehlungen der European Banking Authority (EBA) werden ebenfalls befolgt, welche hier EBA publishes revised Guidelines on outsourcing arrangements angekündigt wurden.
Die Daten selber wegschließen, eigene Schlüssel für Plattenverschlüsselung
Das Anlegen des Kubernetes Clusters über Terraform erlaubt das Hinterlegen eigener Schlüssel, welche für die Festplattenverschlüsselung auf den Worker-Nodes genutzt werden können. Die Schlüssel müssen in IBM Key Protect hinterlegt werden. Mithilfe dieser Schlüssel werden dann die Startlaufwerke der Worker-Nodes verschlüsselt. Es besteht auch die Möglichkeit von IBM generierte Schlüssel zu verwenden.
Sich nicht in die eigenen Verbindungen schauen lassen
Nicht nur was auf der Platte liegt, lässt sich mit eigenem Schlüsselmaterial vor neugierigen Blicken verstecken. Auch SSL-Zertifikate können selbst bereitgestellt werden, wenn man sich nicht mit dem Standard Let’s Encrypt Zertifikat der Load Balancer begnügen möchte. Dabei wird auch das SSL-Zertifikat in den IBM Cloud Secrets Manager geladen, Load Balancern kann somit dieses Zertifikat mitgegeben werden. Der Load Balancer erlaubt damit das SSL-Offloading, das Terminieren der SSL-Verbindung. Der Traffic kann dann mit den weiteren SSL-Schlüsseln innerhalb des restlichen VPCs verschlüsselt werden.
Der Cluster erlaubt in den Ingress Pods und den Cluster zugeordneten Application Load Balancern (ALBs), welche die Ingress Pods bedienen, ebenfalls die Verwendung eigener TLS-Zertifikate. Damit kann bei Einsatz der IBM-eigenen “Internet Services”, welche die Konnektivität von Cloud Apps unter anderem mittels Web Application Firewall (WAF) absichern und die Domain an die VPC binden, komplett mit eigenen Schlüsseln bzw. Zertifikaten gearbeitet werden.
Developer Experience und Dokumentation
Die Weboberfläche der IBM Cloud ermöglicht es ein Dashboard selbst zu gestalten um den Einstieg auf die relevanten Informationen zu Beschränken. In Hinblick auf den täglichen Betrieb gefällt die Ressourcenliste besonders gut, welche einen Überblick über alle im eigenen Account provisionierten Services und Produkte liefert. Die Filtermöglichkeiten (z.B. nach Name, Tags, Ressource Group, etc.) versprechen auch bei komplexeren Workloads eine Übersichtlichkeit über die relevanten Ressourcen.
Die Anzahl an Quellen zur IBM Cloud, welche nicht von IBM selbst kommen ist jedoch sehr überschaubar. Es existiert auch eine IBM Cloud Community. Bei der Suche nach Antworten auf Fragen landen wir allerdings fast ausschließlich bei Inhalten von IBM.
Fazit
Insgesamt hinterlässt die IBM Cloud den Eindruck eines stimmigen Produkts. Die Weboberfläche ist aufgeräumt und einheitlich. Obwohl viele unterschiedliche Komponenten angeboten werden, ist IBM bemüht gleiche Konzepte einheitlich umzusetzen, sowohl technisch als auch in der UI und im Terraform Provider. Gelungene Beispiele sind das Binding von Managed Services an den Kubernetes Cluster und das einheitliche Backup Interface bei den unterschiedlichen Datenbanken.
Komponenten können über die IBM Cloud Weboberfläche und den eigenen Terraform-Provider provisioniert werden. Beim Verfolgen des Infrastructure as Code Gedanken werden die Ressourcen für die Beispielanwendung komplett über Terraform beschrieben. Hier sind uns nur beim neuen Product IBM Cloud Logs Ausnahmen aufgefallen, welche einen manuellen Eingriff erfordern.
Die IBM Cloud hat einen hohen Anspruch an Sicherheit. Unverschlüsselte Verbindungen zu Managed Services werden nicht erlaubt. Die Festplattenverschlüsselung für den Kubernetes lässt sich aktivieren. Das Key Management System IBM Key Protect kann mit eigenen Schlüsseln bestückt werden. Der Kubernetes Load Balancer kommt out-of-the-box mit einem Let’s Encrypt Zertifikat daher, erlaubt aber auch eigene SSL-Zertifikate mittels des IBM Cloud Secrets Managers einzusetzen.
Die hohen Sicherheitsvoraussetzungen in der Cloud führen bei unserer Beispiel-Anwendung dazu, dass mehrere Komponenten nachträglich für die SSL-Kommunikation mit den IBM Managed Services angepasst werden müssen. Ein einfaches Lift-and-Shift einer Legacy Anwendung ist so nicht möglich.
Die hohen Sicherheitsstandards und -zertifizierungen zeigen, dass IBM insbesondere Banken und andere regulierte Bereiche als Zielkunden sieht.
Zusammenfassend: Wird kein einfaches Lift-and-Shift von Legacy Anwendungen in die IBM Cloud gebraucht, lässt sich aus Entwicklersicht gut mit der IBM Cloud arbeiten.