Heimdalls Bewerbung bei der CNCF

Anja Kammer: Hallo und herzlich willkommen zum INNOQ Podcast. Mein Name ist Anja Kammer und heute spreche ich mit Dimitrij Drus über sein Open Source Projekt Heimdall. Hallo Dimitrij.

Dimitrij Drus: Hallo Anja. Freue mich hier zu sein.

Anja Kammer: Stell dich doch bitte einmal kurz vor.

Dimitrij Drus: Ja, ich bin Dimitrij Drus, wie Anja schon gesagt hat. Bin seit mittlerweile sechs Jahren bei der INNOQ und beschäftige mich primär mit Sicherheitsthemen in Projekten von unseren Kunden. Also alles, was irgendwie im Kontext der Entwicklung anfällt.

Anja Kammer: Du bist sozusagen Consultant für Entwicklungsteams auch?

Dimitrij Drus: Im Prinzip schon. Die Rollen, die ich in Projekten primär einnehme, sind dann halt Security Architecture bzw. als Security Architekt und unterstütze die Teams bei solchen Aspekten wie Threat Modelling, bei der entsprechenden Technologieauswahl, bei der Integration der entsprechenden sicherheitsrelevanten Aspekte in ihre Services, in das, was sie machen. Wie könnten sie das einfach gestalten und gleichzeitig auch sicherer? So eine Art Enablement-Rolle, wenn du so magst.

Anja Kammer: Wir sprechen ja heute darüber, welche Erfahrungen du gemacht hast bei der Entwicklung deines Open Source Projekt Heimdall. Magst du einmal Heimdall kurz vorstellen?

Dimitrij Drus: Im Prinzip kann man das sich als eine Art Proxy vorstellen, wobei Proxy vielleicht der falsche Begriff wäre. Denn es gibt zwei Betriebsmodi. Man kann das wirklich als einen reinen Proxy betreiben und man kann das auch als Plugin für vorhandene Infrastruktur, also für vorhandene Proxys nutzen. Im Endeffekt wird man dann so ein vorhandener Proxy, wie zum Beispiel seinen Traffic Ingress Controller in seinem Kubernetes Cluster in ein API-Gateway verwandeln. Und das ist letztendlich auch die Aufgabe von Heimdall an der Stelle. Und zwar Authentifizierungs- und Autorisierungsaspekte zu vereinfachen. Es geht nicht darum, dass Heimdall das alles übernimmt, sondern es geht darum, die vorhandenen Systeme zu orchestrieren, wenn man so möchte. Integration vorhandener Systeme, um gleichzeitig die Entwickler in diesem Zusammenhang zu entlasten. So viele Defaults wie möglich zur Verfügung zu stellen und so wenig Konfiguration wie es nur geht, zu enforcen, damit die Entwickler vielleicht im Best Case eigentlich gar nichts mehr damit zu tun haben, aber deren Endpunkte, deren Services dann aus der Perspektive Authentifizierung und Autorisierung abgesichert sind. Das ist das, was Heimdall so macht.

Anja Kammer: Ich kann mich auf jeden Fall noch an ein Projekt erinnern. Da hatten wir mehrere Proxys zu stehen für unterschiedliche Authentifizierungsmethoden und ich weiß, dass Heimdall dieses Problem lösen könnte.

Dimitrij Drus: Definitiv, definitiv. Das kann man sicher auch als eine Art Abstraktionslayer vorstellen, weil egal was sich vorne abspielt. Vorne im Sinne, welche Protokolle für die Authentifizierung verwendet wird oder auch welches System für die Autorisierung verwendet wird. Hinten haben die entsprechenden Services immer eine stabile Repräsentation und müssen sich gar nicht mehr damit auseinandersetzen, welche Protokolle vorne gefahren werden.

Anja Kammer: Ich möchte noch einen kleinen Spoiler jetzt schon verraten. Bzw. eine kleine Sache jetzt schon verraten. Du hast nämlich Heimdall als Sandbox-Projekt eingereicht bei der Cloud Native Computing Foundation, der CNCF, und wir werden im Gespräch noch mal darauf zurückkommen. Aber so einen kleinen Spoiler möchte ich schon mal jetzt hier platzieren. Wie bist du denn auf die Idee für Heimdall gekommen? Gab es einen bestimmten Grund, ein bestimmtes Projekt, wo es zu viele Probleme gab und du das lösen wolltest?

Dimitrij Drus: Ich habe eingangs gesagt, dass ich primär als Security Architekt in Projekten unterwegs bin. Und ich habe in, keine Ahnung wie viel Jahren, schon kein einziges Projekt gesehen, wo das Themengebiet was Heimdall adressiert, nicht ein Problem in den jeweiligen Setups bei den Kunden war oder ist. Die meisten Entwickler wollen damit (gemeint is Authentifizierung und Autorisierung) gar nichts zu tun haben. Sie sagen: “Geh weg mit deiner Konfiguration. Ich möchte es gar nicht sehen.” Es muss einfach da sein und funktionieren. Sowas im Sinne von Commodity. Und obwohl Authentifizierung eigentlich im Sinne von Protokollen, ob OpenID Connect und Ähnliches eigentlich gelöst ist, ist die Integration bei weitem nicht wirklich gelöst. Es gibt Proxys spezieller Natur, wie zum Beispiel den OAuth2-Proxy, aber sie lösen nur einen einzigen Aspekt. Und den Rest muss man irgendwie selbst umsetzen. Und das führt zu Custom-Lösungen, die teilweise funktionieren, teilweise aber nicht. Die zusätzlichen Kräfte binden und Zeit kosten und natürlich auch den Time-to-Market sehr stark beeinflussen, geschweige denn später die ganze Maintenance. Und im Endeffekt sehe ich immer wieder Trends im Kontext von zunehmendem Einsatz von APIs oder Trends im Sinne von Zero Trust Security - Fragmentierung von Identitätslösungen. Das begegnet mir immer wieder in Projekten. Und das ist eine sehr große Challenge. Und das hat mich letztendlich zu der Entwicklung von Heimdall geführt. Ausschlaggebend war vielleicht ein Projekt, in dem wir mal beide zusammen waren bei einem größeren Kunden. Der Kunde wollte, ich meine, die sind immer noch dabei, von einem größeren CIAM, also Customer Identity Access Management System, das zu dem Zeitpunkt als Monolith gestaltet worden war, weggehen, und zwar in so eine Art Microservice-Landschaft für einen ein neues CIAM-System. Und das bedeutet, wir mussten zusehen, dass entsprechende Möglichkeiten geschaffen werden. Und eine der Möglichkeiten, aus meiner Sicht unumgänglich, war diese Abstraktion von unterschiedlichen Authentifizierungsprotokollen, wie zum Beispiel X.509 Zertifikat-basierte und OpenID Connect-basierte, aber auch Integration von verschiedenen oder mehreren Identity Providern. Also beispielsweise ein Identity Provider für kundenspezifische Funktionalität und ein Identity Provider für Backoffice-spezifische Funktionalität. Dafür gibt es eigentlich keine Frameworks, die das gemeinsam abbilden können. Und das muss man dann händisch alles entwickeln und das tut weh. Vor allem, weil man nicht weiß, wie man das vernünftig macht. Und das war so der Ausgangszeitpunkt. Damals habe ich während meines Researchs mehrere Projekte noch ausprobiert, aber keines dieser Projekte war aus meiner Perspektive das, was man produktiv dann auch einsetzen könnte und was die Probleme, die der Kunde in dem Fall speziell hatte, auch lösen würde. Während der Zeit wurde ich aber sehr oft von Kolleginnen und Kollegen bei uns gefragt: “Wie kann man das denn machen? Wir haben dieses und jenes Problem”. Und das waren eigentlich genau dieselben Probleme, die ich eingangs auch teilweise schon adressiert habe. Diese Integration von unterschiedlichen Systemen. Wie schafft man ein fragmentiertes Identitätsmanagement zu haben, ohne sich da wirklich einen abzubrechen. Das waren so die Ausgangspunkte, wo ich dann gesagt habe: Okay, ich weiß wie man das macht. Ich kenne mich da aus. Ich habe das sehr oft schon umgesetzt, zwar kundenspezifisch, aber ich möchte jetzt nicht, dass das Rad immer wieder von neu erfunden wird. Dementsprechend habe ich Heimdall angefangen.

Anja Kammer: Ah ja. Das bedeutet, du wolltest auch wirklich keine Lösungen für diesen speziellen Kunden haben, sondern du hast gedacht, du löst das einmal richtig und machst ein Open Source Projekt daraus.

Dimitrij Drus: Genau.

Anja Kammer: Hast du denn schon Erfahrungen mit Open Source gemacht? Hattest du schon andere Open Source Projekte bisher gemacht?

Dimitrij Drus: Ich hatte in der Vergangenheit mal ein Projekt, das auch aus einem Bedürfnis entstanden ist. Das ist schon sehr lange her. Das Bedürfnis war 2010/2011, also vor 13 Jahren. Es ging damals um: Wie teste ich meine Entitäten im Kontext von JPA? Also Java Persistence Architecture. Und damals ist ein Testing Framework entstanden. Der ist seit sechs Jahren eingeschlafen, weil ich in dem Kontext nicht mehr unterwegs war oder bin. Aber das war auch eine schöne Erfahrung. Vor allem das war auch das erste Mal, dass ich für ein Open Source Projekt dann von komplett fremden Personen bezahlt worden bin. Ich habe halt Anfragen bekommen: Das Projekt ist so geil. Ich möchte dich unterstützen. Zwei, drei Anfragen hatte ich. Jetzt habe ich irgendwie Gewissensbisse, dass ich das jetzt seit einiger Zeit nicht mehr pflege.

Anja Kammer: Ja gut, aber auch keine Anfragen mehr. Vielleicht wird es auch gar nicht mehr benutzt.

Dimitrij Drus: Wer weiß, ja.

Anja Kammer: Wie viele Nutzerinnen hattest du da so von diesem Projekt?

Dimitrij Drus: Das weiß ich gar nicht. Das war ein reines Testing Framework. Diejenigen, die das genutzt haben, schön. Für mich war das einfach: Ich wollte irgendwas Zusätzliches machen, was mich irgendwie erfüllt. Und das war eine schöne Freizeitbeschäftigung, nenne ich mal so. Und bei Heimdall war es teilweise auch so. Im Endeffekt ist es größtenteils ein Feierabend- oder Wochenendprojekt gewesen, das relativ stark gewachsen ist und mittlerweile auch weltweit im produktiven Einsatz ist, was mich natürlich sehr freut.

Anja Kammer: Es ist produktiv im Einsatz. Wie viele Unternehmen arbeiten produktiv mit Heimdall?

Dimitrij Drus: Laut dem Feedback, das ich aus der Community habe, fünf oder sechs. Ich weiß, dass es zum Beispiel in Kanada im Einsatz ist. Ich weiß, dass es in Deutschland ein Unternehmen das im produktiven Einsatz hat und dass ein anderes Unternehmen bis Ende des Jahres das in die Produktion bringen möchte. Das ist schon alles gesetzt. Ich weiß, dass es in Schweden im Einsatz ist. Ich weiß, dass es in Slowenien im Einsatz ist und das war’s. Ich meine, das waren fünf.

Anja Kammer: Okay. Und wie sieht es so mit dem Feedback-Rückfluss aus? Hast du da wertvolles Feedback schon einsammeln können? Ich meine, wenn es produktiv verwendet wird, wird ja wohl hoffentlich Feedback kommen.

Dimitrij Drus: Ja, im Prinzip schon. Ich weiß nicht, wovon das abhängt. Vermutlich von irgendwelchen Ferienzeiten. Der erste große Meilenstein im Sinne des Durchbruchs war, als ich dann die Community in Discord gestartet habe. Und da kamen so die ersten User. Anfang bis Mitte letzten Jahres gab es sehr viel Bewegung dort. Die Leute haben diskutiert, haben Feedback gegeben. “Ich habe jetzt das entdeckt”. “Und ich habe jetzt jenes entdeckt. Kannst du es bitte fixen?” usw. In den ersten zwei - drei Monaten, nachdem die Community gestartet war, wurden die meisten Kinderkrankheiten dann auch gelöst. Nachdem das aber erledigt worden war, gab es dann kaum Feedback, bis auf, wenn neue Releases rauskamen. “Ja geil, Danke dir.” Solche Sachen. Relativ regelmäßig mache ich natürlich Aufrufe in die Community: “Ich plane das und das zu machen. Was haltet ihr davon, oder was würdet ihr gerne zusätzlich haben? Und was würdet ihr allgemein gerne haben in den kommenden Release?” Da kommt schon Feedback, was ich dann natürlich auch einbaue.

Anja Kammer: Das ist super. Ich meine, dass du keine Bug Reports mehr bekommst oder negatives Feedback ist vielleicht auch gut. Die Probleme wurden gelöst und man möchte sich auch eigentlich gar nicht darum kümmern und jede Woche schauen, ob die Infrastruktur noch läuft und da irgendwelche Kinderkrankheiten sehen. Es ist ja eigentlich ein sehr gutes Signal, oder?

Dimitrij Drus: Ja, einerseits ja. Andererseits würde ich mir mehr Rückläufer im Sinne des Feedbacks wünschen. Aber es ist okay, wenn die Leute damit oder diejenigen, die es einsetzen, damit glücklich sind, bin ich es an der Stelle auch.

Anja Kammer: Ja, super. Hast du denn Hilfe bei der Entwicklung?

Dimitrij Drus: Ja. Das ist einer der demotivierenden Faktoren. Denn ich bin aktuell noch eine One-Man-Show und diesen Bus-Faktor von eins finde ich persönlich problematisch. Dementsprechend bin ich umso glücklicher, dass die Lösung schon produktiv am Einsatz ist und die entsprechend Firmen sich offensichtlich gedacht haben: Okay, das ist zwar eine One-Man-Show, aber es ist Open Source und im Zweifelsfall können wir das dann auch selbst weiter erweitern, nutzen, entwickeln, falls etwas sein sollte. Das gibt mir sehr positive Signale. Aber natürlich suche ich nach weiteren Kontributoren und Maintainer, also vor allem Maintainer. Und du hast vorher gespoilert. Ich habe Anfang des Jahres einen Antrag für CNCF-Sandbox gemacht, obwohl die Gruppe, in dem Fall TAG Network von CNCF, das Projekt sehr interessant fand und sehr zukunftsorientiert fand, war das Feedback leider: “Du bist halt eine One-Man-Show. Und damit wir das Projekt in Sandbox aufnehmen können, wäre es schön, wenn du mindestens noch einen weiteren Contributor hättest und wenn es ein oder zwei Kollaborationen mit weiteren Open Source Projekten gäbe”. Also kein Nein, sondern das sind Bedingungen für dich, damit das auch angenommen wird. Fand ich ein bisschen komisch, weil aus meiner Perspektive ist die Aufnahme in CNCF-Sandbox genau das Mittel zum Aufbau der Community, das Mittel um neue Kontributoren und Maintainer zu bekommen. Aber okay, ich bin jetzt daran am Arbeiten, diese geforderten Maßnahmen umzusetzen.

