Supply Chain Security spielt auch im Container Umfeld eine immer wichtigere Rolle. Es gilt dabei die Sicherheit im Sinne von Echtheit und Integrität der (Docker) Images abzusichern.
Typische Supply Chain Angriffsszenarien bei Kubernetes, Docker...

Dokumentation ist ein Thema, dass gerne hinten angestellt wird.
Quasi "wenn noch Zeit ist". Vergleichbar mit Tests wird Dokumentation von manchen Personen als schlecht investierte Zeit angesehen. Erschwerend kommt hinzu, dass die Pflege aufwendig ist: Wird die Software weiterentwickelt, so müssen oft auch Tests und Dokumentation nachgezogen werden.

Wir haben gute Erfahrungen damit gemacht, Dokumentation - wo möglich - zu generieren. Dabei kann sowohl der Java Quellcode als Quelle dienen, als auch Ergebnisse von automatisiert ausgeführten Tests.
Auf diese Weise kann die Dokumentation nah am Quellcode mitgepflegt werden, die Wahrscheinlichkeit sinkt, dass dies nicht bedacht oder vergessen wird.

In diesem Beitrag geht es darum, auch die Dokumentation der verwendeten Datenbankschemata zu dokumentieren. Dazu werden die Werkzeuge Testcontainers, Schemacrawler und JUnit miteinander verknüpft.

Container Image sind dank OCI Standard und Verbreitung von Docker und Kubernetes zu dem Mittel der Wahl geworden, um Anwendungen zu verteilen. Dabei verwenden Container Runtimes wie Docker ein geschicktes Verfahren zur Deduplizierung von Daten: Ein Container Image ist in Layer aufgeteilt und diese können unabhängig voneinander verteilt und gespeichert werden.
Da die Layer selbst nicht veränderlich sind, können Layer wiederverwendet werden.

Typischerweise finden sich auch viele Gemeinsamkeiten: Die verwendete Basisdistribution, Laufzeitumgebungen wie Python oder Java und ggf. auch firmenspezifische Konfigurationen wie TLS Zertifikate.

Dabei muss ein Tradeoff beachtet werden: Je mehr Layer, desto mehr Overhead entsteht durch sie. Gleichzeitig ist es um so wahrscheinlicher, dass bei feingranularen Image Layern eine gute Wiederverwendbarkeit ermöglicht wird.

Bei der Auswahl von Base-Images, auf die eigene Anwendungsimages aufgebaut werden sollen, gilt es also darauf zu achten, dass diese möglichst geschickt augeteilt sind und nicht nur aus einem Layer bestehen, der stets vollständig neu geladen und gespeichert werden muss, wenn es Aktualisierungen gibt, aber auch nicht aus zehn oder mehr Layern.

Zur Bestimmung der Anzahl der Layer gibt es verschiedene Ansätze. Am Beispiel eines Java Basisimages, openjdk, werden diese im folgenden betrachtet.

Durch CSP Header (Content Security Policy) lassen sich verschiedene Funktionen des Webbrowsers konfigurieren, um das Verhalten von Nachladen und auch Ausführen zusätzlicher oder dynamischer Inhalte zu beeinflussen. Damit lassen sich typische Einfallstore für Angriffe wie Cross-Site-Scripting (XSS) wirksam abstellen.
Ist die Webanwendung jedoch eine Single Page Anwendung (SPA) und auf dynamische Erzeugung von Inhalten angewiesen, führt eine globale Deaktivierung der Dynamik dazu, dass die Anwendung nicht mehr funktioniert. Es stellt sich daher die Frage, wie zwischen guten und potentiell schädlichen externen und dynamischen Inhalten unterschieden werden kann.

Dazu ist in allen Browsern inzwischen ein Verfahren implementiert, mit dem Entwickler solche Inhalte, die erwünscht sind, expliziert markieren können: sogenannte "Nonce" Markierungen. Aktuelle Frameworks, so auch Angular, bringen dazu auch speziellen Support mit.
Die Implementierung wird in diesem Beitrag anhand von nginx gezeigt.

Container Images sind inzwischen etabliert, um darüber Anwendungen bereitzustellen. Durch das standardisierte Format, einheitliche Schnittstellen und das insgesamt bestehende Ökosystem wird es sehr einfach, Artefakte zu konsumieren und auch bereitzustellen. Jedoch hat das auch Konsequenzen: Die Verantwortung für Patchmanagement, Fehlerbehebungen und Security-Updates verschiebt sich zum Anbieter der jeweiligen Images, da diese mehr, als lediglich die Anwendung selbst beinhalten. Gleichzeitig obligt es dem Konsumenten bzw. Nutzer der Images, sicherzustellen, dass diese aus einer vertrauenswürdigen Quelle stammen und auch nicht zwischendurch verändert wurden.
Diese Aspekte der "Supply-Chain-Security", einem Unterbereich der IT-Sicherheit im Kontext von Containeranwendungen wollen wir uns in diesem und folgenden Artikel widmen.

