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:
Okta Security Incident & Lapsus$ Festnahmen
Anfang der Woche veröffentlichte die Hacker-Gruppierung Lapsus$ auf ihrem Telegram Channel Screenshots und Details über einen Zugriff auf die Backend Systeme des Identity Providers Okta – welcher seine Services für Enterprises und viele Fortune 500 Firmen bereitstellt. Unter anderem seien Screenshots von Microsoft internen Azure DevOps Repositories aufgetaucht.
Okta dementierte den Vorfall zu Beginn, korrigierte dann aber initiale Aussagen. Über einen kompromittierten, externen Supportdienstleister sei der Zugriff in einem Zeitfenster von 5 Tagen im Januar auf ein Teil der Kundendaten möglich gewesen.
Der Okta CISO erklärte den Vorfall in einer Zoom Session, welche Corey Quinn hier auf Twitter kommentierte.
Wie man solche Incidents transparenter und detaillierter seinen Kunden mitteilt, zeigt Cloudflare kurz nach Bekanntgabe des Incidents – die Reaktion von Cloudflare erfolgte prompt, ausführlich und schnell – inklusive Kundenempfehlungen.
Security Research von Microsoft haben den Vorfall und die Historie ebenfalls sehr detailliert untersucht und aufbereitet. Im verlinkten Artikel finden sich diverse Empfehlungen und auch klare „Do NOT“ Hinweise, welche ihr euch gerne mal anschauen solltet. Unter anderem soll man „schwache“ Multi Faktor Möglichkeiten wie SMS, Voice Approval oder auch bequeme Push MFA Techniken deaktivieren. Laut diversen Meldungen habe man in diversen, beobachteten Fällen Mitarbeiter Accounts nachts mit Push Anfragen geflutet, bis diese die Pushs dann einfach angenommen haben (ob nun aus Versehen oder genervt, spielt ja keine Rolle).
Eine Analyse über die Vorgehensweise von Lapsus$ und deren Kern Mitglieder findet ihr im verlinkten Artikel bei Zeit Online. Aktuell scheint noch ein wenig unklar, ob die 7 in Großbritannien festgenommenen Mitglieder der Lapsus$ Gruppe diese Hacks durchgeführt haben oder nicht.
Der Teenager, der Microsoft und Samsung gehackt haben soll
Preiserhöhungen in der Google Cloud
Google Cloud erhöht die Preise für diverse Produkte aus dem Cloud Portfolio. Die Ankündigen im offiziellen Google Blog sind sehr vage – es soll Erhöhungen und Reduzierungen bei Cloud Storage, Cloud Load Balancing, im Network Intelligence Center und bei Cloud Ops Monitoring geben. Ob und wie das Ganze Einfluss auf eure Cloud Kosten hat, hängt von der Implementierung der Produkte ab:
Dazu Sachin Gupta, Vice President Google Cloud Infrastructure:
Will customers‘ bills increase? Decrease? The impact of the pricing changes depends on customers‘ use cases and usage.
Das ist schon spannend, ist man im Cloud Umfeld eigentlich gewohnt, dass die Produkte durch Skalierungseffekte (Economies of Scale) immer günstiger werden.
Entsprechend verwundert äußerten sich Kunden und Berater nun zu den Anpassen, der verlinkte Artikel bei InfoQ hat einige Zitate und Meinungen dazu, beispielsweise von Daniel Compton, von Whimsical:
The pricing changes Google is making strike at the heart of their customer’s applications and will force many customers to re-architect their applications, or pay a much larger amount to keep their existing architecture.
Das beschreibt das Risiko der Nutzung einer Cloud doch ganz gut, man gibt nicht nur Verantwortung ab, sondern auch die Kontrolle und Weiterentwicklung der IaaS/PaaS Komponenten, die man früher ggf. selbst kontrolliert hat.
Corey Quinn widmet in „Google Cloud alters the Deal“ dem Vorgang einen eigenen Artikel und schreibt unter anderem:
Specifically, that if you build something in the cloud it will over time become more stable, more capable, and if the price changes it will be a reduction instead of an increase
Weitere Diskussion bei HackerNews und Reddit.
Was meint ihr? Hat das alles keinen Einfluss? Oder ist dies ein Vertrauensbruch?
Growing Concerns among Developers about Google Cloud Price Increases
OVH: Branduntersuchung offenbart Sicherheitsmängel
Etwas mehr als 1 Jahr ist der Brand bei OVH nun her – am 10. März 2021 hatte das Datacenter SBG2 in der Nähe von Straßburg gebrannt – Details und Links findet ihr in Ausgabe #10 von allesnurgecloud.
Ein kürzlich erschienener Bericht der zuständigen Feuerwehr offenbart eklatante Mängel im Design des RZ und der Möglichkeiten der Brandbekämpfung:
- Es gab keine automatische Feuerlöschanlage
- Nur Hydranten zugänglich – ein als Löschwasser gedachtet See war erstmal nicht zugänglich
- passive Kühlkonzept mit Frischluftzufuhr fungierte als Brandbeschleuniger ähnlich eines FEuerkamins
- die Stromzufuhr war zwar 4-fach abgesichert – ließ sich aber nicht zentral abschalten
Weitere Details und Bilder findet ihr im unten verlinkten Artikel oder hier bei Golem.
180 betroffene Kunden haben sich nun zu einer Sammelklage zusammengeschlossen – OVH selbst arbeitet laut eigenen Angaben noch mit Gutachtern und Anwälten an einer offiziellen Stellungnahme zur Brandursache.
OVHcloud fire report: SBG2 data center had wooden ceilings, no extinguisher, and no power cut-out
Ist Confluence ein Doku Friedhof?
Im Blog von Doctave, einer „Documentation as Code“ Plattform, schreibt der Doctave Gründer Niklas Begley über den „Dokumentations-Friedhof“ in Confluence.
Ihm geht es dabei aber nur um die Dokumentation einer sich ständig weiterentwickelten Software – eine Doku außerhalb des Software-Codes zu pflegen – das mache keinen Sinn. Und hier hat er mich, denn ich glaube ebenfalls, dass eine vom Code extern gepflegte Dokumentation nur schwer aktuell zu halten ist. Software Änderungen, Features und Co – sollten mit dem Code selbst dokumentiert und die Dokumentation hierzu automatisch erzeugt werden – ähnlich wie bei der Dokumentation von APIs.
Das selbe gilt auch für Infrastrukturen, die mit Infrastructure as Code (Terraform, Ansible, etc.) erzeugt werden – auch hier macht eine Dokumentation beim Code selbst total Sinn.
Niklas wird für einen Dokumentatonsstandard – jedes Repo solle ein „High Level Architecture Diagramm“ und eine Historie von Architekturentscheidungen (ADR) enthalten.
Was meint ihr dazu? Dokumentiert ihr mit dem Code? Oder außerhalb?
Confluence Is Where Documentation Goes To Die
Next.js Profiling mit Parca Open-Source
Parca ist eine Open-Source Profiling Software von Polar Signals. Im Blog zeigen die Entwickler nun, wie einfach man mit Parca eine einfache Next.js Applikation mit dem Parca Profiling verbindet.
Parca nutzt eineb eBPF Profiler, welcher 100 mal in der Sekunde samples empfängt und weiterleitet. Somit kommt Parca ohne ein ansonsten nötiges SDK aus. Ihr startet eure Node App einfach mit einem entsprechenden Parameter:
node –perf-basic-prof src/main.js
und schön empfängt die Parca alle calls, die eure Applikation auf dem System ausführt.
Cool finde ich das „Comparison Feature„, welches analog einem git diff einen neuen Codestand zu einem späteren Zeitpunkt B mit dem originalen „problematischen“ Code von Zeitpunkt A vergleicht.
Wie das Ganze ansonsten funktioniert und welche Sprachen aktuell unterstützt werden – siehe FAQ.
Profiling Next.js apps with Parca
Wann braucht man einen „Incident Commander“
Im Blog bei Firehydrant findet ihr eine gute Argumentation für die Schaffung eines „Incident Commanders“ – bei uns hies der früher „Eskalationsmanager“ – in meinen Augen macht dies total Sinn.
Egal wie die Rolle nun heisst, bei größeren Incidents hilft ein dedizierter Eskalationsmanager bei der Stakeholder Kommunikation, Koordination der Incident Response und der Dokumentation des Incidents.
Die Hauptaufgabe in meinen Augen ist, die an der Beseitigung des Incidents direkt beteiligten Admins, DevOps & Entwickler vor direktem Zugriff aus dem Management zu schützen, so dass die Mitarbeiter konzentriert an der Entstörung arbeiten können.
Im Blog Beitrag findet ihr weitere Argumente und verschiedene Formen der Etablierung der Rolle.
Habt ihr einen dedizierten Eskalationsmanager? Wie sind eure Erfahrungen mit dem Thema?
When to hire an Incident Commander
GitHub Issues ausgedruckt
Das Video von Andrew Schemlyun habt ihr bestimmt auf Twitter gesehen?
Im verlinkten Blog Beitrag könnt ihr nachlesen, wie er das ganze gemacht hat: mit einem Epson TM-T88IV (Thermaldrucker), einem Raspberry Pi Zero W und einigen Adaptern. Den PHP Code mit der eigentlichen Funktionalität findet ihr auf GitHub.
Papier ist aktuell ja eigentlich rar und teuer – mal schauen was er damit noch anstellt.
I built a receipt printer for GitHub issues
Log4Shell: Noch immer 30% der aktive Instanzen verwundbar
Laut einer aktuellen Studie von Qualys sind noch immer 30% der von Qualys gescannten Java Instanzen anfällig für den im Dezember veröffentlichten Log4J Exploit Log4Shell. Qualys hat für die Studie Daten von über 150 Millionen IT Assets geprüft und insgesamt über 3 Millionen verwundbare Instanzen gefunden. Im März seien noch immer 30% dieser Instanzen ungepatched gegen Log4Shell.
Auch interessant:
- Über 68.000 verwundbare Cloud Instanzen und Container wurden in den USA und EMEA gefunden
- Im Mittel wurden die meisten öffentlich erreichbaren Systeme nach 12 Tagen gefixed (auch schon lange, oder?)
- Interne Systeme wurden später gefixed (das ist denke ich normal)
- Über 50% der verwundbaren Systeme waren Web Applikationen, die in ihrer Version schon länger „End of Support“ waren
Teilweise finde ich die Zahlen im Report schon etwas erschreckend – und das ist ja nur das, das Qualys sehen kann – d.h. in Summe gibt es da draußen noch viel mehr – hoffentlich nicht meine Bank.
30% of Apache Log4j Security Holes Remain Unpatched
GitLab 14.9 Released
Wie jeden 22. des Monats wurde auch im März eine neue GitLab Version veröffentlich: 14.9.
Darin finden sich mal wieder über 40 Verbesserungen – auf der Release Page gibt es außerdem ein Preview für 14.10.
Highlights in 14.9:
- Epics können nun mit anderen Epics verlinkt werden (Ultimate only)
- Deployment approval auf der „Environments Page (Premium und Ultimate)
- Design der Environment Page überarbeitet (Free & OpenSource)
- Diverse neue API Endpoints: Keys & Tokens, Project Topics Deletion & Security & Compliance Menu
- Shortcut für „Related Issue“ erstellen (Alle Versionen)
- Im WYSIWYS Editor kann man nun Markdown Code per C&P einfügen (Alle Versionen)
- Diverse Updates am Static Analyzer (Alle Versionen)
- Kubernetes Cluster können nun aus GitLab mit Terraform gebaut werden (Alle Versionen!)
GitLab selbst kündigt auf GitLab.com prominent die Entfernung diverser „Deprecated“ Features für GitLab 15.0 an – einige Deprecations sind „Breaking Changes“, daher solltet ihr mal ein Auge drauf werfen. GitLab 15.0 soll am 22.05.2022 erscheinen.
GitLab 14.9 released with epic to epic linking and integrated security training
Schmunzelecke
Pendelst du schon oder bist du noch remote? – Thanks Manfred.
💡 Link Tipps aus der Open Source Welt
PagerBeauty – PagerDuty Dashboard für Grafana & Datadog
PagerBeauty ist ein einfaches Widget für Grafana und Datadog Dashboard, welches den aktuellen OnCall Mitarbeiter auf dem Dashboard anzeigt. Zusätzlich kann es aktuell in PagerDuty eskalierte & zugewiesene Incidents anzeigen.
Wie das Ganze dann aussieht, könnt ihr euch hier und da anschauen.
https://github.com/sergiitk/pagerbeauty
Penpot – OpenSource Design & Prototyping
Penpot ist eine OpenSource Design & Prototyping platform – ein wenig eine abgespeckte, aber freie Alternative zu Figma & Co.
Ihr könnt Penpot einfach online ausprobieren oder via Docker-Compose lokal oder auf einem Server installieren.
Penpot war im Februar 2021 auf Product Hunt – hier könnt ihr ein Video und die Kommentare dazu anschauen.
https://github.com/penpot/penpot
Karma – Dashboard für Prometheus Alertmanager
Mit Karma könnt ihr Prometheus Alarme gruppieren und deduplizieren. Zusätzlich bekommt ihr eine bessere Übersicht über „vererbte“ Alerts, beispielsweise wenn ein ganzen Cluster down ist und die darauf befindlichen Systeme eben nicht mehr laufen.
Am Besten schaut ihr mal die Online-Demo an, dann versteht ihr besser, wie das System den Alertmanager erweitern kann.
https://github.com/prymitive/karma
❓ 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: