allesnurgecloud.com ist ein kuratierter Newsletter mit Inhalten aus der Open-Source, Cloud und IT-Welt.
Für weiteren Content folge mir gerne auf Twitter, Mastodon oder LinkedIn.

Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren:

547 Abonnenten sind schon dabei - Vielen Dank!

Please enter a valid email address

Diese E-Mail ist bereits registriert.

The security code entered was incorrect

Vielen Dank für Deine Anmeldung - bitte den Opt-In bestätigen.

Remote Work Status in 2023

Bereits zum 6. Mal haben die 3 „Remote“ Firmen Buffer, Nomad List und Remote OK eine Umfrage um aktuellen Status von „Remote Work“ durchgeführt. Über 3000 Remote Arbeitenden wurden hierzu befragt, 82 % der befragten Arbeiten von zu Hause aus (2022 waren dies noch 59 Prozent).

1. Remote Work wird weiterhin sehr positiv wahrgenommen
   98 % der Teilnehmer möchten für den Rest Ihrer Karriere Remote arbeiten
   Weitere 98 % würden Remote Arbeit weiterempfehlen
2. Remote Arbeiter wollen kein hybrides Setup
   71 % der Befragten bevorzugen ein Remote-only Setup.
   20 % entscheiden sich für Hybrid, aber mit Fokus auf remote-first
   6 % wollen Remote und Hybrid im Wechsel
   2 % wollen Hybrid, aber Office-first
   nur 1 % will zurück ins Büro
3. Flexibilität ist größter Remote Benefit
   22 % der Befragten gaben an, dass Flexibilität das größte Plus von Remote sei
   19 % gaben als Hauptgrund Flexibilität des Wohnortes als Grund für Remote an
   13 % möchten die Flexibilität des Arbeitsortes
4. Remote Mitarbeiter sind einsam
   Vielen gaben an, dass sie zu Hause bleiben, weil sie einfach keinen Grund haben, wohin zugehen?
   Für 23 % der Befragten ist Einsamkeit grundsätzlich ein Problem und für 15 % das Top-Problem der Remote Arbeit
5. Grenzen sind wichtig – schwierig sei jedoch, sie einzuhalten
   71 % gaben an, dass sie „Grenzen“ von Office und Home wichtig finden, die wenigsten seien aber in der Umsetzung erfolgreich
6. Remote Karriere ist einfacher?
   Im Vergleich zu vorherigen Umfragen gaben 36 Prozent an, dass man leichter die Karriereleiter erklimmen könnte (früher nur 14 Prozent) – gleichzeitig empfanden bloß noch 28 Prozent die Remote-Karriere schwieriger (vorher 45 %)
7. Remote Arbeiter fühlen sich verbunden
   75 % der Befragten gaben an, dass sie sich, trotz Zeitzonen übergreifender Zusammenarbeit, mehr mit Ihren Kollegen verbunden fühlen.

Da sind jetzt ein paar überraschende Themen dabei – und ich bin mir auch nicht sicher, ob das so zusammenpasst.
Die kompletten Ergebnisse der Umfrage findest du hier – inklusive Links zu vorherigen Umfragen.
Bei Amazon hat man die Umfrage wohl nicht gelesen, bzw. sie kam zu spät. Amazon CEO Andy Jassy hat die Mitarbeiter zum 1.3. zurück ins Büro geordert. Das kam bei der Belegschaft nicht so gut an, innerhalb kürzester Zeit sammelten sich über 16.000 Mitglieder in einer Slack Gruppe, die in einer Petition die Rücknahme der Ankündigung forderten.

State Of Remote Work 2023

37signals veröffentlicht MRSK für Container Orchestrierung

Bei Basecamp/37signals geht es nun doch Schlag auf Schlag – viel schneller als gedacht veröffentlichte man in dieser Woche eine leichtgewichtige Software für die Container Orchestrierung auf bare-metal Servern oder VMs.
Die Software heißt MRSK und hat eine ganz schicke Homepage – na, ich halt es für jedenfalls lustig.
Das Ganze sollt dem Exit aus der Cloud dienen und Basecamp in den nächsten Jahren über 7 Millionen Dollar einsparen.
Was ist nun MRSK?

MRSK deploys web apps anywhere from bare metal to cloud VMs using Docker with zero downtime. It uses the dynamic reverse-proxy Traefik to hold requests while the new application container is started and the old one is stopped. It works seamlessly across multiple hosts, using SSHKit to execute commands.

