NWS Kubernetes Playground Jetzt Verfügbar

NWS Kubernetes Playground Jetzt Verfügbar

Wir freuen uns, Dir heute unseren brandneuen NWS Kubernetes Playground präsentieren zu können! Die interaktive Plattform hilft Dir dabei, Neues über cloud-native Technologien zu lernen, Dein Wissen und Selbstvertrauen in der Arbeit mit Kubernetes auszubauen, und eine Reihe von NWS-Produkten auszuprobieren. Unser Kubernetes Playground bietet eine einmalige Lernumgebung, in der Du in einer vollständigen, kostenlosen Umgebung aufbauend auf NWS Kubernetes arbeitest. Jeder Playground wird durch Workshop-ähnliche Anweisungen begleitet, die Dich durch die inhaltlich eng gefassten Themen führen. So kannst Du Neues lernen, wann immer Du ein paar Minuten Zeit hast. Die meisten Abschnitte halten interaktive Aufgaben und Quizze für Dich bereit, um dein Wissen zu testen und zu vertiefen.

Startseite des NWS Playgrounds

Vertiefe deine cloud-native Skills mit kurz gehaltenen Labs

 

Ab Heute Verfügbar

Zum Launch bieten wir Dir auf unserer Plattform drei Playgrounds an, die sich mit den Grundlagen rund um Kubernetes befassen:

  1. Arbeiten mit Pods: Dieser Playground wird Dir alles beibringen, was du über Pods wissen musst, von der Erstellung bis hin zum Troubleshooting. Du erlangst so erste Erfahrungen im Umgang mit Pods und wie sie in Kubernetesumgebungen funktionieren.
  2. Arbeiten mit Deployments: Lerne, Deployments zum Management und zur Skalierung deiner Kubernetesworkloads zu nutzen. Dieser Playground deckt die Grundlagen im Umgang mit Deployments auf Kubernetes ab.
  3. Kubernetes Sandbox: Experimentiere in dieser Umgebung komplett frei mit Kubernetes. Dieser Playground stellt spezifische Features und Eigenheiten von NWS Managed Kubernetes vor (z.B. Storageclasses), und lässt Dich frei mit Kubernetes experimentieren.

Um loszulegen, besuche playground.nws.netways.de und tauche in die Welt von Kubernetes ein. Egal, ob du unsere umfangreichen Tutorials aus unserem Blog praktisch nachvollziehen oder dich in der Kubernetes Sandbox umschauen möchtest, unsere Playgrounds bieten Dir eine praktische und authentische Lernumgebung!

eine NWS Playground Session

Interaktive Sessions bieten Lerninhalte, Wissensabfragen und interaktive Elemente, um dein Fachwissen zu verbessern

 

Wie es Weitergeht

Sei gespannt auf die Zukunft! Wir entwickeln kontinuierlich neue Playgrounds und kündigen sie bei Veröffentlichung in unserem Newsletter an. Melde dich an, um up-to-date zu bleiben und die neuesten Änderungen an den NWS Playgrounds mitzubekommen. Mit dem NWS Kubernetes Playground kannst Du nach und nach ein solides Verständnis für Kubernetes entwickeln und Deine Fähigkeiten weiterentwickeln. Für mehr Details und Updates, schaue regelmäßig in unserem Blog und auf playground.nws.netways.de vorbei!

Managed Prometheus ist Live!

Managed Prometheus ist Live!

Letzten Donnerstag haben wir die neueste Erweiterung unserer Managed Services herausgebracht – Prometheus. Als führende Opensource Monitoringlösung bietet es eine ganze Reihe an spannenden Features.

Lass uns einen Blick darauf werfen, was Prometheus ist, wie es dir bei der Überwachung deiner IT-Infrastruktur helfen kann, und wie du es in MyNWS startest.

Was ist Prometheus

Prometheus ist die führende Opensource Monitoringlösung, die es dir erlaubt, Metriken von einer großen Bandbreite an IT-Systemen zu sammeln, zu aggregieren, zu speichern und zu querien.
Hierfür besitzt Prometheus seine eigene Querysprache, PromQL, mit der auch Visualisierung und Alarmierung umgesetzt werden.

Als grundlegende Säule des Cloud-Native Ökosystems integriert Prometheus wunderbar mit Anwendungen wie Kubernetes, Docker, und Microservices allgemein. Zusätzlich ermöglicht es die Überwachung von Services wie Datenbanken oder Messagequeues.

Mit unserem Managed Prometheus kannst du diese Vielseitigkeit innerhalb von Minuten für dich nutzen, ohne dich mit Einrichtung, Konfiguration und Betrieb deiner Umgebung aufhalten zu müssen.

Probiere es direkt aus – der erste Monat ist kostenlos!

Wie funktioniert Prometheus

Prometheus sammelt Daten in einem maschinenlesbaren Format von Webendpoints der zu überwachenden Anwendungen, üblicherweise unter dem Pfad /metrics.
Bietet ein Service keinen solchen Endpoint an, gibt es im Ökosystem vermutlich bereits einen sog. Metrics Exporter, der die Daten lokal auf andere Weise abfrägt und selbst bereitstellt.

Die gesammelten Metriken werden von Prometheus selbst gespeichert, im Laufe der Zeit aggregiert, und nach einiger Zeit gelöscht. Mit PromQL kannst du diese Daten entweder in Prometheus Weboberfläche oder in Grafana visuell aufbereiten.

Nutze Managed Prometheus in MyNWS

Um Managed Prometheus in MyNWS nutzen zu können, musst du lediglich das Produkt aus der Liste auswählen, einen Namen und Plan wählen, und auf Create klicken. Innerhalb von Minuten läuft deine Managed Prometheus App dann auch schon – doch was bietet sie an Features?

Managed Prometheus in MyNWS bietet vom Start weg eine breite Palette an Features, unter Anderem:

  • Webzugang zu Prometheus und Grafana – für schnelle Abfragen und ausführliche Visualisierungen
  • User Access Management basierend auf MyNWS ID – hol‘ dein Team ins Boot
  • Prebuilt Dashboards und Alarmierungen für Kubernetes – Visualisiere deine Daten ab Minute 1
  • Custom Domain Support – konfiguriere deine eigene Domain einfach in MyNWS
  • Remote Write möglich – aggregiere, sichere und visualisiere Daten von anderen Prometheus-Instanzen in MyNWS

Wenn das Alles für dich gut klingt, probiere Managed Prometheus in MyNWS auf jeden Fall einmal aus – der erste Monat ist kostenlos!

Hast du noch weitere Fragen oder brauchst Unterstützung auf den ersten Metern, melde dich gerne jederzeit bei unseren MyEngineers oder wirf einen Blick auf unsere Opensource Trainings, falls du gerade erst mit Prometheus loslegst.

CfgMgmtCamp 2024: Unser Rückblick

CfgMgmtCamp 2024: Unser Rückblick

Vergangenen Sonntag fuhr ein Teil unseres Teams bis nach Ghent in Belgien, um am ConfigManagementCamp 2024 teilzunehmen.
Hierbei handelt es sich um eine kostenlose Konferenz, direkt im Anschluss an die FOSDEM, was Jahr für Jahr für ein großes Publikum aus Fans von Open Source, guten Gesprächen und neuen Ideen sorgt. Auch dieses Jahr war das nicht anders, und so wollen wir in diesem Artikel noch einmal auf das CfgMgmtCamp 2024 zurückblicken.

Die ollen Zuverlässigen

Configmanagement als Aufgabenbereich ist bereits seit Längerem eine Notwendigkeit im alltäglichen Betrieb von IT-Infrastruktur und Software. So ist es nur natürlich, dass es inzwischen eine Riege etablierter, „oller“ Lösungen gibt, z.B. Puppet, Terraform oder Ansible.
Es war schön zu sehen, dass die Projekte und ihre jeweiligen Ökosysteme weiterhin voller Leben sind: Egal ob event-driven Ansible oder neue ‚Hacks‘ im Umgang mit Puppet, es gab auf jeden Fall noch Neues zu lernen!

Spongebob Squarepants holding the 'old reliable' box

Ansible, Terraform und Konsorten sind weiterhin zuverlässige Wegbegleiter im Configmanagement

Terraform und sein brandneuer Fork OpenTofu, der im Januar seinen ersten stabilen Release feiern durfte, waren ebenfalls Thema einiger Talks.
Die Tatsache, dass OpenTofu innerhalb von fünf Monaten von Fork zu Stable Release gelangen konnte, zeigt gut, wie wichtig der Community das Projekt ist.
Es wird spannend zu sehen sein, wie sich die beiden Projekte weiter (auseinander) entwickeln.

Noch erwähnenswert ist, dass sowohl Puppet Labs als auch Ansible als Sponsoren am CfgMgmtCamp 2024 auftraten, sodass man sich direkt ‚an der Quelle‘ mit Maintainern und der Community austauschen konnte.

Neues Jahr, Neue Tools

Natürlich waren wir nicht nur vor Ort, um unser Wissen rund um existierende Tools zu vertiefen, wir wollten auch Neues kennenlernen!
Hierzu gab es so einige Möglichkeiten:

Pkl ist eine Konfigurationssprache, die intern bei Apple genutzt wird. Apple hat sich 3 Tage vor dem CfgMgmtCamp dazu entschlossen, diese zu opensourcen. Einen ersten Eindruck konnten wir beim weltweit ersten Talk zu Pkl erhalten:
Die Konfigurationssprache erlaubt es einem, typisierte und durchweg validierte Konfigurationen zu erstellen, die dann in Formate wie YAML oder JSON exportiert werden können. Genaueres findet man auf der Projektwebsite oder im GitHub-Repository des Projekts

Ein weiteres interessantes Projekt, das am CfgMgmtCamp 2024 vorgestellt wurde, ist winglang. Die zugrundeliegende Idee, eine Programmiersprache für Infrastruktur und Code zu haben, fand viel Anklang.
Winglang fokussiert sich dabei auf die Abstraktion der verschiedenen Bausteine „in er Cloud“, um das Definieren von Workloads und Infrastruktur zu erleichtern.
Uns gefiel vor allem der lokale Simulator, der die definierten Ressourcen und das Verhalten der Workloads in Echtzeit wiederspiegelt.

Die dritte Neuheit, die wir nicht unerwähnt lassen wollen, ist System Initiative, ein ‚collaborative power tool designed to remove the papercuts from DevOps work‘. Du kannst es Dir vorstellen wie DrawIO für Infrastructure, mit Multiplayer-Support: Es ist eine GUI mit einer Vielzahl an Cloud-Komponenten, mit denen Du deine Infrastruktur in den Wolken bauen kannst.
System Initiative gleicht im Hintergrund konstant die Korrektheit und den Zustand Deines Projekts mit der Cloud Deines Vertrauens ab.

Unsere Erkenntnisse vom CfgMgmtCamp 2024

Rückblickend konnten wir zwei grundsätzliche Erkenntnisse mit nach Nürnberg nehmen:

Niemand mag YAML, sogar im ‚YAMLCamp‘ – Ansätze wie CUElang, Pkl und winglang deuten mehr als offensichtlich darauf hin.
Ob Sprachen mit strikteren Regeln hinsichtlich Korrektheit der richtige Weg sind, um am Ende dann doch YAML zu generieren, wird sich noch zeigen müssen.

Ansible, Puppet und Terraform sind nachwievor relevant. Wir konnten auch dieses Jahr wieder Neuerungen, Weiterentwicklungen und lebhafte Diskussionen rund um die Tools und ihre jeweiligen Ökosysteme beobachten. Außerdem hat die Open Source Community im vergangenen Jahr eindrucksvoll gezeigt, dass sie die Dinge auch selbst in die Hand nehmen kann, falls nötig (Hallo, OpenTofu!).

Für uns besonders interessant waren einige der Talks rund um Terraform und Ansible, da wir diese rund um OpenStack ebenfalls nutzen: Sei es im Zusammenspiel von OpenStack mit Terraform oder dem Erzeugen dynamischer Inventare unserer Infrastruktur in der Cloud für Ansible.

Und solltest Du Dich noch nicht bereit fühle, direkt ins tiefe Wasser des Configmanagements zu springen, sind ja auch noch unsere MyEngineers bereit, Dir jederzeit zu helfen.

Rejekts und KubeCon 2024 Review

Rejekts und KubeCon 2024 Review

Letzte Woche war unser Team auf der KubeCon2024, um sich über die neuesten Entwicklungen in der Cloud-Native Landschaft zu informieren. Wieder daheim angekommen wollen wir unsere Einblicke natürlich mit dir teilen! Schnall dich an, bringe deinen Bürostuhl in eine aufrechte Position, und los geht es mit der Rejekts EU, bevor wir zum eigentlichen KubeCon 2024 Review kommen.

Rejekts – Die Vor-Konferenz-Konferenz

