pixel
Select Page

NETWAYS Blog

Produkte im Shop bewerten und sparen!

Wir vom NETWAYS Shop sind immer auf der Suche nach Verbesserungen. Wie können wir mehr auf Dich und Deine Bedürfnisse eingehen? Wie können Angebote individueller gestaltet werden? Welche Hardware soll noch in unser Portfolio aufgenommen werden? Das alles läuft...

Produkte im Shop bewerten und sparen!

Produkte im Shop bewerten und sparen!

Wir vom NETWAYS Shop sind immer auf der Suche nach Verbesserungen. Wie können wir mehr auf Dich und Deine Bedürfnisse eingehen? Wie können Angebote individueller gestaltet werden? Welche Hardware soll noch in unser Portfolio aufgenommen werden? Das alles läuft...

Latest Posts

DockerCon 2022: Wie geht Containersecurity?

DockerCon 2022: Wie geht Containersecurity?

Buzzwords wie Software Supply Chain, Container Security Scanning oder Software Bill of Materials (SBOM) sind in den vergangenen zwei Jahren vermehrt in aller Munde, nicht zuletzt aufgrund des anhaltenden Trends zur Containerisierung vormals monolithischer Anwendungen...

Network Links between OpenStack and Kubernetes Projects

Network Links between OpenStack and Kubernetes Projects

We are happy to introduce cross-project network links between OpenStack and Kubernetes! This feature provides an easy and free solution for our customers to share one or multiple networks between their OpenStack and Kubernetes projects. We employ the native OpenStack...

The DevOpsDays are back!

The DevOpsDays are back!

DevOpsDays is a series of technical conferences on topics around the practices, tools and cultural philosophy for integrating processes between software development and IT operations teams. This year's two-day conference will take place in Berlin from September 21-22,...

Consulting & Technology

DockerCon 2022: Wie geht Containersecurity?

DockerCon 2022: Wie geht Containersecurity?

Buzzwords wie Software Supply Chain, Container Security Scanning oder Software Bill of Materials (SBOM) sind in den vergangenen zwei Jahren vermehrt in aller Munde, nicht zuletzt aufgrund des anhaltenden Trends zur Containerisierung vormals monolithischer Anwendungen...

Ein kurzer Abriss über Graylog Sidecar

Ein kurzer Abriss über Graylog Sidecar

Graylog Sidecar ist ein Konfigurationsmanagementsystem, ein sogenanntes Framework, für unterschiedliche Log Collectoren, auch Backends genannt. Die Graylog Nodes agieren hier als zentraler Hub und halten die Konfiguration der Log Collectoren. Auf unterstützten...

OSMC 2022 | Be a Sponsor!

OSMC 2022 | Be a Sponsor!

What is OSMC all about? OSMC is the premier worldwide professional event focussed on open source monitoring solutions. Today businesses have to deal with an increasing complexity of their IT infrastructure. Therefore it’s even more important to ensure availability of...

Events & Trainings

The DevOpsDays are back!

The DevOpsDays are back!

DevOpsDays is a series of technical conferences on topics around the practices, tools and cultural philosophy for integrating processes between software development and IT operations teams. This year's two-day conference will take place in Berlin from September 21-22,...

Icinga Camp Berlin: Erste Speaker online

Icinga Camp Berlin: Erste Speaker online

Endlich wieder ein Icinga Camp Berlin! Am 21. Juli 2022 kann das Gipfeltreffen der Icinga Enthusiasten in der Hauptstadt nach zweijähriger Pause endlich wieder stattfinden. Während das NETWAYS Events Team sich den Vorbereitungen des Camps im fantastischen HOTEL MELIÁ...

stackconf 2022 | Register now!

stackconf 2022 | Register now!

Get prepared for stackconf 2022! The preparation of the lecture program is in full swing and we are very excited to be able to present a great international and top-class speaker line-up again this year. Here are a few insights: Hannah Foxwell from VMware Tanzu will...

Web Services

Network Links between OpenStack and Kubernetes Projects

Network Links between OpenStack and Kubernetes Projects