MRSK ist also ein Deployment tool, welches Zero-Downtime Deployments durchführt.
Zusätzlich kann MRSK jetzt schon folgende Dinge:

• .env File Handling, beispielsweise via 1Password oder Bitwarden
• Mit Hostgruppen und Container Labels umgehen
• Images auf Remote Hosts bauen
• Mit accessories umgehen – für Datenbanken, Caches, Such-Engines und mehr.
• Cron Commands verwalten
• Status von Containern anschauen
• Rollbacks ausführen
• uvm.

Das sieht schon nicht schlecht aus – eine Mischung aus Waypoint und Nomad – aber halt ein Stück einfacher gedacht.
DHH hat dazu ein „Introduction Video“ auf YouTube erstellt (20:27) – da sieht man auch, wie er mit der CLI arbeitet, wie man sich die Logs anschauen kann, etc.
Die einzige Voraussetzung für den Betrieb ist eine Docker Engine auf einem Server.
Anwendungen lassen sich so auch Cloud-übergreifend einfach realisieren – natürlich braucht man trotzdem irgendwo eine Datenbank.

Einige Tage zuvor hatte er dem Cloud-Abgesang nochmals ein Kapitel hinzugefügt. In „Don’t be fooled by serverless“ rechnet er recht einfach vor, warum die Cloud-Anbieter das Thema so sehr hypen: Man könne damit noch viel mehr über-provisionieren als schon mit VMs.
MRSK soll jedenfalls zum Ende des Sommers eine stabile Version 1.0 bekommen – zu dem Zeitpunkt will 37signals/Basecamp dann bereits diverse Applikationen aus der Cloud migriert haben.
Spannende Entwicklung und mal sehen, was hier noch alles kommt. Datenbanken und andere Services verlässlich HA zu betreiben, ist nochmals ein anderes Thema als stateless Workload.

MRSK: Deploy web apps anywhere

Technische Schulden kontrolliert beheben

Wie du sicher weisst, finde ich das Thema „Technische Schulden“ recht spannend.
Der verlinkte Artikel beschreibt in der Herleitung schön, was die Probleme bei „gewachsenen Applikationen“ seien können und wie sich diese in der Praxis auswirken:

1. Steigende Fehlerrate: Die „MTBF“ (Mean Time between failures) steigt an und man bearbeitet immer mehr Incidents
2. Steigende Implementierungszeiten: die Lead Time, die zur Auslieferung neuer Features benötigte Zeit, steigt immer weiter an
3. Sinkende Effizienz – Die Effizienz sinkt
4. Steigende Lösungszeiten: Die TTR (Time to Repair) steigt immer weiter an
5. Steigende Zeit bis zum ersten Commit: Das Onboarding neuer Mitarbeiter:innen dauert immer länger – die Zeit bis zum ersten Commit steigt.

Dies kann alles diverse Gründe haben – um die darunterliegenden Probleme zu begegnen, benötigt es einen Prozess, um die „technischen Schulden“ kontrolliert zu beheben.
Im verlinkten Beispiel hat das Team um Alex Ewerlöf sich folgende Policy ausgedacht:

• 10 % der Developer Zeit wird an der Behebung der technischen Schuld gearbeitet
• Technische Schulden sollen zuallererst vermieden werden (einfacher als gesagt)
• ein PR, welcher wissentlich technische Schulden erzeugt, muss gleich mit einem Issue zur Behebung der technischen Schuld verlinkt werden
• Alle Tickets/issues erhalten das gleiche Label – beispielsweise „tech-debt“
• Es wird gemeinsam an der Behebung der technischen Schulden gearbeitet – an dem bestimmten Tag soll es keine Meetings geben
• Erfolge zur Behebung der technischen Schulden werden am Demo Day gezeigt

Interessant im Artikel finde ich diesen Teil:

Having to regularly deal with the debt made us more conscious not to create it in the first place. That way, we would spend the Tech Debt Friday on more meaningful work like improving our tests, linting or CI/CD pipeline to prevent errors or make them cheaper.

Das spricht dafür, dass man durch den Prozess immer besser in der Behebung und in der Vermeidung von technischen Schulden wird. Auch interessant fand ich, dass durch die gemeinsame Behebung der technischen Schuld das gegenseitige Verständnis des Codes immer besser wurde – und alleine dadurch die Effizienz bei neuen Features gestiegen ist.