Ich hatte mich bereits ein paar Tage vor dem Rest des Teams auf den Weg nach Paris gemacht, um an den Cloud-Native Rejekts teilzunehmen. Über die letzten Jahre hat die Konferenz vielen tollen, aber dennoch abgelehnten Talks der KubeCon eine zweite Heimat gegeben. Das ist inzwischen immens wertvoll – die Akzeptanzrate für Talks auf der KubeCon lag dieses Jahr bei unter 10%. Mit genug Platz für ~300 Teilnehmer und 45 Talks auf 2 Tracks stimmte die Konferenz auch dieses Jahr auf eine fantastische KubeCon-Woche ein. Die Beiträge reichten dabei von gesponsorten, kurzgehaltenen Keynotes über Talks in Normallänge bis zu witzigen, lehrreichen Lightningtalks am Abend des zweiten Tages.

the Rejekts EU 2024 main stage at ESpot in Paris

Cloud-Native Rejekts fand im ESpot statt, einem modernen eSports-Center in Paris.

Die meisten Teilnehmer waren sich darin einig, dass die weniger überlaufene Veranstaltung kombiniert mit ihren hochwertigen Beiträgen – quasi eine Mini-KubeCon – inzwischen ein ‚Must See‘ im Cloud-Native Eventkalender ist.

Nicht zuletzt aufgrund der verschiedensten Projekte und Unternehmen aus allen Cloud-Native Anwendungsgebieten, die durch Anwesende repräsentiert waren. Dadurch konnte man jederzeit auch zwischen den Talks anregende Diskussionen über neue Technologien, Open Source und Cloud-Native Entwicklung, und Marketingstrategien führen.

Meine persönlichen „Lieblings-Rejekts“

Nach Sichtung des Event Schedules beschloss ich für mich, die Themen Cilium, Kubernetes‘ noch recht junge Gateway API, und GitOps zu priosieren – und wurde nicht enttäuscht. Rejekts hatte ein paar wirklich gute Talks für mich in petto:

In Demystifying CNI – Writing a CNI from scratch nahm Filip Nikolic von Isovalent, den Begründer von Cilium, die Anwesenden mit auf eine Reise durch die Erstellung eines einfachen CNIs – in Bash.
Vom Empfangen von JSON  von der Container Runtime über die Erstellung von veth Paaren zur Bereitstellung von IP-Adressen für Pods war das Ganze ein ausführlicher Einblick in ein ‚Real-World‘ Szenario.

Nick Young, einer der Maintainer der Kubernetes Gateway API, erklärte uns, wie man CRDs für Kubernetes Controller nicht implementieren sollte.
In seinem großartigen Talk Don’t do what Charlie Don’t Does – Avoiding Common CRD Design Errors folgten wir Charliie Don’t durch den Prozess der Erstellung einer zugegebenermaßen gruseligen CRD Spezifikation.

Der dritte Beitrag den ich hervorheben möchte war From Fragile to Resilient: ValidatingAdmissionPolicies Strengthen Kubernetes von Marcus Noble, der eine detaillierte Einführung in diesen neuen Typ von Policy gab und zusätzlich einen Ausblick auf MutatingAdmissionPolicies gewährte, die momentan Teil des KEP 3962 sind.

Nach einigen kurzweiligen Lightning Talks zum Ende von Tag 2 war ich bereit, zum Rest des Teams zu stoßen und mich auf die Hauptveranstaltung vorzubereiten – also schnell weiter zum KubeCon 2024 Review!

KubeCon 2024 – AI, Cilium, and Platforms

KubeCon Paris war riesig – die größte KubeCon in Europa bis heute. Die Veranstalter hatten dies bereits in ihrer Schluss-Keynote auf der KubeCon 2023 in Amsterdam verkündet, dennoch: 12.000 Teilnehmer versammelt auf einem Haufen zu sehen ist noch einmal etwas anderes.

Justin, Sebastian, and Achim waiting for KubeCon to start

Justin, Sebastian und Achim warten auf den Start der KubeCon

Sie Alle warteten auf die Keynotes an Tag 1, die oft den Ton für die gesamte Konferenz angeben. DIeses Jahr war das übergreifende Thema eindeutig identifizierbar: AI. Jede Keynote hatte zumindest eine Erwähnung von GenAI, LLMs und Co. parat, und die meisten betonten: Wir leben im AI-Zeitalter.

Interessanterweise verließen viele Teilnehmer die Keynotes, während diese noch liefen – vielleicht sind sie mittlerweile einfach übersättigt durch den konstanten Hype rund um AI, den wir seit über einem Jahr erleben.
Vielleicht wollten sie auch nur schneller in die Ausstellungshalle der Sponsoren – viele hatten interessante Lösungen oder zumindest coolen Swag zu bieten!

Was das Team getrieben hat

Vielleicht wollten sie sich aber auch nur einen Kaffee holen ohne die ersten Talks des Tages zu verpassen – es gab eine riesige Auswahl. Deswegen habe ich Justin, Sebastian und Achim gefragt, was denn ihre Highlights waren, anstatt euch nur meinen persönlichen KubeCon 2024 Review zu geben:

Justin (Systems Engineer):

„Mir hat die Paneldiskussion rund um Revolutionizing the Control Plane Management: Introducing Kubernetes Hosted Control Planes am besten gefallen.
Wir suchen immer nach Möglichkeiten, unsere Managed Kubernetes Plattform zu verbessern, und das Control Plane aus Nutzersicht zu verstecken ist eine elegante Lösung. Entsprechend interessant war der Beitrag für mich.
Insgesamt war meine erste KubeCon so, wie ich sie mir vorgestellt hatte: Alle Teilnehmer hatten spürbar Lust auf Kubernetes und moderne Technologien.“

Sebastian (CEO):

„Mein Liebingsbeitrag war eBPF’s Abilities and Limitations: The Truth. Liz Rice und John Fastabend sind fantastische Redner die ein komplexes und sehr technisches Thema mit großartigen Beispielen präsentiert haben.
Generell interessieren mich Basistechnologien mehr als das nächste hippe Tool, das mir den Alltag erleichtert – wo bliebe denn da noch der Spaß? Deswegen finde ich eBPF auch so interessant.
Insgesamt war die KubeCon dieses Jahr deutlich besser organisiert als noch 2022 in Valencia, direkt nach der Pandemie. Trotzdem, das Klima und den Strand dort kann man nicht schlagen!“

Daniel (Platform Advocate):

„Teil meines Jobs ist es unter Anderem mir anzuschauen, wie unsere Nutzer Kubernetes einsetzen und darauf aufbauen. Logischerweise war ich also besonders interessiert an der großen Bandbreite an Talks rund um Platform Engineering. Am besten gefallen hat mir in diesem Bereich der Report zu State of Platform Maturity in the Norwegian Public Sector von Hans Kristian Flaatten.
Während meines Studiums habe ich die digitalisierten Plattformen der norwegischen Behörden als zeitweiser Immigrant selbst erlebt, und die Einsatzfelder scheinen seitdem noch deutlich gewachsen zu sein. Als Deutscher ist es immer etwas unvorstellbar, cloud-native Technologien in diesem Umfang in Behörden und öffentlichen Einrichtungen zu sehen.
Ansonsten teile ich Sebastians Ansicht: Valencia (meine erste KubeCon) ist vom Setting her schwer zu schlagen, aber auch in Paris waren viele Dinge super: die Stadt, der Veranstaltungsort, und der Zustrom an Teilnehmern zum Austauschen und Diskutieren.

Achim (Senior Manager Cloud):

„Mir hat der Beitrag From CNI Zero to CNI Hero: A Kubernetes Networking Tutorial Using CNI sehr gut gefallen. Die Vortragenden Doug Smith und Tomofumi Hayashi haben so ungefähr alles erkärt, was man rund um CNIs wissen sollte.
Angefangen beim Erstellen und Konfigurieren eines CNI-Plugins über die Funktionsweise innerhalb von Kubernetes wurden viele wichtige Aspekte des CNI-Projekts abgedeckt.
Was die KubeCon im Allgemeinen angeht, geht es mir wie Sebastian – insgesamt war die Pariser Edition gut organisiert, davon einmal abgesehen gab für mich keine allzu großen Änderungen.
Viele der Sponsoren und präsentierten Themen gab es so oder so ähnlich bereits in den vergangenen Jahren.“

KubeCon 2024 Review – ein Fazit

Blicken wir zurück, hatten wir als Team eine super Woche. Alte und neue Freunde (wieder) zu treffen, an spannenden Diskussionen teilzuhaben und Neues zu lernen sind einfach jedes Jahr aufs Neue gute Gründe, auf die KubeCon zu kommen. Jetzt haben wir also ein Jahr Zeit, das Gelernte zu verinnerlichen und anzuwenden, bevor wir einmal mehr zur KubeCon zurückkehren: KubeCon EU 2025 wird vom 01.-04. April in London stattfinden.

The next KubeCons will be in London/Atlanta (2025) and Amsterdam/Los Angeles (2026)