We are happy to introduce cross-project network links between OpenStack and Kubernetes! This feature provides an easy and free solution for our customers to share one or multiple networks between their OpenStack and Kubernetes projects. We employ the native OpenStack...

Rocket.Chat: Was die Messenger-App genial macht

Rocket.Chat: Was die Messenger-App genial macht

Spätestens mit Beginn der Corona-Pandemie befinden sich die meisten Unternehmen in der Situation, dass ihre Mitarbeiter nicht mehr alle zentral an einem Ort zusammenarbeiten und jederzeit mal schnell über den Gang huschen können, wenn noch eine Info benötigt oder eine...

What is the Icinga Master App?

What is the Icinga Master App?

Du hast eine kritische Infrastruktur, die sich bei Ausfällen auch auf Deinen Gewinn auswirken kann? Dann ist die Icinga Master App genau das richtige für Dich und Dein Unternehmen!   Und was ist die Icinga Master App jetzt eigentlich? = Kurz gesagt, ist es ein...

Hardware

Produkte im Shop bewerten und sparen!

Produkte im Shop bewerten und sparen!

Wir vom NETWAYS Shop sind immer auf der Suche nach Verbesserungen. Wie können wir mehr auf Dich und Deine Bedürfnisse eingehen? Wie können Angebote individueller gestaltet werden? Welche Hardware soll noch in unser Portfolio aufgenommen werden? Das alles läuft...

HWgroup IP Watchdog2 – Volle Kontrolle in 2 Versionen

HWgroup IP Watchdog2 – Volle Kontrolle in 2 Versionen

Der HWgroup IP Watchdog2 ist ein Gerät zur Überwachung bestimmter Prozesse, das in der Lage ist, das überwachte Gerät aus der Ferne neu zu starten. Das Gerät ist in 2 Versionen erhältlich, die ich heute gerne vorstellen möchte. Beide sind ähnlich in der Anwendung,...

SMSEagle: Neue Software-Version 4.30

SMSEagle: Neue Software-Version 4.30

Wir freuen uns, Euch mitteilen zu können, dass diese Woche die neue Software-Version 4.30 für SMSEagle-Geräte veröffentlicht wurde! Diese Version enthält aufregende neue Funktionen, verschiedene Verbesserungen und einige Fehlerbehebungen. Nachfolgend findet Ihr eine...

Company

Produkte im Shop bewerten und sparen!

Produkte im Shop bewerten und sparen!

Wir vom NETWAYS Shop sind immer auf der Suche nach Verbesserungen. Wie können wir mehr auf Dich und Deine Bedürfnisse eingehen? Wie können Angebote individueller gestaltet werden? Welche Hardware soll noch in unser Portfolio aufgenommen werden? Das alles läuft...

Unsere ukrainischen Gäste im Kesselhaus

Unsere ukrainischen Gäste im Kesselhaus

Obwohl es für die meisten kaum vorstellbar war, haben wir seit dem 24. Februar wieder Krieg in Europa. Das unglaubliche Leid ist, trotz medialer Präsenz, nicht mal im Ansatz nachzuvollziehen und die Situation für die Menschen dort wird von Tag zu Tag schlimmer....

All Posts

Produkte im Shop bewerten und sparen!

Wir vom NETWAYS Shop sind immer auf der Suche nach Verbesserungen. Wie können wir mehr auf Dich und Deine Bedürfnisse eingehen? Wie können Angebote individueller gestaltet werden?
Welche Hardware soll noch in unser Portfolio aufgenommen werden? Das alles läuft natürlich im Hintergrund. Um Dir als Kundschaft den Weg zu uns zu erleichtern, gibt es immer die Möglichkeit mit uns per E-Mail über shop@netways.de im Gespräch zu bleiben. Wenn es mal schneller gehen soll und die Anfrage nur kurz ist, kannst Du uns auch jederzeit Livechat, den du auf unserer Shop Startseite rechts unten findest, treffen. Wir freuen uns auf Dich und Deine Fragen!

Um gemeinsam mit Dir mehr über unsere Produkte zu lernen (Du hast die Expertise in der Anwendung), gibt es sofort in unserem Online-Shop die Möglichkeit, unsere Produkte zu bewerten. Wir machen somit einfach mal den Realitätscheck und Du kannst uns dabei helfen!