We invested 10% to pay back tech debt; Here’s what happened

Einbruch bei LastPass über DevOps Home PC

Zum LastPass Security Incident aus dem Oktober letzten Jahres gibt es nun ein ausführliches Update bei LastPass.
Im Prinzip waren es sogar 2 Incidents, die jetzt auch separat kommuniziert werden.

Im Incident Nummer eins wurde ein Laptop eines Software Engineers kompromittiert. Angreifer erlangten dadurch Zugriff auf das Cloud-basierte Development System, konnten Source erbeuten und vor allem Informationen über die internen Systeme von LastPass. Die Details zum ersten Incident kannst du hier nachlesen.
Die in Incident 1 erbeuteten Informationen wurden dann für einen weiteren, gezielteren Angriff genutzt.
Einer von 4 Senior DevOps Engineers, mit Zugriff auf den Master Key zum Entschlüsseln der in verschlüsselten Cloud Storage abgelegten Daten, wurde Ziel eines ausgeklügelten Angriffs – natürlich mit dem Ziel, den Key zu extrahieren.
Man installierte einen Key Logger auf dem privaten Rechner des Mitarbeiters, und konnte so auf den Corporate Passwort und Secret Speicher von LastPass zugreifen:

This was accomplished by targeting the DevOps engineer’s home computer and exploiting a vulnerable third-party media software package, which enabled remote code execution capability and allowed the threat actor to implant keylogger malware. The threat actor was able to capture the employee’s master password as it was entered, after the employee authenticated with MFA, and gain access to the DevOps engineer’s LastPass corporate vault.

Der Angriff erfolgte wie beschrieben im privaten Netzwerk über ein Media Package mit Remote Code Lücke – Nachteil von Remote Work? Warum darf der Kollege auch mit dem privaten Rechner zugreifen? Kann natürlich auch mit dem Firmenrechner passieren.
LastPass hat diverse, zusätzliche Sicherheitsmechanismen eingebaut, damit so etwas in Zukunft nicht mehr passiert.
Die Details der zweiten Attacke kannst du in diesem Artikel nachlesen.
Bei beiden Angriffen wurde LastPass von den Security-Spezialisten von Mandiant unterstützt. Mandiant wurde vor ziemlich genau einem Jahr von Google übernommen und gehört heute organisatorisch zur Google Cloud.
LastPass kann man zu diesem Incident vieles vorwerfen – die Transparenz ist jedenfalls einmalig, bedenkt man die Kritikalität der Thematik.

Security Incident Update and Recommended Actions

Kubernetes: Freeze der Legacy Container Registry

Nicht nur PHP und Ubuntu gehen mal EoL, auch so eine Container Registry kann mal EoL gehen.
Warum?
Die frühere Registry k8s.gcr.io ist eine nur in einer Google Region betriebe Registry, welche nun – dank erneutem Sponsoring von Google und neuem AWS Sponsoring – auf mehrere Clouds verteilt wird und grundsätzlich schnellere Downloads in der Nähe der Workload ermöglicht.
Jedenfalls wird k8s.gcr.io zum 3. April 2023 eingefroren – und erhält vorerst keine Updates und keine neuen Versionen mehr.
Was kannst du tun?
Einfach die alte Registry (k8s.gcr.io) durch die neue Domain registry.k8s.io ersetzen und fertig.

k8s.gcr.io Image Registry Will Be Frozen From the 3rd of April 2023

Macbook M1 Air mit Thinkpad t480 ersetzen

Max Rozen, Entwickler bei Cloudflare, hat einen interessanten Artikel zu seinem neuen Laptop geschrieben. Er war etwas genervt von seinem 2020er-MacBook Air M1 und hat dies durch ein Thinkpad t480 ersetzt.
Kommt nun doch das Jahr von Linux auf dem Desktop?
Na jedenfalls musste erst mal das Display getauscht werden – und der Akku. Naja, das t480 ist ja auch schon paar Jahre alt – es ist dafür aber günstig zu haben.
Jedenfalls hat Max Pop!_OS 22.04 am Start – eine auf Ubuntu-Linux basierte Distribution. Als Oberfläche kommt die modifizierte Gnome Variante COSMIC zum Einsatz – schau dir einfach die Screenshots hier an. Das Ganze erinnert ein wenig an MacOS.
Max wollte ein günstiges Gerät, welches er mit auf Reisen nehmen kann – und eine ähnliche Performance bietet, wie sein Macbook M1. Ja, so ganz kommt die Performance nicht ran, aber ihm reicht es scheinbar.
Dass es für das Gerät dann ein „Hardware Maintenance Manual“ gibt, sowie ifixit guides – das ist halt genau das Gegenteil von Apples geschlossenem Ökosystem.
Das Thema wurde bei HackerNews dann in über 600 Kommentaren diskutiert bzw. angereichert – da gibt es auch noch diverse Tipps für günstigere Apple Alternativen.