Die kommenden KubeCons werden in London/Atlanta (2025) und Amsterdam/Los Angeles (2026) stattfinden.

Wenn auch du mit cloud-native Technologien, insbesondere Kubernetes, arbeitest und liebend gerne einmal die KubeCon besuchen würdest, wirf doch einmal einen Blick auf unsere offenen Stellen – vielleicht bist du bald Teil unseres KubeCon 2025 Reviews? Und solltest du eine Einführung in das Thema Kubernetes und Cloud-Native allgemein brauchen, kann ich dir nur unsere Tutorials ans Herz legen – wir versprechen dir, sie sind gut!

LUKS verschlüsselter Speicher auf OpenStack

LUKS verschlüsselter Speicher auf OpenStack

Die gewissenhafte Absicherung deiner IT-Landschaft hat in den vergangenen Jahren mehr und mehr an Bedeutung gewonnen. Mit einem stetigen Anstieg an (Nutzer-)daten, die verwaltet, verarbeitet, und gespeichert werden müssen, sollte die Verschlüsselung dieser Daten auf deiner Agenda für eine ganzheitlich abgesicherte IT-Infrastruktur stehen.
Deswegen schauen wir uns in diesem Tutorial an, wie LUKS verschlüsselter Speicher auf OpenStack bei der Absicherung deiner Volumes im Ruhezustand helfen kann. Wir schauen uns zwei Herangehensweisen an, verschlüsselte Volumes in OpenStack zu definieren und zu nutzen: via Weboberfläche und via OpenStack CLI. Starten werden wir mit der Weboberfläche.

Voraussetzungen

Als Nutzer von OpenStack wurden alle notwendigen Voraussetzungen, um LUKS verschlüsselten Speicher auf OpenStack nutzen, normalerweise bereits von deinen Administratoren für dich konfiguriert. Solltest du OpenStack selbst verwalten und auf der Suche nach Konfigurationsanleitungen sein, schau doch einmal in die offizielle Dokumentation.

Um dieses Tutorial auf NWS OpenStack nachzustellen, benötigst du eine NWS ID. Du brauchst außerdem ein OpenStack Projekt, in dem du Volumes und Server erstellen kannst.
Möchtest du das Tutorial in deinem Terminal nachstellen, musst du zusätzlich noch die OpenStackRC-Datei für dein Projekt herunterladen.
Solltest du eine Auffrischung brauchen, wie diese Dinge ablaufen, wirf doch einen schnellen Blick auf unser Tutorial Projekt starten und den ersten Server anlegen.

Konfiguration von LUKS verschlüsseltem Speicher im Dashboard

Zuerst schauen wir uns an, wie LUKS verschlüsselter Speicher auf OpenStack über Horizon, OpenStacks Weboberfläche, bereitgestellt werden kann. Wenn du ein NWS-Kunde bist, kannst du Horizon entweder über https://cloud.netways.de erreichen und dich mit deiner NWS ID einloggen, oder du klickst in deiner Projektübersicht auf MyNWS auf den „Got to App“ Button oben rechts.

Screenshot of the MyNWS VPC project overview

Navigiere vom MyNWS Dashboard zu OpenStack Horizon

Erstellen eines neuen LUKS verschlüsselten Volumes

Bist du im Horizon Dashboard angekommen, navigiere über Volumes > Volumes zur Volumeübersicht deines Projekts und klicke auf Create Volume oben rechts. Es öffnet sich ein Konfigurationsdialog, in dem du die gewünschten Einstellungen für das neue Volume angeben kannst:

  • Volume Name – wähle einen aussagekräftigen Namen für dein Volume, bspw. encryption-tutorial-volume
  • Description – füge Informationen zu deinem Volume hinzu, falls erwünscht
  • Volume Source – wähle zwischen einem leeren Volume und dem Import eines existierenden Images
  • Type – die wichtigste Einstellung, die u.A. bestimmt, ob das Volume verschlüsselt wird oder nicht – mehr dazu später
  • Size – die gewünschte Größe des Volumes
  • Availability Zone – wo OpenStack das Volume speichern soll; in NWS OpenStack existiert nur eine Availability Zone (nova)
  • Group – füge das Volume zu existierenden Volumegruppen hinzu, falls gewünscht
screenshot of the New Volume dialogue on OpenStack Horizon

Beispielhafte Konfiguration eines LUKS verschlüsselten Volumes in NWS OpenStack