Was springt für Dich dabei heraus?
Du kannst in Zukunft einfacher, besser und schneller zwischen Produkten vergleichen und natürlich von anderen Kundenerfahrungen profitieren. Das wiederum hilft uns, unser Sortiment und unsere Dienstleistungen weiterzuentwickeln und an Deine Bedürfnisse anzupassen. Somit haben wir beide gewonnen.

Das Beste kommt zum Schluss!
Wenn Du nach Kauf eines unserer Produkte im NETWAYS Shop bewertest, erhältst einmalig 10% Rabatt auf Deinen nächsten Einkauf in unserem Online-Shop! Du hast noch nie im Shop bestellt, weil du normalerweise per Bestellformular bestellst oder bestellen musst? Kein Thema. Wusstest Du, dass Du unser Kommentarfeld während des Bestellvorgangs prima für Deine Bestellnummern oder sonstige Informationen nutzen kannst? Bei Fragen dazu kannst Du gerne jederzeit auf uns zukommen.

So kommst Du zu Deinem verdienten Rabatt:
Schicke uns einfach einen Screenshot Deiner Bewertung an shop@netways.de und Du erhältst einen einmaligen Rabattcode für Deine nächste Bestellung (einlösbar im Shop). Einfacher geht es doch kaum, oder?
Wir freuen uns auf Deine Bestellung und Dein Feedback!

 

 

 

Isi Salampasidis
Isi Salampasidis
Sales Engineer

Isi ist seit Oktober 2019 zurück aus der Elternzeit und ist wieder für alle Belange des Online Shops verantwortlich. Der Ein- und Verkauf der Monitoring Hardware sowie die Weiterentwicklung des Shops und seines Portfolios wird sie mit ihrem bekannten Tatendrang gehörig vorantreiben. Privat verbringt die halbgriechische Ruhrpott-Fränkin sehr gerne so viel Zeit wie möglich mit Frau und Kind (Theodor, geboren im Mai 2018) oder engagiert sich ehrenamtlich für queer-feministische Projekte.

OSMC 2021 | Current State of Icinga

This entry is part 7 of 11 in the series OSMC 2021

OSMC 2021 has brought many insights into latest monitoring trends and we’re still amazed about that great on-site event last autmn. We’re happy to had a big amount of international attendees, 28 top-level speakers and not to forget our much valued sponsors on bord – in short: we’re grateful for everyone who made OSMC 2021 a special and an exciting event once again!

For all of you who would like to listen to last year’s experts sessions as a follow-up, I’ve created this blog series. It reminds you bi-weekly of one of our OSMC lectures including its video recording.

Today it’s all about Bernd Erk who updates us with the current state of Icinga.

Enjoy Bernd’s lecture!

 

 

If you’re already curious about what will await you at this year’s Open Source Monitoring Conference mark your calendars for November 14 – 16, 2022.

Grab your Early Bird ticket until June 30 and become part of an extraordinary open source event!

In case you have some great news to spread, you’re invited to join us as a speaker! Submit you paper for OSMC until July 31.

 

We’re looking forward to meeting you all again this autumn in Nuremberg.

Stay tuned!

Katja Kotschenreuther
Katja Kotschenreuther
Online Marketing Manager

Katja ist seit Oktober 2020 Teil des Marketing Teams. Als Online Marketing Managerin kümmert sie sich neben der Optimierung unserer Websites und Social Media Kampagnen hauptsächlich um die Bewerbung unserer Konferenzen und Trainings. In ihrer Freizeit ist sie immer auf der Suche nach neuen Geocaches, bereist gern die Welt, knuddelt alle Tierkinder, die ihr über den Weg laufen und stattet ihrer niederbayrischen Heimat Passau regelmäßig Besuche ab.

DockerCon 2022: Wie geht Containersecurity?

