NETWAYS Blog

stackconf online 2021 | Why you should take care of infrastructure drift

by Henrik Triem | Oct 26, 2021 | Events, NETWAYS, stackconf

This entry is part [0] of 9 in the series stackconf online 2021

stackconf online 2021 is over and was a full success. It was all about open source infrastructure solutions in the spectrum of continuous integration, container, hybrid and cloud technologies. We’re still excited about all of our experts sessions and the large number of participants who joined us from all over the world. In the following you get an insight about one of our talks.

Stephane Jourdan, co-author of Infrastructure-as-Code Cookbook and co-founder of Driftctl lectures us in the talk “Why you should take care of infrastructure drift” about infrastructure drift, why it’s causing issues and how to avoid and mitigate it.

The talk starts off by looking for a definition for infrastructure drift, asking users and customers for their experiences. Infrastructure drift happens when the reality and the expectations don’t match is the definition given. This is supplemented by a technical explanation: the configuration provided by our management tools doesn’t match the configuration on our actual machines. For varying reasons, whatever configuration we have running in our cloud infrastructure, in our AWS machines, differs from the configuration we have provided in Terraform. That difference is infrastructure drift.

Infrastructure drift: A simple overview

It is caused by unmanaged resources in the cloud infrastructure, be it manual inputs directly into the machines, dynamic updates, different teams working with different software, making changes to the configuration in the cloud. These changes are not being supervised by our configuration management tool, and if not checked regularly for infrastructure drift, these differences can stay there for weeks, months even. Many companies are adopting automation when using and providing cloud infrastructure and it is very easy to overlook infrastructure drift, posing a considerable security threat. Driftctl helps us by checking for these differences and giving us a report about the quantity of infrastructure drift.

Then Stephane shares user stories with us. We hear about using Driftctl to check Terraform: users making manual inputs, changing access rules and firewall configurations in AWS creating rules which are not being covered by Terraform. These issues were caused by varying authorized people making changes directly in AWS web UI, and persisted in each case with unacceptable duration. The usage of Driftctl is being presented to us in live demos – the user inputs of the stories were being replicated and Stephane demonstrates how Driftctl checks these differences and notifies the user by giving a percentage calculated, informing them about the serverity of the infrastructure drift in their environments.

Driftctl scans Terraform and finds two rouge instructions

To finish up his talk, Stephane shows us more usages of Driftctl: scanning JSON Output for differences, using the .driftignore file to ignore occurrences of infrastructure drift, scanning with filters to focus on specific areas of the AWS accounts, and using Driftctl in CI setups, where a Docker container is being provided for easy integration in various CI systems.

stackconf 2022 will take place in Berlin. The final date will be announced soon. If you want to learn more about infrastructure solutions in advance you have the possibility to take look at our archive where you can find all slides and videos from this year’s stackconf.

Stay tuned!

Henrik Triem

Developer

Henrik ist Anwendungsentwickler und Trainer, verhinderter Rockstar und Open Source-begeistert. Erfolgreich bei NETWAYS ausgebildet geht er hier seiner Leidenschaft für Packaging und Icinga nach. In seiner Freizeit sieht man ihn gerne an Klavier oder Gitarre sitzen.

Read more from Henrik and meet the Team

OSMC Hackathon – Share your impressions!

by Henrik Triem | Nov 19, 2019 | Events, OSMC

After two informative and exciting days at OSMC, the cherry on the sundae for me was joining our fifth OSMC hackathon for the first time. Hearing and learning about the discoveries, lessons learned and experiences made by other people in different environments, maybe using different tools, and being shown cool tricks and setups, I personally always get a little twitchy in my fingers wanting to jump at my keyboard and download, clone, install, code and play around with all the amazing new stuff I’ve learned attending OSMC 2019.

And the hackathon is the perfect setting to do this – people having seen the same talks, being excited about the same new features that have been at the forefront of discussion during the last few days.

On Wednesday the attendees made a short trip to a restaurant to have dinner, where people got to know each other casually and dream up the first plans and ideas for the main event tomorrow. After a well deserved night of sleep, the morning started with high spirits and a bit of coffee.