On replacing my MacBook Air M1 with a Thinkpad T480

OnlineShop Software mit Sicherheitslücken

Das BSI hat in einer Studie diverse Online-Shop Software auf Sicherheitslücken untersucht.
Für die Studie wurden zuerst Bundesbürger in einer Umfrage befragt:

• Über 90 % aller Befragten kaufen Online ein
• 55 % davon einmal im Monat oder häufiger
• 80 % nutzen davon das Smartphone, 60 % auch mal den Laptop, 40 % auch ein Tablet
• Über 90 % der 15-39-jährigen nutzen das Smartphone
• 61 % haben Bedenken bezüglich der Weitergabe persönlicher Informationen
• 81 % wünschen sich ein unabhängiges Siegel von dritter Stelle, welches die Sicherheit von Online-Shops bewertet.

Zusätzlich hat man sich aus einer Liste 10 Online-Shop Software Anbieter für eine Schwachstellenanalyse herausgersucht. Unter den Anbietern beispielsweise: Shopware, Sylius, wpShopGermany, Magento, PrestaShop, Gambio und Weitere.
Bei einer Software wurden nur 2 aktive Schwachstellen gefunden, bei einer anderen Software sogar 17 – die Anbieter werden hier im Detail nicht genannt. Insgesamt hat man 78 Schwachstellen gefunden und die Hersteller entsprechend informiert.
Die meisten Schwachstellen waren mit CVSS „medium“ bewertet – 4 Stück mit HIGH und 10 mit CRITICAL.
Die Hälfte der CRITICALs war auf den Einsatz von EOL Software zurückzuführen.
Schwachstellen-Scanner haben bestimmt viele der Anbieter im Einsatz – beheben muss man die Findings halt trotzdem noch selbst.

BSI-Studie: Viele massive Sicherheitslücken bei Online-Shops

Schmunzelecke

DOOM auf einem Multi-Monitor Setup? Ja, das geht – mit insgesamt 4 Monitoren.
Hier kommst du direkt zum Ergebnis bei ca. 30:15.

💡 Link Tipps aus der Open Source Welt

Open Source Vulnerability Scanner von Google

Google hat zu „distributed vulnerability database for Open Source“ osv.dev einen CLI Scanner veröffentlicht, welcher ein offiziell supportetes Frontend für die Datenbank darstellt.
Falls du die DB nicht kennst, sie enthält unter anderem „machine und human readable“ CSVs in einem Standardformat für:

• Alpine
• Debian
• Linux
• Go
• NPM
• Packagist
• PyPi
• RubyGems
• Android
• Maven

und weitere Repositories.
Den Scanner gibt es schon seit dem 13. Dezember und ich hatte das Announcement dazu irgendwie verpasst.

https://github.com/google/osv-scanner

Clack – Typescript CLI Anwendungen

Mit Clack kannst du einfach und schnell schöne CLI Anwendungen und Prompts in deine Applikationen einbauen.
Wie das Ganze funktioniert, kannst du interaktiv auf der Clack Homepage ausprobieren.

https://github.com/natemoo-re/clack

❓ Feedback & Newsletter Abo

Vielen Dank, dass du es bis hierhin geschafft hast!
Kommentiere gerne oder schicke mir Inhalte, die du passend findest.

Falls dir die Inhalte gefallen haben, kannst du mir gerne auf Twitter folgen.
Gerne kannst du mir ein Bier ausgeben oder mal auf meiner Wunschliste vorbeischauen – Danke!

Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren:

547 Abonnenten sind schon dabei - Vielen Dank!

Please enter a valid email address

Diese E-Mail ist bereits registriert.

The security code entered was incorrect

Vielen Dank für Deine Anmeldung - bitte den Opt-In bestätigen.