Buzzwords wie Software Supply Chain, Container Security Scanning oder Software Bill of Materials (SBOM) sind in den vergangenen zwei Jahren vermehrt in aller Munde, nicht zuletzt aufgrund des anhaltenden Trends zur Containerisierung vormals monolithischer Anwendungen und deren Betrieb als sog. Microservices. Allerdings kann nach wie vor nicht jeder, der auf die ein oder andere Weise mit Docker oder Containern im Allgemeinen zu tun hat, etwas mit diesen Begriffen anfangen. Aus diesem Grund habe ich den Fokus meines virtuellen Besuchs der diesjährigen DockerCon auf genau diesen Themebereich – Containersecurity – gelegt und möglichst viele Best Practices für Dich zusammengefasst.

 

Die Ausgangslage

Die großen Sicherheitslücken der vergangenen zwei Jahre, sei es der Solarwinds-Breach oder die Log4J/Log4Shell-Exploits haben einmal mehr schmerzlich bewusst gemacht: In fast jedem Softwareprodukt, egal ob proprietär oder Open Source, befinden sich zahlreiche mehr oder weniger gut gepflegte Abhängigkeiten verschiedenster Maintainer – in vielen Applikationen stecken bis zu 80% Open Source Code, die es “auf dem Schirm” zu behalten gilt. Dies gilt natürlich auch für Container(-images), die letzten Endes nichts anderes tun, als die Applikation zu bündeln und (weitestgehend) losgelöst vom ausführenden Hostsystem ausführbar zu machen.

Dennoch gelten Container paradoxerweise oft als besonders sicher, sei es aufgrund der von außen wahrgenommenen “Kapselung” oder der geringen Größe – soviel potentiell vulnerable oder bösartige Software kann da doch gar nicht drinstecken, oder? Mögen diese Wahrnehmungen in der Theorie und im Bestfall auch stimmen, sieht die Praxis in den allermeisten Fällen anders aus, wie die ein oder andere Keynote im Rahmen der DockerCon gezeigt hat.

Laut SysDig, einem Spezialisten für Cloudsecurity, laufen 58% der in den einschlägigen Containerregistries (DockerHub, Google, Github, etc.) verfügbaren Containerimages als root, anstatt einen geeigneteren, unprivilegierten Nutzer zu verwenden. Außerdem beinhalten selbst die offiziellen, von den Registries kuratierten Containerimages beliebter Frameworks oder Distributionen dutzende detektierbare Schwachstellen.

Offensichtlich gibt es also zum Einen ein falsches Gefühl von Sicherheit innerhalb der Nutzergemeinschaft von Containern, zum Anderen aber schlichtweg keine Blaupause oder “OneFitsAll”-Lösung, die für beliebige Container(-images) absolute Sicherheit verspricht. Nur eine Sache ist klar: “Hinten” anzufangen, ist nicht rentabel – Container einfach zu deployen und dann im Betrieb nach Sicherheitslücken zu suchen, ist teuer, erzeugt vermeidbaren zusätzlichen Aufwand und nimmt Flexibilität. Die Absicherung der Container muss “nach links” geschoben werden, möglichst an den Beginn der Containerisierung. Doch wo ansetzen?

 

Die Möglichkeiten

Um den Ursprung für Schwachstellen in Container(-images) und damit einhergehend mögliche Ansatzpunkte zur Absicherung zu identifizieren, muss man die “Lebensphasen” eines Container(-images) verstehen. Diese lassen sich kurz und bündig wie folgt darstellen:

 

  • Bau des Images (lokal oder via CI/CD)
  • Distribution des Images – Push in eine Registry (Self-hosted oder bei einem Anbieter), Pull von Usern/Programmen
  • Deployment des Images (Openshift, (Managed) Kubernetes, etc.) und Betrieb des Containers

 

An dieser Stelle wird hoffentlich klar, warum ich permanent “Container(-image)” schreibe – abhängig von der betrachteten Lebensphase haben wir es beim Thema Containersicherheit entweder mit einem erstellten Image oder mit einem laufenden Container, quasi einer Instanziierung dieses Images zu tun. Mit dieser Aufschlüsselung in verschiedene Abschnitte können wir uns nun mögliche Schritte zur Absicherung unserer Container anschauen.

