von Daniel Bodky | Apr 30, 2024 | Software as a Service
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.
von Daniel Bodky | Mrz 27, 2024 | Event
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!
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.
von Daniel Bodky | Mrz 27, 2024 | Event
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.
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 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.
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!
von Daniel Bodky | Mrz 8, 2024 | OpenStack, Tutorial
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.
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
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.
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:
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.
von Daniel Bodky | Feb 20, 2024 | Kubernetes, Tutorial
In einem der ersten Tutorials auf unserer Seite haben wir dir gezeigt, wie du Ingress-NGINX in deinem Cluster installieren und einrichten kannst. Heute gehen wir einen Schritt weiter und schauen uns an, wie du Ingress-NGINX und deine Services mit Hilfe von TLS-Zertifikaten durch Cert-Manager absichern kannst!
Was ist Cert-Manager?
Cert-Manager ist ein CNCF-Projekt zur automatischen bzw. programmatischen Bereitstellung von TLS-Zertifikaten. Das Programm beobachtet kontinuierlich annotierte Ressourcen (z.B. Ingress Objekte) und eine Sammlung an CustomResourceDefinitions um Zertifikate für deine Workloads anzufragen, zu erstellen, und zu erneuern. Auf der Liste der unterstützten Certificate Authorities finden sich u.A. ACME, GlobalSign, Hashicorp Vault, oder Cloudflare Origin CA. Nachdem diese initiale Frage geklärt ist, können wir uns als Nächstes anschauen, wie man Ingress-NGINX mit Cert-Manager absichern kann!
Installation von Ingress-NGINX
Um Ingress-NGINX absichern zu können, müssen wir Ingress-NGINX installieren – logisch! Wir werden dafür auf Helm zurückgreifen, eine Art Paketmanager für Kubernetes. Analog zur Installation von Softwarepaketen auf einem Betriebssystem folgt auch die Installation von Anwendungen auf Kubernetes mittels Helm einem gewissen Schema:
- Konfigurieren des Repositories
- Abfragen verfügbarer Pakete und Versionen
- Installation des gewünschten Pakets
Mit Helm sieht dieser Vorgang wie folgt aus:
helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install --namespace ingress-nginx --create-namespace ingress-nginx ingress-nginx/ingress-nginx
Warum 4x ingress-nginx?!
Der dritte Befehl sieht evtl. ein wenig komisch aus – wozu müssen wir viermal „ingress-nginx“ angeben? Die erste Angabe ist für den Namen des Namespaces, in den wir unsere Anwendung installieren möchten. Die zweite Angabe ist für den Releasenamen, den Helm nutzt, um unsere Installation(en) zu managen, und die dritte/vierte Angabe referenziert das genutzte Repository bzw. Paket.
Terminieren alle drei Befehle erfolgreich, ist Ingress-NGINX bereits erfolgreich installiert und bereit, Anfragen an die Dienste in unserem Cluster zu bearbeiten. Wir können also mit der Installation von Cert-Manager weitermachen.
Installation von Cert-Manager
Genau wie zur Installation von Ingress-NGINX können wir auch für Cert-Manager Helm nutzen. Wir fügen das entsprechende Repository hinzu, syncen die verfügbaren Paket und installieren Cert-Manager in unser Cluster. Mit der zusätzlichen Einstellung installCRDs stellen wir sicher, dass die von Cert-Manager genutzten CustomResourceDefinitions mitinstalliert werden.
helm repo add jetstack https://charts.jetstack.io/
helm repo update
helm install --namespace cert-manager --create-namespace cert-manager jetstack/cert-manager --set installCRDs=true
Auch Cert-Manager ist erfolgreich installiert, sobald die Helm-Befehle erfolgreich terminieren. Alles, was uns jetzt noch fehlt, ist ein sog. Issuer .
Erstellung eines Issuers
Wie eingangs erwähnt, unterstützt Cert-Manager viele verschiedene Zertifikatsanbieter. Dafür muss es natürlich wissen, welche Authorität für die Ausstellung eines gewissen Zertifikats genutzt werden soll. Hierfür können Cert-Manager’s Issuer CRDs genutzt werden. Im Rahmen dieses Tutorials nutzen wir den ACME Issuer, der es uns erlaubt, Let’s Encrypt Zertifikate für unsere Services zu erstellen:
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-staging
namespace: cert-manager
spec:
acme:
# You must replace this email address with your own.
# Let's Encrypt will use this to contact you about expiring
# certificates, and issues related to your account.
email: daniel@example.com
# we will only use the staging API for this tutorial
server: https://acme-staging-v02.api.letsencrypt.org/directory
privateKeySecretRef:
# Secret resource that will be used to store the account's private key.
name: acme-staging-key
# Add a single challenge solver, HTTP01 using nginx
solvers:
- http01:
ingress:
ingressClassName: nginx
Dieser Issuer nutzt die Staging API von Let’s Encrypt, um gültige (aber nicht vertrauenswürdige) Zertifikate für unsere Services zu erstellen. Um die Authentizität unserer Services zu überprüfen, werden HTTP01-Challenges genutzt (s. Let’s Encrypt Challenge Types). Wenn wir genau hinschauen, sehen wir, dass wir statt einem Issuer einen ClusterIssuer nutzen, der clusterweit referenziert werden kann. Als Nächstes können wir die Definition in unser Cluster einspielen:
kubectl apply -f clusterissuer.yml
Damit unser Ingress in der Lage ist, wie gewünscht zu funktionieren, brauchen wir jetzt noch Konnektivität.
Vorbereitung des Ingress
Möchten wir unseren Ingress über das Internet erreichen und ein TLS-Zertifikat für in generieren (lassen), benötigen wir einen DNS-Eintrag. Für diesen wiederum brauchen wir die Ingress IP unseres Clusters. Diese IP wird von Ingress-NGINX für seinen Clusterdienst vom Typ LoadBalancer genutzt, um Traffic in unser Cluster zu routen.
Erstellung eines DNS-Eintrags
Wir können die öffentlich verfügbare IP des Ingress-NGINX Dienstes mit folgendem Befehl ausgeben lassen:
kubectl get svc -n ingress-nginx ingress-nginx-controller -o jsonpath={.status.loadBalancer.ingress[0].ip}
Für diese IP benötigen wir nun einen A Eintrag für eine gültige (Sub)domain bei unserem DNS-Provider. Wie genau dieser Eintrag angelegt werden kann, unterscheidet sich von Anbieter zu Anbieter und ist nicht der Fokus dieses Tutorials.
Installation einer Demoanwendung
Das letzte fehlende Puzzlestück ist eine Anwendung, die wir absichern und mit unseren Webbrowsern aufrufen können. Wir werden hierzu podinfo deployen, eine oftgenutzte Demoanwendung mit einem kleinen Webfrontend. Zur Installation nutzen wir erneut Helm:
helm repo add podinfo https://stefanprodan.github.io/podinfo
helm repo update
helm install --namespace podinfo --create-namespace podinfo podinfo/podinfo
Nach einem kurzen Augenblick ist die Anwendung in unserem Cluster installiert, inklusive eines ClusterIP Dienstes, den wir im nächsten Schritt in unserem Ingress referenzieren können.
Ingress-NGINX mit Cert-Manager absichern
Wir haben nun endlich alle benötigten Voraussetzungen erfüllt und können jetzt im abschließenden Schritt einen Ingress erstellen und absichern:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
annotations:
cert-manager.io/cluster-issuer: letsencrypt-staging
name: podinfo
namespace: podinfo
spec:
ingressClassName: nginx
rules:
- host: podinfo.cluster.example.com
http:
paths:
- pathType: Prefix
path: /
backend:
service:
name: podinfo
port:
number: 9898
tls: # < placing a host in the TLS config will determine what ends up in the cert's subjectAltNames
- hosts:
- podinfo.cluster.example.com
secretName: podinfo1-tls
Ein paar Punkte fallen auf:
- wir erstellen den
Ingress im selben Namespace in dem wir auch podinfo installiert haben
- wir fügen eine Annotation hinzu, die Cert-Manager anweist, unseren zuvor erstellten
ClusterIssuer für die Zertifikatsgenerierung zu nutzen
- unser
Ingress wird Anfragen an https://podinfo.cluster.example.com/ an unseren podinfo Dienst weiterleiten
- zusätzlich definieren wir einen Hostnamen für den SAN-Eintrag unseres Zertifikats und einen Namen für das Zertifikat selbst
Diese Konfiguration können wir in unser Cluster einspielen:
kubectl apply -f ingress.yml
- Cert-Manager die Annotation unseres
Ingress liest und…
- …einen weiteren temporären
Ingress für die HTTP01-Challenge erstellt
- …das angefragte
Certificate als CRD erstellt
- …das zugehörige Secret podinfo1-tls für unseren
Ingress erstellt
- Ingress-NGINX das
Ingress Objekt mit der öffentlichen IP verknüpft.
Sind all diese Punkte abgeschlossen, können wir in unseren Webbrowsern https://podinfo.cluster.example.com aufrufen – und werden von der altbekannten Meldung „Your Connection is not secure“ begrüßt.
Unser Zertifikat wird von den meisten Webbrowsern nicht anerkannt werden.
Das passiert, weil wir Let’s Encrypt’s Staging API als Certificate Authority konfiguriert haben. Klicken wir auf Show advanced und bestätigen mit Proceed to https://podinfo.cluster.example.com/, werden wir trotzdem zu podinfo weitergeleitet:
Podinfo’s Tintenfisch freut sich, uns zu sehen
Es funktioniert! Podinfo’s Maskottchen applaudiert uns für die korrekte Konfiguration unseres Ingress und ClusterIssuer . Der Vollständigkeit halber können wir in den Zertifikatsdetails unseres Webbrowsers auch noch verifizieren, dass das angefragte Zertifikat von Cert-Manager erstellt wurde:
Das Zertifikat wurde von Let’s Encrypts STAGING API ausgestellt.
Zusammenfassung
Geschafft – wir haben unseren Ingress-NGINX mit Cert-Manager abgesichert! Alles, was wir dafür benötigt haben, war ein ClusterIssuer , der Let’s Encrypts (Staging) API nutzt, und eine dazugehörige Annotation in unserem Ingress Objekt. Solltest du noch weiter experimentieren wolle, kannst du als nächsten Schritt Let’s Encrypts Production-API nutzen, indem du den staging Teil aus der konfigurierten URL des ClusterIssuer herausnimmst. Dann sollte sich auch dein Webbrowser nicht mehr beschweren, dass das Zertifikat nicht vertrauenswürdig ist. Deployst du bereits andere Anwendungen mit Helm, kann es außerdem gut sein, dass es bereits vordefinierte Values oder eingebauten Cert-Manager-Support für deine Anwendung(en) gibt – schau doch einfach einmal nach! Und war das Tutorial jetzt doch etwas zu schnell oder gewisse Punkte noch unklar, zögere nicht, bei unseren MyEngineers durchzuklingeln – sie brennen dafür, dir jederzeit unter die Arme zu greifen!
Recent Comments