Anja Kammer: Dann lass uns doch mal über die Einreichung bei der CNCF sprechen. Das ist im Grunde das, was sich bewegt hat dort einzureichen, dass du mehr Contributors haben wolltest und Leute das Feedback geben, um sozusagen um mehr Reichweite zu bekommen?

Dimitrij Drus: Genau. Also einerseits mehr Reichweite, andererseits um mehr Gehirnhälften, wenn man das so ausdrücken kann, zu haben, in dem man über dieses Themenkomplex diskutieren kann, mit denen man einfach neue Features besprechen kann. Es ist immer schwierig, alleine darüber nachzudenken oder zu grübeln. Und sehr oft ist es einfach nicht ausreichend. Deswegen dauern gewisse Sachen viel länger, als es mir eigentlich lieb ist.

Anja Kammer: Was dauerte denn länger, als es dir lieb war?

Dimitrij Drus: Ich habe ja erzählt, was Heimdall so macht. Aktuell gibt es eine Einschränkung aus meiner Perspektive. Diese sieht die aktuelle Community gar nicht als Einschränkung, weil der Bedarf dort einfach nicht vorhanden ist sowas zu machen. Bei dieser Abstraktion von den Authentifizierungssprotokollen, kann Heimdall aktuell nur einen einzigen Subject intern erzeugen. Vielleicht en kurzer Schritt zurück, was überhaupt ein Subject ist. Wenn man im Authentifizierungs- oder Autorisierungskontext unterwegs ist, dann spricht man regulär von Subject, Object und Permissions. Subject ist das, was auf diesen Object, wie auch immer zugreifen möchte. Und Permission heißt, was im Kontext dieses Zugriffs überhaupt erlaubt ist, oder ob überhaupt dieser Zugriff erlaubt ist. Und in dieser Abstraktion, die Heimdall aktuell implementiert, gibt es nur ein einziges Subject. Sehr oft hat man aber das Bedürfnis eigentlich mehrere Subjects zu haben. Beispiel: Request auf irgendeinen Endpunkt kommt von einem Gerät, mit dem der Benutzer arbeitet. Das heißt, meine Authentifizierungsanforderung wäre: Ich möchte sowohl das Gerät als auch den Benutzer authentifizieren. Und ich möchte sowohl das Gerät als auch den Benutzer autorisieren. Und vielleicht kommt noch zusätzlich die Umgebung - in welchem Netzwerk ist der Benutzer unterwegs? Netzwerk im Sinne von - über welchen Router oder welchen Proxy ging diese Request durch, dass man auch zusätzlich diese Informationen bekommt. Und in diesem Gesamtbeispiel hätte ich dann drei Subjects. Die Idee, die ich jetzt seit längerem irgendwie austrage, ist: Wie kann ich das Modell, was Heimdall intern hat, so anpassen kann, dass ich nicht nur ein Subject habe, sondern mit drei arbeiten kann und dementsprechend die Regeln auf diese oder sogar mehr, unendlich viele Subjects auch zugreifen können und entsprechend nutzen können.

Anja Kammer: Und das ist für dich immer noch ein Problem? Ist es noch ungelöst?

Dimitrij Drus: Das ist immer noch ungelöst. Wir haben mal in der Vergangenheit mit dir gesprochen. Das ist immer noch ungelöst. Anja ist bei mir jetzt auch ab und zu Sparringpartner in diesem Kontext. Für die Hörer des Podcast.

Anja Kammer: Einfach nur eine Rubber Ducky. Manchmal braucht man sowas.

Dimitrij Drus: Ja, genau. Andere Sachverhalte wären: Ich habe jetzt für das nächste Release vorgenommen: Ich möchte so die Ops-Experience verbessern. Also sprich, mehr Metriken, vor allem fachlicher Natur, vielleicht ein besseres Logging. Vielleicht ein Dashboard für Grafana. Aber damit man das überhaupt machen kann, braucht man Feedback. Die Community ist aktuell relativ still, weil die selbst irgendwie glücklich sind. Offensichtlich oder hoffe ich zumindest. Aber jetzt ist die Frage: Wie komme ich jetzt quasi an diese Information? Was wäre denn sinnvoll? Natürlich habe ich eigene Ideen, aber das ist bei weitem nicht das, was ich mir wünsche.

Anja Kammer: Siehst du auch die Gefahr, dass durch eine Community, die sehr aktiv werden könnte, du dann für bestimmte Features überstimmt wirst? Oder, dass sich Heimdall in eine Richtung entwickelt, die du eigentlich gar nicht geplant hast und eigentlich gar nicht willst?