Round tables were placed in Saal Elizabeth, the biggest of the three OSMC conference rooms, everybody got together, and after Bernd welcomed us (and told us when lunch would be served!) everybody got a chance to introduce themselves, what one was looking for on this day, where areas of expertise lie, and if there are any specific problems to be solved.

Collaborative hacking equals collaborative fun

The topics were as diverse as the plethora of tools discussed at OSMC – people were working with GitHub Actions, Golang, Kubernetes, translating bash scripts in python, setting up clusters with Grafana, LOKI, Prometheus, automating the pain away with Ansible, having private lessons in Terraform, making logging more effective with Elasticsearch and Logstash, Icinga modules like Icingabeat, looking at the awesome stuff you can do with Icinga Director, and I’ve even seen people working on issues and pull requests – as we know, the community is always active. #monitoringlove <3

Personally, I was working with Tobias on a SELinux check plugin for Icinga, but mostly, I was looking around, taking in the experience and trying to learn a bit from all the interesting discussions that developed. I can really recommend it! It can make your OSMC experience more complete and rounded, working, coding and developing alongside the experts. Maybe this year you were only able to check out our cool videos from OSMC, and you really wanted to ask one of our amazing speakers a certain question? Well, follow our Twitter at @NetwaysEvents, keep an eye out for the next registration, sign up for two days of open source monitoring goodness plus the hackathon and meet up with your engineering heroes – I’ll be there and I’m looking forward to you!

Henrik Triem

Developer

Read more from Henrik and meet the Team

NETWAYS stellt sich vor – Henrik Triem

by Henrik Triem | Oct 23, 2019 | NETWAYS

This entry is part 21 of 35 in the series NETWAYS stellt sich vor

Name: Henrik Triem Alter: 24 Jahre Position bei NETWAYS: Junior Developer Bei NETWAYS seit: August 2018

Was genau gehört zu Deinem Aufgabenbereich bei NETWAYS? Ich habe das große Vergnügen, mich in C++ und Icinga Core reinzufuchsen. Von den Grundlagen der Softwareentwicklung bis hin zu ausgeklügelten Feinheiten des Icinga-Codes, meine Hauptaufgabe ist es momentan, mich zu einem Icingaexperten zu machen. Dazu werden von mir Issues bearbeitet, ich sauge die Konzepte und Ideen auf, die meine Kollegen in den Code eingearbeitet haben, und versuche mich Stück für Stück mehr einzubringen.

An welchen Projekten arbeitest Du gerade? Momentan versuche ich verschiedenste Konzepte von Icinga zu verinnerlichen; darunter die DSL oder auch die Verwendung von TLS in unserem Code. Außerdem steht bald wieder ein neuer Release an!

Welche größeren oder besonders interessanten Projekte stehen zukünftig an? Eines der größeren Projekte in näherer Zeit wird es sein, den Icinga Core auf C++11-Standard zu heben. Generell ist die Modernisierung ein Prozess, der niemals abgeschlossen ist, und mich brennend interessiert.

Was macht Dir an Deiner Arbeit am meisten Spaß? Die Freiheiten, die ich bekomme, um mich in Themengebiete reinzuarbeiten, Issues und Probleme zu bewältigen, und einen aktiven Aufbereitungsprozess zu haben. Als Programmierer freut man sich eh über jede kleine Hürde, die genommen wird; sogesehen sind in einer Debugging Session tausende kleine Freudenmomente versteckt.

Was machst Du, wenn Du mal nicht bei NETWAYS bist? Wenn ich mich mal zuhause rumtreiben sollte, widme ich mich dort meinem Klavier und meiner Gitarre. Meistens bin ich aber in allen Ecken und Enden Deutschlands meinen Schabernack treibend zu finden…

Wie geht es in Zukunft bei Dir weiter? Erstmal steht der (hoffentlich gute!) Abschluss meiner Ausbildung als Fachinformatiker in Anwendungsentwicklung an; danach hoffe ich, dass ich mich weiterhin gut und in vielerlei Hinsicht gebildeter und wertvoller in die Firma einbringen kann.

Henrik Triem

Developer

Read more from Henrik and meet the Team