Containerimages werden entweder lokal von Entwickler:innen, DevOps-Engineers, etc. auf Grundlage eines sog. Dockerfiles gebaut – alternativ lässt sich dieser Vorgang aber auch von CI/CD Pipelines umsetzen, wenn man den Dockerfile und andere benötigten Ressourcen bspw. in GitLab eincheckt. Die meisten Möglichkeiten zur Absicherung des späteren Container(-images) ergeben sich bereits in diesem ersten Schritt – der Quellcode der zu containerisierenden Applikation liegt vor, ebenso die Definition des Containers selbst, und auch möglicherweise vulnerable oder bösartige Abhängigkeiten wurden noch nicht in das spätere Containerimage eingebettet.

Ist das Containerimage lokal oder in einer Pipeline gebaut worden, muss man es zur späteren Nutzung in Produktion in eine Containerregistry übertragen. Diese kann entweder selbst gehosted werden, als private, aber gemanagte Instanz in der Cloud laufen oder öffentlich von jedem beliebigen Nutzer einsehbar sein. Auch bei diesem Vorgang gibt es Möglichkeiten, die Supply Chain zwischen Entwickler und Endnutzer abzusichern.

Auch wenn im Dockerfile gewisse Best Practices befolgt werden, kann der Container diese in vielen Fällen beim Deployment überschreiben – das letzte Wort haben hierbei immer Kubernetes, Openshift, Docker Desktop und Konsorten. Aus diesem Grund müssen einige der Überlegungen, die in der Build-Phase des Containerimages stattgefunden haben, auch hier noch einmal herangezogen, betrachtet und evaluiert werden, um die für die konkrete Nutzung besten Einstellungen und Kompromisse zu finden.

Ist der Container erst einmal deployed, gibt es nicht mehr viele Möglichkeiten, ihn “von innen” weiter abzusichern. Dennoch kann und sollte man sich fortlaufend Gedanken bspw. um die Erreichbarkeit innerhalb des Clusters, des Netzwerkes, der Cloud etc. machen, Regeln nachziehen wo nötig und natürlich auch Update- und Backupstrategien im Hinterkopf behalten. Am Ende des Tages merkt man spätestens jetzt: Nach dem Deployment eines Containers seine Sicherheit zu überprüfen und zu garantieren, ist nicht sinnvoll – wir brauchen einen Left Shift.

 

Die Umsetzung

Buildphase

Nach viel Theorie und Konjunktiv können wir uns jetzt konkrete Umsetzungsmöglichkeiten der besprochenen Ansätze anschauen. Beginnen werden wir “ganz links” beim Bau der Containerimages. Vieles lässt sich hier über verschiedene Direktiven im genutzten Dockerfile festlegen – Docker listet alle möglichen Direktiven sowie sinnvolle Best Practices und Caveats in der Docker Dokumentation auf. Für uns besonders interessant sind die Direktiven ADD, COPY und USER. Wie eingangs erwähnt, nutzen mehr als die Hälfte aller Containerimages per Default den root Nutzer innerhalb des Containers, obwohl das in vielen Fällen gar nicht notwendig wäre – auf einem klassischen Server läuft ein Apache2 Webserver schließlich auch als User apache, warum sollte/müsste das innerhalb eines Containers bspw. auf Debian-Basis anders sein?

Die anderen beiden erwähnten Direktiven beziehen sich auf die Abwägung, ob man gewisse Verzeichnisse und Dateien aus seiner Entwicklungsumgebung denn tatsächlich im endgültigen Container braucht – oder ob man die Applikation direkt lokal baut, und lediglich die fertige Binary via COPY in das Containerimage überträgt. In diesem Fall muss man natürlich darauf achten, dass etwaige zur Laufzeit benötigte Tools (ich meine dich, curl) und Bibliotheken sich auch im endgültigen Containerimage befinden. Alternativ kann man innerhalb eines Dockerfiles eine build und eine run Umgebung schaffen – auf diese Weise kann man die Applikation innerhalb des Containers bauen und im Anschluss lediglich die benötigten binären Artefakte und andere benötigten Ressourcen in das Lauzeitimage kopieren. Für diese Vorgehensweise würde es sich anbieten, das Entwicklungsrepository via ADD in die build Umgebung des Containerimages zu übertragen.