Dimitrij Drus: Das kann definitiv passieren. Das ist in dem aktuellen Zustand Zukunftsmusik. Da muss ich mir noch Gedanken machen, wie ich damit umgehe. Aber im Prinzip bin ich offen für jegliche Änderung. Das beste Beispiel: Heimdall ist zum gewissen Teil opinionated. Ich bin der Meinung, dass OpenID Connect nicht für First-Party Authentifizierung gedacht ist und dementsprechend habe ich diese Funktionalität nicht eingebaut. Das Prüfen der Token usw. ist alles mit dabei. Aber das Fahren, dieses Authorization-Code-Grand-Flows ist zum Beispiel nicht Bestandteil von Heimdall. Das lagere ich an andere Services raus, zum Beispiel an den schon genannten OAuth2-Proxy. Jetzt kann ich mir vorstellen, dass diejenigen, die Heimdall nutzen, sagen: Eigentlich möchte ich weniger Moving Parts haben in meinem Setup. Implementiere doch bitte diese Funktion in Heimdall. Ich bin da eher zurückhaltend. Das möchte ich eigentlich nicht, weil ich meine Meinung ist: Ja, kann man machen, aber es gibt bessere Wege. Das wäre so ein Beispiel, wo ich jetzt aktuell noch nicht weiß, wie ich damit umgehe, obwohl ich selbst dafür ein Ticket bei GitHub eingetragen habe und bin einfach gespannt, wie viele da voten, dass die das benötigen. Aktuell keiner. So gesehen ist das erstmal im Backlog.

Anja Kammer: Vielleicht auch die Ruhe vor dem Sturm. Wer weiß.

Dimitrij Drus: Genau, wer weiß.

Anja Kammer: Wir haben über die Einreichung bei der CNCF gesprochen. Wie war denn so der Prozess? Wie lief das Ganze ab?

Dimitrij Drus: Relativ simpel. Ich habe mich im CNCF Slack erkundet. Einfach Leute gefragt: Ich möchte mein Projekt einreichen. Wie ist der Prozess? Und man hat sich dann auf das entsprechende CNCF Sandbox Projekt bei GitHub verwiesen und gemeint: mach einfach ein Ticket auf. Und dem bin ich einfach gefolgt. Und da ist ein Template hinterlegt, das zu füllen ist. Und irgendwann bekommt man dann Feedback von der CNCF-Community, dass die das Review des Projektes für den Zeitraum eingeplant haben. Und irgendwann bekommt man dann eine Einladung: Lass mal darüber sprechen. Und in meinem Fall habe ich ungefähr zwei Wochen vor dem eigentlichen Review-Termin eine Anfrage bekommen, von dem Chair der TAG Network Gruppe, mit der Frage, ob ich das Projekt schon mal irgendwo vorgestellt habe. Das war bis dato nicht der Fall. So hat er vorgeschlagen: Lass uns mal einen ein Video auf YouTube drehen, was wir dann auf der CNCF TAG Network Seite dann veröffentlichen werden. Das haben wir dann gemacht. Das Video hat natürlich sehr gute Resonanz gehabt, weil dann hat das Projekt direkt zu sechs oder sieben Sterne mehr, an dem Tag nachdem das Video veröffentlicht worden ist, bekommen. Das hat mich natürlich gefreut.

Anja Kammer: Okay, das Video verlinken wir dann auf jeden Fall in den Shownotes.

Dimitrij Drus: Der Chair der TAG Network Gruppe ist selbst von dem Projekt sehr begeistert und hat dann auch direkt seine Hilfe angeboten und meinte: Lass uns mal zusätzlich einige Videos drehen, die dann interessanter sind als das, was du dann präsentiert hast, wo wir einfach zeigen, wie man mit Heimdall arbeiten kann und welche Integrationsmöglichkeiten da sind. Und das veröffentlichen wir dann auch. Geplant ist jetzt eine Reihe aus drei Serien. In der ersten werden wir zeigen, wie man Heimdall mit Verwendung von OAuth2-Proxy und Keycloak dann für First-Party Logins nutzen kann und entsprechend endpunktspezifische Absicherungen vornehmen kann. Beispielsweise an /public Endpoint und /user wäre dann für alle auch authentifizierten User erreichbar und sowas wie /admin wäre nur für Admins erreichbar. Das ist nicht nur Authentifizierung, sondern zusätzlich schon ein Autorisierungsmerkmal. Meinetwegen mit der Rolle Admin. Dass wäre das erste Video. Im zweiten Video würden wir diesen Autorisierungsaspekt auslagern an beispielsweise an OPA (Open Policy Agent), und würden zeigen, wie das funktioniert. Und in dem dritten Video wollten wir die Integration mit Istio noch zusätzlich hinzufügen, dass man sagt: Okay, wir haben jetzt einige Workloads in unserem Cluster und wir haben jetzt ein Istio-Gateway. Wie können wir jetzt den Envoy, der von Istio konfiguriert wird, jeweils so konfigurieren, dass für entsprechende Anfragen dann an Heimdall weitergeleitet wird bzw. dieser Request bei Heimdall durchgeroutet wird, um Authentifizierungs- und Autorisierungsanforderungen abzubilden. Das wäre das dritte Video.

Anja Kammer: Gut, ich habe jetzt noch zwei Fragen im Kopf. Die eine Frage ist, du hast Istio erwähnt. Heimdall funktioniert auch in allen Umgebungen. Ich brauche keine Kubernetes Umgebung dafür, auch wenn du dich für einen CNCF-Sandboxprojekt beworben hast?