Entwicklerazubis: Jahr 1, das Projekt

by Henrik Triem | Aug 22, 2019 | Datenbanken, Design, Development, HTML / CSS, PHP

Man bekommt nicht immer das, was man will… außer, man ist bei NETWAYS Azubi!

Mein erstes Jahr bei NETWAYS ist fast vorüber, und meine jugendlichen Ambitionen haben den Wunsch in mir erweckt, mit den beiden anderen Dev-Azubis meines Jahres, Loei und Niko, ein eigenes Projekt zu übernehmen, um unsere erlernten Fertigkeiten zu prüfen, eine Übersicht davon zu bekommen, auf welchem Stand wir alle sind, den ein oder anderen Trick voneinander aufzuschnappen und eigenverantwortlich und kooperativ ein Projekt zu vervollständigen. Und alles, was es gebraucht hat, um diesen Wunsch zu erfüllen, war diese Idee zu pitchen und klar und deutlich zu vermitteln, warum dieses Interesse besteht, und was wir uns davon erhoffen. Meine Vorgesetzten scheinen von der Idee zumindest angetan genug gewesen zu sein, dass wir drei Wochen eingeräumt bekommen haben, um uns um dieses Projekt zu kümmern. Danke, NETWAYS!

Die Aufgabe klingt einfach, hat es aber doch durchaus in sich – aus Berichten in Icinga sollen PDFs generiert werden. Die Funktionalität ist schon vorhanden – unsere Aufgabe ist es, den Benutzern mehr Features zur Verfügung zu stellen, damit man eigene Anpassungen an dem Aussehen der PDFs vornehmen kann. Das Schöne an dieser Aufgabe ist die Breite der Elemente und Bereiche, welche eine Rolle dabei spielen. Icingaweb, PHP, HTML, CSS, Google Chrome… es ist in gewisser Art und Weise eine große Reise in das Unbekannte, und natürlich können wir alle drei uns nicht sicher sein, welche Probleme und Hürden sich uns in den Weg stellen werden, und wie die zündenen Ideen kommen, die uns helfen, diese Hürden zu überwinden.

Boo

Much better

Und zündende Ideen gab’ es bereits! Ein Beispiel: Google Chrome baut sich aus HTML-Code die PDFs zusammen, lässt sich es aber nicht nehmen, automatisch generierte Header und Footer anzufügen, mit Seitenzahl und Datum. Das ist natürlich ein Element, welches wir gerne unter Kontrolle hätten! Der erste Hack, mit dem ich mich über diese Hürde bewegt habe, ist ein CSS-Styleelement an den übergeben HTML-Code anzufügen. Das ist in seinem momentanen Zustand natürlich noch etwas unschön gelöst, wenn einfach nur der HTML-Code um ein fest eingebautes Codeelement erweitert wird, aber wir haben einen Einstiegspunkt, einen Ansatz, mit der wir weiterbauen und -basteln können.

Scheue Dich vor Fragen nicht!

Auch wenn der Kerngedanke dieses Projekts natürlich daraus besteht, dass wir uns selbst beweisen, spricht natürlich Nichts dagegen, bei Fragen, die aufkommen, einen der zahlreichen Experten die NETWAYS hat zu involvieren. Was Benutzeroberflächen angeht, ist bei uns UX-Designer Florian der Ansprechpartner Nummer 1. Wir haben uns zusammengesetzt und konnten ihm live beim Bauen eines Mockups in Sketch zusehen. Eine Gelegenheit, durch die großen Augen, die wir gemacht haben, auch etwas über grundlegende Designansätze in Icingaweb zu lernen, und Grundsätze bezüglich Design. Mit diesem Wissen können wir erstmal diesen Pfad weiter selbst beschreiten, aber natürlich werden wir viel Rücksprache führen. Nur weil man bisher nicht dazu kam, sich extensive Kenntnisse in einem Bereich selbst anzueignen, heißt das nicht, dass man dieses Wissen, wenn es einem zur Verfügung steht, nicht nutzen kann. Und immer schön dran denken, selbst den Fundus an Talenten zu erweitern.

A mockup of things to come…