Diese Vorgehensweise bringt uns direkt zur nächsten “beliebten” Unsicherheit in Container(-images): Lokal hinterlegte Credentials, Entwicklertokens, Cloudzugänge etc. Es gibt vermutlich keine Art von geheimen Daten, die nicht bereits versehentlich in Containerimages “vergessen” wurde. Das kann schnell passieren – ein Entwickler nutzt ein Shellscript mit Zugangsdaten, um von seiner Entwicklungsumgebung in ein Testcluster zu deployen, eine .yaml-Datei, um Daten aus einer Entwicklerdatenbank zu lesen etc. Im “schlimmsten Fall” überträgt er wissentlich eine Datei mit Zugangsdaten, die die containerisierte Applikation später in Produktion nutzen soll, oder hinterlegt sensible Daten im Containerimage als Umgebungsvariable mittels ENV.

Zur Bewältigung dieser Problematik gibt es die Möglichkeit, ähnlich wie eine .gitignore Datei für Git-Repositories eine .dockerignore Datei für den Buildvorgang eines Containerimages zu hinterlegen. Alle in dieser Datei aufgeführten Dateien und Verzeichnisse werden vom Dockerdaemon bei der Verarbeitung des Build-Contexts, von ADD und von COPY Direktiven ignoriert und finden sich somit zu keinem Zeitpunkt im Containerimage wieder. Dringend benötigte Umgebungsvariablen zur Konfiguration der containerisierten Applikation können auch zum Zeitpunkt des Deployments noch übergeben werden, bspw. mittels des Parameters -e via Docker-CLI oder dem Einlesen von Secrets als Umgebungsvariablen in Kubernetes.

Grundlegende Maßnahmen wie die Nutzung eines passenden Base-Images in der FROM Direktive (es muss nicht immer debian:buster oder ubuntu:20.04 sein), das Vermeiden der Öffnung unbenötigter Ports via EXPOSE sowie der Nutzung sog. Kannibalen-Tags (latest zeigt nach jedem Imageupdate auf eine neue Version) sollten darüber hinaus natürlich immer befolgt und beachtet werden.

Distributionsphase

Haben wir nun lokal oder in der Pipeline ein in sich möglichst sicheres Containerimage gebaut, muss es auf die eine oder andere Art und Weise seinen Weg in eine Containerregistry finden, um von anderen Nutzern heruntergeladen und deployed werden zu können. Für diese Vorgänge werden einem von den meisten Containerregistries Werkzeuge an die Hand gegeben, mit deren Hilfe wir den Prozess des Up-/Downloads von Containerimages absichern können.

Letzten Endes sind Containerregistries nichts anderes als APIs mit der Fähigkeit, Nutzer zu authentifizieren und zu authorisieren, Containerimages in Empfang zu nehmen, zu speichern und deren Versionierung im Blick zu behalten. Wie immer, wenn man über das Internet mit einer API spricht, gilt: HTTPS ist Pflicht! Darüber hinaus bieten Registries verschiedene Möglichkeiten, zusätzliche Maßnahmen gegen die Verbreitung unsicherer Images oder die Manipulation vorhandener Containerimages zu treffen. So können Imageregistries oftmals alle verwalteten Containerimages auf bekannte Schwachstellen scannen und den Download solcher Images durch Endnutzer untersagen. Auch die digitale Signierung von verwalteten Containerimages ist oftmals möglich, z.B. mittels sigstore und cosign.

Deploymentphase

Wird unser Containerimage nun im Rahmen eines Kubernetes-Deployments oder Docker-CLI-Befehls aus der Registry gepulled und deployed, haben wir einmal mehr die Möglichkeit, Sicherheit zu forcieren: Wie bereits erwähnt, können wir zum Einen die Voreinstellungen in Hinblick auf Umgebungsvariablen, User- und Gruppenkontext uvm. überschreiben, zum Anderen bietet natürlich auch die Absicherung der ausführenden Infrastruktur selbst die Möglichkeit, dass Deployment so sicher wie möglich zu gestalten.