Dimitrij Drus: Genau. Klar, Heimdall kann stand-alone operiert werden. Beispielsweise als ein ganz normaler Prozess auf dem Betriebssystem oder auch als einfacher Container. Es hat keine Abhängigkeit zu Kubernetes. Mit Kubernetes hat man insofern eine Integration, dass Heimdall intern einige Controller umsetzt. Der eine Controller für die Verifikation der Regeln. Die Umsetzung der Authentisierungs- und Autorisierungsanforderung werden in Heimdall mit Regeln abgebildet. Und dafür gibt es Custom Resources Definition in Heimdall, die jetzt mit dem Helm-Chart mit ausgeliefert werden und mit deren Hilfe man dann entsprechende Regeln definieren kann. Dafür gibt es, wie gesagt, einen entsprechenden Admission Controller, den Heimdall implementiert und zusätzlich implementiert Heimdall einen weiteren Controller, um diese Regeln zu laden. Für Verification und für das eigentliche Laden. Und das ist die einzige Integration in Kubernetes die es eigentlich so gibt. Abgesehen von den Standard Annotations für meinetwegen Scrapen von Metriken und Ähnlichen.

Anja Kammer: Aber jegliche Konfiguration kann ich auch einfach so mittels Dateien bereitstellen. Ich brauche dafür keine Customer Resource Definitions.

Dimitrij Drus: Genau, die Standardkonfiguration beinhaltet die regulären Settings, die man von Services kennt. Welcher Port wird verwendet? Logging-Konfiguration, Tracing-Konfiguration, Metrics-Konfiguration. Aber, so das Herz der Konfiguration macht der sogenannte Mechanisms Catalogue aus. Das ist die Sammlung der möglichen, ich nenne sie mal Mechanismen, die man später in Regeln differenzieren kann, wo man entweder Defaults nutzt, dann muss man in der Regel nichts mehr konfigurieren, oder wenn man gewisse Sachverhalte noch mal um konfigurieren kann, je nachdem welche Abweichung man braucht von diesen Defaults. Und diese Regeln können aus dem File System geladen werden, von beliebigen HTTP-Endpunkten geladen werden, von Cloud Blobs, wie AWS S3 Bcket, oder ähnlichen, aber auch als Kubernetes Custom Resources Definitions. Je nachdem, ob man den jeweiligen Provider zum Laden dieser konfiguriert hat.

Anja Kammer: Du hast an alles gedacht. Man merkt schon, dass du da sehr viel Herzblut reingesteckt hast.

Dimitrij Drus: Definitiv.

Anja Kammer: Sehr gut. Du hattest auch erwähnt, dass es da sehr viel Begeisterung gibt und dir wurde dann auch vorgeschlagen, noch mal eine Serie daraus zu machen und eine Serie von Videos zu machen. Was führt die Leute dazu, so begeistert zu sein? Was glaubst du, ist das Killer-Feature, wo die Leute sagen: Wow, das ist Wahnsinn. Das begeistert mich jetzt.

Dimitrij Drus: Es ist super einfach. Im einfachsten Fall definierst du deinen Katalog mit dem, was benötigt ist. Du definierst deine Default-Regel. Diese Option gibt es in Heimdall. Und das war’s. Mehr musst du nicht machen. Und wenn du Abweichungen von dieser Default Regel hast, dann erzeugst du Dateien pro Microservice. Es ist ja dann essenzieller Bestandteil des Microservices und schreibst deine spezifische Anforderung deklarativ rein. Und sowas gibt es einfach nicht. Die Services, die ich in dem Kontext kenne und das sind gerade mal drei. Zwei davon wusste ich schon seit längerem, bevor ich Heimdall gestartet habe, die ich vorher erwähnt habe. Und eins habe ich Ende des letzten Jahres bzw. Anfang dieses Jahres kennengelernt. Sie adressieren ungefähr vergleichbare Aspekte, aber die brauchen bei weitem viel mehr Konfiguration als mit Heimdall. Und das ist dann einfach. Und das sagen auch die Leute aus der Community bzw. auch der Chair der TAG Network Gruppe. Nic an der Stelle. Und laut seiner Aussage, der ist einfach begeistert.

Anja Kammer: Sehr schön. Mich hat es auch begeistert. Auch die Einfachheit und die Art und Weise wie man Regeln beschreiben kann, fand ich auch sehr intuitiv. Bzw. Du hast auch gefragt: Hey Anja, wie intuitiv ist das? Wie würdest du das ändern? Dann durfte ich dir meine Meinung sagen.

Dimitrij Drus: Da bin ich auch sehr dankbar, dass du die Zeit gefunden hast.

Anja Kammer: Ja. Was glaubst du, was muss sich so im Cloud Native Bereich in der Community ändern, damit Heimdall so richtig aufblühen kann, um das Projekt irgendwie so voranzutreiben? Was müsste sich so ändern oder muss sich überhaupt was ändern?

Dimitrij Drus: Ich glaube, es muss sich gar nicht so viel ändern. Eigentlich bedarf es keiner Änderung, weil die Probleme sind da, die Heimdall interessiert und nicht nur Heimdall. Es ist einfach der Bekanntschaftsgrad für das Projekt hier. Sobald dieser etwas größer ist, glaube ich schon, dass das Projekt Wind in den Segeln bekommt und die Community noch größer wird und das Projekt als solches besser und erwachsener wird. Was auch immer das dann bedeutet für die Zukunft.