Kooperatives Kodieren

Einer der in meiner Einleitung angesprochenen Tricks, den ich einfach für neat halte, und sehr dem Spirit dieses Projektes entspricht, ist die Möglichkeit in git Co-Authoren einzutragen. Dafür muss man in der commit message einfach

 Co-authored-by: Name <e-mail>

angeben, und git verlinkt automatisch zwei Autoren für diesen commit. In diesem Fall meine beiden Kollegen bei diesem Projekt. Gute Arbeit, Jungs!

Da kann man ruhig mal klatschen! ?

Willst Du uns vielleicht nächstes Jahr bei dem nächsten Entwicklungsprojekt behilflich sein? Dann raus mit Deiner Bewerbung an NETWAYS! Wir freuen uns schon auf dich!

Henrik Triem

Developer

Read more from Henrik and meet the Team

TLS: Eine kleine Übersicht

by Henrik Triem | Jun 6, 2019 | Network, Security

Der durschnittliche Internetbenutzer benutzt TLS (Transport Layer Security) mittlerweile auf fast allen größeren Websiten – ohne, dass sich dieser darüber bewusst wäre, in den allermeisten Fällen. Auch in meiner Ausbildung bei NETWAYS darf ich mich nun intensiv mit TLS beschäftigen. Doch was ist TLS? Dieser Text soll einen groben Umriss um die zugrunde liegenden Prinzipien und Techniken hinter TLS legen.

Warum brauchen wir TLS?

TLS wird benötigt, um drei Probleme zu lösen. Unsere Kommunikationen sollen verschlüsselt sein – wir wollen nicht, dass Pakete oder Informationen, die wir übertragen, abgehört werden. Außerdem wollen wir sicher gehen, dass der andere Teilnehmer dieser Kommunikation auch derjenige ist, mit dem wir diesen Austausch an Informationen vollziehen wollen. Darüber hinaus wäre es auch gut, sich darauf verlassen zu können, dass das, was von der einen Seite losgeschickt wurde, auch das ist, was der andere erhält. Um diese drei Probleme kümmert sich TLS. Doch wie macht es das?

Eine Beispielverbindung:

1. ClientHello

Ein Client verbindet sich mit einem Server und verlangt eine gesichertete Verbindung. Dazu wird die Version von TLS übertragen, und eine Chiffrensammlung, aus denen sich der Server die Verschlüsselungsmethode aussuchen kann.

2. ServerHello & Certificate & ServerKeyExchange

Der Server antwortet, welches Chiffre verwendet werden soll, und einem Zertifikat, welches den Server authentifizieren soll und einen öffentlichen Schlüssel enthält.

3. ClientKeyExchange

Dieses Zertifikat wird von dem Client verifiziert, und der öffentliche Schlüssel des Servers wird vom Client benutzt, um ein pre-master secret zu erstellen, welcher dann wieder an den Server geschickt wird.

Der Server entschlüsselt das pre-master secret, und beide Parteien nutzen es, um einen geheimen, geteilten Schlüssel zu erstellen, welcher als shared secret bezeichnet wird.

4. ChangeCipherSpec

Der Client versendet die erste, mit dem shared secret verschlüsselte Nachricht, welche der Server entschlüsseln soll, damit geprüft werden kann, ob die Verschlüsselung richtig initialisiert wurde. Wenn diese Verifizierung erfolgreich abgelaufen ist, kommunizieren dann der Client und der Server verschlüsselt untereinander. Dieser ganze Prozess wird als TLS-Handshake bezeichnet.

Geschichte: TLS wurde unter dem Vorläufernamen SSL (Secure Sockets Layer) in 1994 von Netscape für den damals sehr populären Browser Mosaic vorgestellt. Version 2.0 und 3.0 folgten jeweils ein Jahr später. 1999 wurde SSL 3.1 bei der Aufnahme als Standart von der Internet Engineering Task Force in TLS 1.0 umbenannt. 2006 folgte Version 1.1, 2008 1.2 und 2018 die heutige Version 1.3.

Asymmetrische & Symmetrische Verschlüsselung: TLS ist zunächst asymmetrisch, dann symmetrisch verschlüsselt. Was bedeutet das? Nun, hier kommen die Schlüsselpaare ins Spiel. TLS benötigt einen öffentlichen und einen privaten Schlüssel. Der öffentliche Schlüssel wird benutzt, damit der Gegenpart einen Vorschlüssel erstellen kann, welcher dann von dem privaten Schlüssel wieder decodiert wird. Das ist eine asymmetrische Verschlüsselung – welche allerdings deutlich kostenintensiver und aufwändiger ist, und sich dementsprechend nicht für die zahlreichen Anwendungsmöglichkeiten für eine TLS-Verbindung eignet. Dank’ dem Vorschlüssel können allerdings beide Seiten des Austausches einen gemeinsamen, geheimen Schlüssel berechnen, mit Hilfe dessen die verschlüsselten Nachrichten auf jeweils beiden Seiten entschlüsselt werden können. Somit ist der Kern von TLS eine symmetrische Verschlüsselung; der Austausch der tatsächlichen Information passiert über diesen Kanal. Um aber an diesen Punkt zu kommen, sind asymmetrische Verschlüsselungsprinzipien im Einsatz.

Zertifikate: Wie in dem TLS-Handshake betrachtet, sind Zertifkate elementar zur Ausweisung und Identifikation von Server und Client – und wohl der kritischste Punkt in dem ganzen TLS-Ablauf. Damit ein Kommunikationspartner identifiziert werden kann, muss er sein Zertifikat ausweisen, welches seine Identiät beweist. Ausgestellt wird ein Zertifikat von einer certificate authority, einem vertrauenswürdigen Aussteller dieser Zertifikate, was verschiedenste Dinge bedeuten kann: Viele multinationale Konzerne stellen kommerziell Zertifikate aus, darunter fallen Firmen wie IdenTrust, Sectigo und DigiCert Group. Es existieren allerdings auch einige non-profit organisations, wie CAcert und Let’s Encrypt, die als Zertifizierungsstelle auftreten. Darüber hinaus gibt es natürlich auch jede Menge Zertifikatsaussteller innerhalb von Netzen, welche in der Hand von einem vertrauenswürdigen Admin liegen.

Chiffrensammlung: Eine Chiffrensammlung ist eine Auflistung aus den Verschlüsselungsmethoden, die bei einer TLS-Verbindung eingesetzt werden können. Beispiele dafür wären RSA, MD5, SHA. Bei einer TLC-Verbindung wird in ClientHello und ServerHello unter den beiden beteiligten Parteien kommuniziert, welche dieser Methoden zur Verfügung für den Aufbau der Verbindung stehen.

https: Doch was hat es nun mit https auf sich? Ganz einfach: https (HyperText Transfer Protocol Secure) ist eine Extension von http, bei der http über eine verschlüsselte TLS-Verbindung versendet wird, was sie im Gegensatz zu Klartext-http vor unerwünschten Abschnorchelungen und sonstigen Attacken schützt.

Verbreitung: Laut der regelmäßig auf einen neuen Stand gebrachten Auswertung von SSL Labs von rund 140.000 Webpages bieten gerade mal 67.2% eine adequate TLS-Ausstattung. Das mag im ersten Moment etwas niedrig erscheinen, man darf aber auch nicht vergessen, dass diese Lage vor nicht allzu langer Zeit noch deutlich, deutlich schlimmer war, und durch Maßnahmen wie einer automatischen Warnung von Chrome verbessert wurde. So hat sich auch laut Firefox Telemetry die Anzahl der per https aufgerufenen Websiten sich von 25% auf 75% erhöht. Ebenso bemerkenswert: Einem Jahr nach Einführung von TLS 1.3 unterstützen gerade mal 15% den aktuellen Standart, der absolut überwiegende Teil bietet noch hauptsächlich TLS 1.2 an. Man darf gespannt sein, wie lange es dauert, bis der Großteil den Wechsel vollzogen hat. Auf der anderen Seite bieten 7.5% der Webpages noch Unterstüztung für SSL 3.0 an, einem Standart, der mittlerweile fast so alt ist wie ich selbst, und als nicht sicher gilt.