In obigem Screenshot Screenshot ist das Volume für den Typ LUKS konfiguriert, was der Volumetyp für LUKS verschlüsselten Speicher auf NWS OpenStack ist. Ich habe außerdem sichergestellt, dass ein neues, leeres Volume erstellt wird, und die Größe auf 4GB gesetzt.
Stellst du das Tutorial auf einer anderen OpenStackumgebung als NWS OpenStack nach, kann es sein, dass der Volumetyp anders benannt ist.

Auf NWS OpenStack sind Volumes vom Typ LUKS immer 256bit aes-xts-plain64 verschlüsselt.

Bist du zufrieden mit den Einstellungen, kannst du auf Create Volume klicken und ein paar Augenblicke warten. OpenStack erstellt in der Zwischenzeit ein neues, LUKS verschlüsseltes Volume für dich. Im nächsten Schritt können wir das Volume in einen Server einbinden.

Einbinden von LUKS verschlüsselten Volumes

Ein Volume alleine bringt dich nicht weiter, egal ob verschlüsselt oder nicht – du brauchst einen Client, der es nutzt. Im Rahmen dieses Tutorials werden wir hierfür einen neuen Server in OpenStack erstellen. Das geht entweder über das Dashboard in MyNWS oder durch einen Klick auf Launch Instance in Horizon unter Compute > Instances.
Sobald der Server läuft, können wir das verschlüsselte Volume in Horizon einbinden: Klappe das Dropdownmenü in der Action Spalte der Serverübersicht aus, und wähle Attach Volume von den verfügbaren Aktionen.Screenshot of the server listing in OpenStack, with the Action menu expanded

Ein weiterer Popupdialog öffnet sich, und bietet verfügbare Volumes zum Einbinden an. Wähle das im vorherigen Schritt erstellte LUKS verschlüsselte Volume und bestätige mit einem Klick auf Attach Volume:Screenshot of the Attach Volume dialogue in OpenStack Horizon

Das war’s auch schon – das verschlüsselte Volume ist nun auf dem Server eingebunden. Wenn du dich an deinem Server einloggst (bspw. via SSH), solltest du ein neues Storage Device sehen können (vmtl. /dev/sdb). Du kannst das neue Volume wie jedes andere verwenden, OpenStack hat es zu diesem Zeitpunkt bereits für dich entschlüsselt.
An dieser Stelle noch einmal der Hinweis: LUKS verschlüsselte Volumes sichern deine Daten im Ruhezustand, allerdings nicht in Bewegung – das gilt es bei der Evaluierung deiner IT-Sicherheit zu beachten!

Konfiguration von LUKS verschlüsseltem Speicher im Terminal

Solltest du das Terminal und OpenStacks CLI der Weboberfläche vorziehen, gibt es auch dort natürlich die Möglichkeit, LUKS verschlüsselten Speicher für OpenStack zu konfigurieren.
Downloade deine OpenStackRC.sh Datei, source sie, und wähle das OpenStack-Projekt, auf dem du arbeiten möchtest:

source ~/Downloads/nws-id-openstack-rc.sh

Testing authentication and fetching project list ...

Please select one of your OpenStack projects.

1) aaaaa-openstack-bbbbb
2) ccccc-openstack-ddddd
3) eeeee-openstack-fffff
4) ggggg-openstack-hhhhh
5) iiiii-openstack-jjjjj
6) kkkkk-openstack-lllll
7) mmmmm-openstack-nnnnn
8) ooooo-openstack-ppppp
Enter a number: 1
Selected project: aaaaa-openstack-bbbbb

Hast du eines deiner Projekte gewählt, kannst du als nächstes ein verschlüsseltes Volume erstellen.

Erstellen eines neuen LUKS verschlüsselten Volumes

Zuerst musst du den Storagetypen deines OpenStackprojekts identifizieren, der LUKS verschlüsselten Speicher unterstützt. Eine Liste aller verfügbaren Storagetypen kannst du dir mit folgendem Befehl ausgeben lassen:

openstack volume type list
+--------------------------------------+--------------------------+-----------+
| ID                                   | Name                     | Is Public |
+--------------------------------------+--------------------------+-----------+
| 2f487bd6-628d-46ba-83c5-21c6dbb4c67d | Ceph-Encrypted           | True      |
| e0704085-2e47-4e3d-b637-ae04e78f5000 | Ceph-Encrypted-High-IOPS | True      |
| 21b793e6-8adf-4c92-9bf9-14f5a7b6161a | LUKS                     | True      |
| 664b6e93-0677-4e11-8cf1-4938237b6ce2 | __DEFAULT__              | True      |
| 0a65e62f-3aad-4c6d-b175-96dedaa7ba1f | Ceph-High-IOPS           | True      |
| c4a685b0-64c4-4565-9b4c-9800056d659d | Ceph                     | True      |
+--------------------------------------+--------------------------+-----------+