Anja Kammer: Du hast allein an Heimdall entwickelt. Wie war denn so der Entwicklungsprozess? Gab es irgendwelche bestimmten Meilensteine oder bestimmte Wendepunkte? Kannst du da mal aus dem Nähkästchen plaudern?

Dimitrij Drus: Ja, im Prinzip muss ich jetzt ein bisschen zurückblicken. Da gab es in der Tat mehrere. Der erste große Meilenstein aus meiner persönlichen Perspektive war erreicht, als ich Conditions in den Regeln erlaubt habe. Sprich, man konnte ab dem Zeitpunkt dann sagen: Diesen Mechanismus also z.B. diese Art der Autorisierung möchte ich nur ausführen, wenn das und das gilt. Beispielsweise, wenn es einen authentifizierten Subject gibt, oder wenn der Request meinetwegen ein GET Request war. Davor war es nicht möglich und das war dann umständlich, das Ganze entsprechend zu konfigurieren. Man bräuchte einfach mehr Regeln. Das war für mich persönlich dann ein großer Meilenstein. Und die Leute aus der Community meinten auch: Das ist richtig geil. Es hilft ihnen. Und der zweite große Meilenstein, ich will mal sagen, das ist jetzt vor einigen Wochen gewesen, wo ich endlich mal den Alpha-Suffix bei der Version rausgenommen habe und zwar eigentlich auch auf Druck der Community, weil die Leute gesagt haben: Nimm endlich mal dieses Suffix raus, der stört nur. Das Projekt ist bei weitem nicht Alpha. Und das, was du dir vorstellst, wenn es nicht mehr Alpha ist, dann bist du schon längst bei Version 3.0 oder Ähnliches. Weil die meinten: Okay, das ist schon produktiv im Einsatz. Das ist stabil genug. Breaking Changes im Sinne der Konfiguration wird es immer geben, aber das ist nutzbar. Das ist besser als alles andere, was die da draußen kennen. Und das ist produktiv. Das ist kein Alpha. Ich dachte: Okay, ich lasse mich überreden. Ich nehm’s raus. Aber wieso habe ich diesen Alpha-Suffix rausgenommen? Meine Initialidee war: Ich nehm’s nur dann raus, wenn Ich weiß, ich antizipierte keine Breaking Changes. Ich habe jetzt weder in meiner Issue-Liste in GitHub noch in meinem Kopf nichts was zu Breaking Changes führen würde. Und ich wollte auf jeden Fall das meiste, was sowas bedeuten könnte (mit sowas meine ich Breaking Changes), zu diesem Release dann auch hinter mich bringen. Das habe ich dann geschafft. Und deswegen ist jetzt der aktuelle Release, der 0.15.0 ohne Alpha-Suffix für mich auch ein großer Meilenstein.

Anja Kammer: Kann es sein, dass dir dabei dein Perfektionismus ein wenig im Weg steht? Ich meine, vielleicht hätte es schon vorher soweit sein können.

Dimitrij Drus: Ich zweifle nicht daran. Ja, das ist definitiv der Fall.

Anja Kammer: Wenn du so auf die bisherige Reise bei der Entwicklung von Heimdall zurückblickst, hat dich irgendwas motiviert. Was hat dich motiviert, da dranzubleiben? Einfach nur das Wissen: Es ist besser als alle anderen Tools, die es da draußen gibt?

Dimitrij Drus: Ja, das ist vielleicht selbstsüchtig, aber in der Tat, würde ich mal vielleicht sagen: Ja, weil ich bin von dem Projekt sehr überzeugt. Wenn ich das nicht wäre, dann würde ich das nicht machen. Aber ich bin sehr überzeugt, und das gibt mir persönlich die Kraft da weiterzumachen. Und weil ich ab und zu immer noch Feedback bekomme. Ob das jetzt von der Community ist, ob das jetzt beispielsweise von den Leuten von CNCF ist und auch darüber hinaus, weil das Video hat dann einige andere interessante Kontakte erzeugt. Oder bei uns in der INNOQ intern. Ich bekomme Feedback und der allein sagt: Nee, ich mache das Richtige. Das ist das, was den Leuten hilft. Und das sollte die Natur der Open Source Projekte sein, dass das hilfreich ist. Ich wüsste nicht, was ich noch hinzufügen sollte.

Anja Kammer: Du hattest gesagt, diese Bewerbung bei der CNCF hat noch ein paar weitere Wellen geschlagen. Wer ist denn noch so auf dich zugekommen oder auf dich aufmerksam geworden dadurch?