Hierzu zählen z.B. die Nutzung sog. rootless Container, die von einem Container Runtime Interface (CRI) wie Docker oder containerd ausgeführt werden, die selbst nicht im root Kontext laufen. Auch die Nutzung restriktiver Netzwerk- und Firewallpolicies kann dabei helfen, die Risiken durch möglicherweise vulnerable oder bösartige Container zu minimieren. Konfiguration und Forcierung dieser Maßnahmen innerhalb eines Clusters können schnell zur Sisyphusarbeit werden – hier kann ein gemanagtes Kubernetes-Cluster von Vorteil sein, bspw. Managed Kubernetes von NETWAYS Web Services. Darüber hinaus sollte man eine nachhaltige Update-Strategie für seine Containerimages verfolgen: Es gilt, einen guten Kompromiss zwischen regelmäßigen Updates zu finden, aber nicht sofort jede neue Version (und deren evtl. neu eingeführte Schwachstellen) in Produktion zu deployen.

 

Das Fazit

Container(-images) sicher zu erstellen, zu verwalten und zu deployen ist ein langer Weg voller Stolpersteine. Wie so oft beim Thema Sicherheit wird man die 100% aller Voraussicht nach nicht erreichen – Nichtexistenz von Sicherheitslücken lässt sich nun einmal nicht beweisen. Dennoch habe ich Dich hoffentlich für das Thema und die teils falschen, gängigen Annahmen und Praktiken sensibilisieren können und nebenbei einige Best Practices an die Hand gegeben, die das Risiko durch vulnerable Container deutlich verringern.

Solltest Du nun mehr über den Vorgang des Imagebaus, den Betrieb von Containern in Kubernetes oder Containerisierung im Allgemeinen erfahren wollen, schau Dir doch einmal unser Kubernetes Schulungsangebot von NETWAYS an. In diesem eintägigen Workshop vermittle ich Dir praxisnah und einsteigerfreundlich alles, was Du für die ersten eigenen Schritte mit Docker und Kubernetes wissen musst. Ich freue mich auf Dich!

Daniel Bodky
Daniel Bodky
Consultant

Daniel kam nach Abschluss seines Studiums im Oktober 2021 zu NETWAYS und berät nun Kunden zu den Themen Icinga2 und Kubernetes. Nebenher schreibt er in seiner Freizeit kleinere Tools für verschiedenste Einsatzgebiete, nimmt öfters mal ein Buch in die Hand oder widmet sich seinem viel zu großen Berg Lego. In der wärmeren Jahreszeit findet man ihn außerdem oft auf dem Fahrrad oder beim Wandern.

Network Links between OpenStack and Kubernetes Projects

We are happy to introduce cross-project network links between OpenStack and Kubernetes!
This feature provides an easy and free solution for our customers to share one or multiple networks between their OpenStack and Kubernetes projects.
We employ the native OpenStack RBAC feature to make this possible.
As a result, our customers can now establish local connections between their OpenStack servers and Kubernetes clusters.

 

How you can use it

You will need to have at least one OpenStack project and one Kubernetes project with at least one cluster. Alternatively, two OpenStack projects or two Kubernetes projects with different subnets will also work.

Once you are logged in to your NWS account, just navigate to either one of your OpenStack projects or one of your Kubernetes projects.
Next, click on “Networks” – this is a new section we added to the menu of the projects.
A list with all of the networks of the project will show up. Next to each of the networks you will find an action called “Manage network links“.
If you click on “Manage network links”, a popup window will show up containing a list of all the other networks that you have in your other Kubernetes and OpenStack projects.

 

The networks are grouped by the projects they belong to. For each network you now have an option to create a link, as seen in the screenshot. If you have chosen a network, which you would like to link to the current network, you just have to click on the “Create Link” button next to it.

 

Doing so will trigger a job which will be processed in the background. As one of the first steps, the job will check, if the selected networks are compatible with each other. Two networks are compatible, if they contain subnets with different subnet addresses. Furthermore, there must be a router in each of the projects, which has an interface on each of the networks.

 