Für Product Owner, Entwickler und weitere Stakeholder können Bildschirmaufnahmen hilfreich sein, um schnell und einfach einen Einblick in den Entwicklungsstand einer Webanwendung zu erlagen. In diesem Post berichte ich von meinen Erfahrungen, einen Prozess aufzusetzen, um in einer Build-Pipeline automatisch Videos und Screenshots einer Anwendung aufzunehmen und diese bereitzustellen. Realisiert habe ich dieses Vorhaben sowohl mit Playwright als auch mit Puppeteer.

Im Beitrag Crossplane Tutorial wurde Crossplane als Werkzeug zur Infrastrukturautomatisierung vorgestellt. In diesem Beitrag wird der Einsatz von Crossplane für die Hetzner Cloud gezeigt. Dabei wird auch betrachtet, wie neue Provider für Crossplane durch Wiederverwendung bestehender Terraform Plugins bereitgestellt werden können.

Heutzutage ist es wichtiger denn je, dass Anwendungen auf verschiedenen Architekturen und Plattformen reibungslos funktionieren. Man denke z.B. an den erfolgreichen Schwenk von Apple auf die ARM-Plattform und die Kosteneffizienz, die ARM auch...

Im DevOps Kontext haben sich über die Zeit verschiedene Werkzeuge entwickelt:
Waren Puppet und Chef noch frühe Vertreter mit unterschiedlichen Paradigmen (deklarativ vs. imperativ) verwendeten doch beide einen Agent. Ansible setzte sich weitgehend als imperative Lösung ohne Agent für die Provisionierung von Systemen durch, während Terraform als Infrastruktur- und Cloudwerkzeug de-factor Standard wurde.
Sowohl Ansible als auch Puppet setzen auf eine Konfiguration, die nahe an typischen Datenformaten von APIs sind (YAML bzw. JSON).

In diesem Beitrag soll es um ein neuartiges Werkzeug gehen, dass den deklarativen Ansatz verfolgt, jedoch die Kubernetes API als Schnittstelle verwendet. Crossplane geht damit einen spannenden Weg und erlaubt es, bestehende Verfahren zur Authentifizierung und Autorisierung weiter zu nutzen und sich dank zahlreicher Kubernetes Libraries auch einfach an eigene oder bestehende Anwendungen zu integrieren. Dies ermöglicht eine konsistente Verwaltung von (Cloud-)Ressourcen und Kubernetes-Workloads. Crossplane bietet somit eine engere Integration zwischen Anwendungen und Infrastruktur, was die Automatisierung und das Management vereinfacht.

Dies wird dank der erweiterbaren API von Kubernetes möglch: Alle Crossplane Ressourcen sind Custom Resource Definitions (CRDs) in Kubernetes. Die Erweiterung von Crossplane ist durch die erweiterbare API von Kubernetes ebenfalls gegeben, so können sogenannte Provider nachgerüstet werden. Dazu können vorhandene Kubernetes Konzepte wie ConfigMaps oder Secrets verwendet werden.

Aus diesem Ansatz ergeben sich folgende Vorteile von Crossplane:

Crossplane benötigt jedoch einen Kubernetes API Server als Basisinfrastruktur. Im folgenden schauen wir uns die Installation und Verwendung von Crossplane genauer an.

Supply Chain Security ist ein wichtiges Thema. Dabei stehen Container Images zunehmend im Fokus, und das auch nicht ganz zu Unrecht: Bei vielen Kunden erleben wir, dass Zulieferer zwar "Docker Image" als Auslieferungsformat vereinbaren, gleichzeitig jedoch keine Updatevereinbarungen jenseits der eigentlichen Software getroffen werden.
Das ist angesichts der bei Docker Images immens vergrößerten Verantwortung - das Basis-Image gehört ja mit zur Auslieferung - zu wenig.
Durch den zunehmenden Einsatz von Kubernetes finden Container Images auch Einzug in Bereichen, die bisher wenig Erfahrung mit Patchmanagement und Security Prozessen haben. Kubernetes selbst sowie der Betrieb der Umsysteme, wie einer Container Registry, stellen für sich dabei oft schon Herausforderungen dar.

Als Nutzer von Images ist ein Weg, wenigstens etwas Übersicht über die als "Blackbox" betrachteten Images und jeweiligen Abhängigkeiten und transitiven Abhängigkeiten zu gewinnen, mit Image Scanning zu arbeiten.

Im vorherigen Artikel PostgreSQL in Kubernetes und OpenShift wurden die Grundlagen zum Betrieb von PostgreSQL in Containern und Kubernetes vorgestellt. Als ein Option wurde in diesem Beitrag erklärt, wie PostgreSQL mit Helm in Kubernetes betrieben werden kann.
In diesem Beitrag geh es darum, wie das Kubernetes Operator Konzept den Betrieb erleichtern kann und einige prominente Vertreter von Kubernetes Operators zu vergleichen.

Unsere Docker-Schulungen werden in der letzten Zeit sehr häufig angefragt. Damit ist zumeist Docker unter Linux gemeint, also native Linux-Container auf nativen Linux-Systemen. So weit so klar.

Mit dieser Klarheit ist es allerdings schnell...