**Dimitrij Drus] Ich würde jetzt nicht sagen Wellen, aber ich habe einige Tage später eine Kontaktaufnahme von einer Person aus den USA bekommen. So wie ich ihn verstanden habe, arbeitet er im Kontext von CNCF, schreibt ab und zu Papers für die im Kontext von Zero Plus Networking. Der ist selbst schon pensioniert, aber er war seinerzeit CTO einer Firma. Er hat den Namen nicht genannt, beziehungsweise er hat schon einen Namen genannt, aber ich habe es jetzt nicht im Kopf. Und der fand Heimdall einfach genial, weil das ist einer der essenziellen Bausteine. Es ist nicht so, dass ich mit Heimdall allein Zero Trust Networking oder Zero Trust Security als solches umsetzen kann. Da bedarf es vieler weiterer Komponenten. Und Heimdall ist halt eine der Komponenten. Vielleicht kann man, wenn man jetzt wieder zurückgeht, was Heimdall ist, kann man vielleicht auch sagen, dass es so eine Art Universal Policy Enforcement Point, der das Ganze dann orchestriert. Und es gibt aber noch weitere Komponenten, die speziell für Networking zuständig sind. Und in dem Kontext wurde ich dann von einer Firma kontaktiert mit Sitz in den USA. Und die machen Zero Trust Networking auf L4-Ebene, also TCP/IP. Heimdall ist nur Layer 7. Die Firma, ich habe jetzt den Namen leider vergessen. Tut mir leid. Aber das ist die Firma hinter OpenZity, hinter dem Projekt OpenZity. Falls das jemandem etwas sagt. Und es gab ein interessantes Gespräch mit dem Vice President der Firma, der für entsprechende strategische Partnerschaften zuständig ist. Ob sich daraus was entwickelt, werden wir dann sehen.

Anja Kammer: Ich wünsche es dir auf jeden Fall.

Dimitrij Drus: Danke, danke. Ich behaupte jetzt nicht, dass es eine große Welle ist. Ich bin einfach gespannt, was daraus dann wird. Vielleicht auch gar nichts, wer weiß.

Anja Kammer: Genau, damit muss man auch umgehen können, oder?

Dimitrij Drus: Definitiv. Ich habe vorher über die Stille der Community von Zeit zu Zeit gesprochen. Damit muss man auch mit umgehen können.

Anja Kammer: Da braucht man ein dickes Fell.

Dimitrij Drus: Man muss einfach dranbleiben.

Anja Kammer: Was würdest du denn Open Source Contributern oder Menschen, die Open Source Projekte starten, empfehlen, was sie sich noch zulegen sollen, neben dem dicken Fell?

Dimitrij Drus: Ja, vielleicht das, was du vorhin gesagt hast, dass mir Perfektionismus im Wege steht. Sprich: Warte nicht darauf, dass alles perfekt ist. Die Projekte entwickeln sich einfach kontinuierlich weiter und es ist wichtig auf das Feedback aus der Community zu hören und zu reagieren, wie auch immer der geartet ist. Das kann schon sein, dass es länger dauert. Man muss einfach offen für die Hilfe sein. Und Open Source Projekte sind an der Stelle eine großartige Ressource. Man muss aber nicht davon ausgehen, dass die Hilfe immer kommt. Das kann demotivierend sein, aber man muss einfach am Ball bleiben. Wäre meine Empfehlung.

Anja Kammer: Auf jeden Fall. Gibt es irgendwelche Hürden, die du nehmen musstest, die man so gar nicht auf dem Schirm hätte, wenn man anfängt von denen vielleicht auch überrascht warst?

Dimitrij Drus: Ehrlich gesagt gar nicht.

Anja Kammer: Ich hatte es schon auf dem Schirm, was da kommen könnte, nämlich Funkstille.

Dimitrij Drus: Genau. Vielleicht lag es auch daran, dass ich in den regulären Projektkontexten, in denen ich unterwegs bin, eher als Einzelkämpfer unterwegs bin. Ich bin nicht in Teams von der INNOQ unterwegs. Ich bin mit anderen Teams unterwegs. Und das ist eine völlig andere Situation, als wenn man in der Mannschaft gemeinsam etwas macht. Und mag sein, dass dadurch, dass ich an solches Arbeiten gewohnt war, ich es so gar nicht wahrgenommen habe, dass es eine Hürde ist, oder dass es problematisch ist.

Anja Kammer: Gibt es sonst noch etwas, was du unseren Hörerinnen mit auf den Weg geben möchtest?

Dimitrij Drus: Falls jemand Interesse an dem Projekt hat, gerne der Community beitreten. Ich freue mich auf jeden Fall. Falls jemand eigene Ideen hat, aber Scheu hat, etwas Eigenes zu realisieren - es wird nie der richtige Zeitpunkt kommen. Mach einfach. Und sei einfach geduldig. Sei offen für Feedback und sei bereit, einfach kontinuierlich zu lernen. Und ich würde mal sagen, dass es extrem wichtig ist. Vor allem der Kommunikationsaspekt. Sowohl auf das Projekt bezogen, als auch auf die Community bezogen. Und hab einfach eine klare Vision und sei flexibel. Dann wird schon alles funktionieren. Das wären vielleicht so die letzten Worte in diesem Kontext. Natürlich würde ich mich mehr freuen, wenn es kein eigenes Projekt ist, sondern dass ich dich jetzt als Hörer für das Projekt gewinnen kann. Das wäre natürlich sehr toll.

Anja Kammer: Klasse, das sind schöne Schlussworte. Dann bedanke ich mich für das Gespräch, Dimitrij.

Dimitrij Drus: Danke dir ebenfalls. Hat mich gefreut.

Anja Kammer: Ciao!

Dimitrij Drus: Ciao!