Only, if both of those requirements are met, it will be possible to route between the networks and the job will start. Once it’s finished, you’ll get notified.

 

In case the requirements are not met you will get a notification telling you that the subnets are incompatible.

 

By default, our OpenStack and Kubernetes networks are compatible with each other. If you want to link Kubernetes with Kubernetes, then the only way to ensure compatibility is to supply a custom subnet address on creation to one of the clusters. For OpenStack to OpenStack you do not have the option (yet) to supply a custom subnet address to your default network on creation of the project. However, you can create your own custom networks with any subnet addresses and ensure compatibility that way.

 

Why should you use it?

Some might ask, why should one want to use this feature? Here is an example:
Let’s say, you have your application running on your Kubernetes cluster and you need to connect it to a database, which is running on a server in your OpenStack project. In that case you want to have a secure connection – a VPN comes to mind. Another approach would be a Database with a floating IP and security group rules.
But both of those options come with some tradeoffs: in case of the VPN, you have another point of failure and additional network overhead. And with a floating IP on your database you might not sleep so well, because of security concerns.
This new feature comes in handy, as the connections are not leaving our internal network infrastructure and traffic can flow locally between the projects and networks without additional overhead!

We already had some customers who were using this feature before the launch of the integration into NWS. In those cases one of our MyEngineers would configure the cross-connection manually for the customer.
But now it comes at no additional costs, because it does not require any action of one of our MyEngineers. Feel free to try it. Should you have any questions, don’t hesitate to send us a message or use our LiveChat on our website, which can be found in the bottom right corner.

 

Gabriel Hartmann
Gabriel Hartmann
Systems Engineer

Gabriel hat 2016 als Auszubildender Fachinformatiker für Systemintegrator bei NETWAYS angefangen und 2019 die Ausbildung abgeschlossen. Als Mitglied des Web Services Teams kümmert er sich seither um viele technische Themen, die mit den NETWAYS Web Services und der Weiterentwicklung der Plattform zu tun haben. Aber auch im Support engagiert er sich, um den Kunden von NWS bei Fragen und Problemen zur Seite zu stehen.

The DevOpsDays are back!

DevOpsDays is a series of technical conferences on topics around the practices, tools and cultural philosophy for integrating processes between software development and IT operations teams.

This year’s two-day conference will take place in Berlin from September 21-22, and is geared toward developers, sysadmins, and anyone involved in techniques related to DevOps – whether you’re a beginner or an expert.

Submit your Talk!

We are currently looking for speakers for the event in Berlin. The Call for Papers runs until June 30, 2022. If you feel like sharing your know-how, simply submit your presentation.

Presentations in English about experiences and best practices with DevOps culture as well as topics around automation, testing, security and organizational culture are very welcome.

There are two different lecture formats to choose from:

  • 30-Minute Talk | presented during the conference usually in the morning.
  • Ignite Talk | five-minute presentation with 20 slides that change every 15 second

If you’d like to lead a group discussion during the attendee-suggested Open Space breakout sessions, it is not necessary to propose it ahead of time.

Become a Sponsor!

As a sponsor, you have many opportunities to promote your company. Depending on your sponsorship package, you have different options to present yourself to your target group.

There are three different sponsor packages available: Silver, Gold and Platinum.

Whether it’s additional tickets, your own booth, introducing your brand to the entire audience, or your logo being promoted on social media and the event website, there’s something for everyone!

 

Tickets for this year’s DevOpsDays are already available.

Save your spot and be there from September 21 – 22 in Berlin!

The DevOps community is looking forward to seeing you!

Katja Kotschenreuther
Katja Kotschenreuther
Online Marketing Manager

Katja ist seit Oktober 2020 Teil des Marketing Teams. Als Online Marketing Managerin kümmert sie sich neben der Optimierung unserer Websites und Social Media Kampagnen hauptsächlich um die Bewerbung unserer Konferenzen und Trainings. In ihrer Freizeit ist sie immer auf der Suche nach neuen Geocaches, bereist gern die Welt, knuddelt alle Tierkinder, die ihr über den Weg laufen und stattet ihrer niederbayrischen Heimat Passau regelmäßig Besuche ab.