In NWS OpenStack heißt der für LUKS Verschlüsselung zuständige Storagetyp bequemerweise LUKS.
Als nächstes kannst du nun ein neues Volume erstellen und den gewünschten Storagetypen referenzieren:

openstack volume create --type LUKS --size 4 encryption-tutorial-volume
+---------------------+------------------------------------------------------------------+
| Field               | Value                                                            |
+---------------------+------------------------------------------------------------------+
| attachments         | []                                                               |
| availability_zone   | nova                                                             |
| bootable            | false                                                            |
| consistencygroup_id | None                                                             |
| created_at          | 2024-03-04T12:41:29.000000                                       |
| description         | None                                                             |
| encrypted           | True                                                             |
| id                  | 9b20a1d8-bfb6-4e4f-bb4b-dbda62e4afc7                             |
| multiattach         | False                                                            |
| name                | encryption-tutorial-volume                                       |
| properties          |                                                                  |
| replication_status  | None                                                             |
| size                | 4                                                                |
| snapshot_id         | None                                                             |
| source_volid        | None                                                             |
| status              | creating                                                         |
| type                | LUKS                                                             |
| updated_at          | None                                                             |
| user_id             | acfef1ea27ec3ac25fa5009238cdeb2cc5ae2c943da7ecb279c43a5a91b8a4bf |
+---------------------+------------------------------------------------------------------+

Im obigen Beispiel habe ich ein Volume namens encryption-tutorial-volume mit einer Größe von 4GB erstellt.

Auf NWS OpenStack sind Volumes vom Typ LUKS immer 256bit aes-xts-plain64 verschlüsselt.

Als nächstes musst du das erstellte Volume in einem Server einbinden.

Einbinden von LUKS Encrypted Volumes

Um das Volume einbinden zu können, brauchst du einen Server, an den du es anschließen kannst. Erstelle also mit folgendem Befehl einen neuen Server in deinem OpenStack-Projekt, oder nutze das MyNWS oder Horizon Dashboard dafür:

openstack server create --flavor s1.small --image "Debian 10" --network public-network test-server

Dieser Befehl funktioniert standardmäßig in jedem NWS OpenStack-Projekt – wenn du dieses Tutorial auf einer anderen OpenStack-Umgebung nachstellst, kann es sein, dass du die Referenzen auf Flavor, Image und Network anpassen musst.

Ist der Server erst einmal gestartet, kannst du das Volume wie folgt an den Server anschließen:

openstack server add volume --device /dev/sdb test-server encryption-tutorial-volume
+-----------------------+--------------------------------------+
| Field                 | Value                                |
+-----------------------+--------------------------------------+
| ID                    | 9b20a1d8-bfb6-4e4f-bb4b-dbda62e4afc7 |
| Server ID             | 7952e17d-0781-41c3-a1e9-b758574ac336 |
| Volume ID             | 9b20a1d8-bfb6-4e4f-bb4b-dbda62e4afc7 |
| Device                | /dev/sdb                             |
| Tag                   | None                                 |
| Delete On Termination | False                                |
+-----------------------+--------------------------------------+

Loggst du dich nun in deinen Server ein (bspw. via SSH), siehst du das neue Storage Device als /dev/sdb. Du kannst nun direkt damit arbeiten wie mit jedem anderen Volume auch: Formatierung, Mount und Benutzung funktionieren sofort – OpenStack hat den Block Storage bereits im Hintergrund entschlüsselt.

Fassen wir zusammen

OpenStack bietet Alles, was zur Verschlüsselung deiner Volumes im Ruhezustand benötigt wird. Du kannst entweder über OpenStacks Horizon Dashboard oder über seine CLI Block Storage Volumes erstellen, verschlüsseln und anbinden, ohne die Konfiguration deiner Server anpassen zu müssen.
Das Feature verursacht kaum zusätzliche Kosten (OpenStack speichert den LUKS Verschlüsselungs-Key als Secret in Barbican, OpenStacks Key Manager – dadurch entstehen geringe Fixkosten pro Secret) und ist ein „Quick Win“ für die Absicherung deiner IT-Infrastruktur.