Transkript

Secrets Management

Von der Herausforderung, Geheimnisse zu verwalten

Wie lassen sich Geheimnisse wie Passw├Ârter verwalten in einer Welt von automatisierter Infrastruktur, Cloud-Anbietern und Continuous Deployment? In diesem Podcast unterhalten sich J├Ârg M├╝ller und Daniel Bornkessel ├╝ber modernes Secrets Management und dabei insbesondere ├╝ber Hashicorps Vault.

Zur├╝ck zur Episode

Transkript

J├Ârg M├╝ller: Willkommen zu einer neuen Folge des INNOQ-Podcasts. Wir wollen uns heute zum Thema Secrets-Management unterhalten und daf├╝r habe ich mir Daniel eingeladen. Hallo Daniel!

Daniel Bornkessel: Hallo J├Ârg!

J├Ârg M├╝ller: M├Âchtest du kurz ein paar Worte zu dir sagen, wer du bist und was du so bei INNOQ machst?

Daniel Bornkessel: Klar. Mein Name ist Daniel Bornkessel, ich bin Senior Consultant bei INNOQ Deutschland. Und ich habe mich die letzten Jahre haupts├Ąchlich besch├Ąftigt mit Themen wie Infrastruktur, Continuous Integration, Continuous Delivery und in letzter Zeit auch verst├Ąrkt mit ÔÇô wenn man man einen Hype-Begriff nennen m├Âchte ÔÇô DevSecOps. Ich komme aber aus der Ecke der Applikations-Entwicklung. Das hei├čt, ich bin nicht urspr├╝nglich ein Admin oder Operations-Entwickler gewesen, sondern eher aus der Applikationsecke.

J├Ârg M├╝ller: Wir haben uns jetzt ja das Thema Secrets-Management ausgesucht. Das ist ein Thema, wenn man den Namen h├Ârt, dann klingt das erst einmal wahnsinnig wichtig, ganz geheim. Aber ich glaube, so richtig klar ist den meisten nicht, was darunter zu verstehen ist. Vielleicht f├╝r unser heutiges Gespr├Ąch: Was verstehst du unter Secrets-Management und was macht man damit?

Daniel Bornkessel: Ja, genau, diesen Begriff Secrets-Management, so richtig gibt es den nicht. Man wird daf├╝r zum Beispiel keinen Eintrag bei Wikipedia finden. Es geht um Secrets, wie der Begriff schon sagt. Erst einmal ganz kurz: Unter einem Secret verstehen wir hier nicht Daten, die verschl├╝sselt zum Beispiel abgespeichert werden m├╝ssen in einer Datenbank, sondern es geht wirklich um Passw├Ârter, API-Keys, Tokens, Zertifikate und so weiter.

J├Ârg M├╝ller: Also eigentlich die Dinge, mit denen man dann auf die verschl├╝sselten Daten zugreift?

Daniel Bornkessel: Genau richtig, ja. Also beim Secrets-Management geht es um die Schl├╝ssel, mit denen ich Daten verschl├╝sseln kann, zum Beispiel. Das Ganze ist Teil eines Sicherheitskonzepts in der Firma. Aber im Gegensatz zu den externen Problemen oder Gefahren, die auftreten k├Ânnen, wie zum Beispiel Angriffe von au├čen, wof├╝r man Firewalls hat, besch├Ąftigt sich Secrets-Management sehr viel mit den Problemen, die von internen Angriffen ausgehen k├Ânnen. Also wenn im Extremfall ein Mitarbeiter der Firma wirklich etwas B├Âses m├Âchte oder auch wenn ein Mitarbeiter die Firma verl├Ąsst und dann aber Passw├Ârter hat, die immer noch g├╝ltig sind, obwohl er nicht mehr in der Firma ist.

J├Ârg M├╝ller: Okay, cool. Bevor wir uns jetzt dar├╝ber unterhalten, wie man das ganz modern und schick macht, lohnt sich ja durchaus mal ein Blick in die Vergangenheit und zu schauen, wie man das eigentlich fr├╝her gemacht hat und wie ist man fr├╝her mit Datenbank-Passw├Ârtern zum Beispiel umgegangen?

Daniel Bornkessel: Genau. Fr├╝her, ich sage mal so, vor ungef├Ąhr zehn Jahren war das normale Setup von IT eigentlich noch, eine Applikationen war ein Monolith, der wurde auf einem Server deployt und die Server wurden von Admins ÔÇô also damals hat man immer Admins gesagt, heute sagt man oft OPs oder Operations ÔÇô von Hand gepflegt. Das Sicherheitskonzept war da einfach, dass es eigentlich eine relativ kleine Gruppe von Leuten gab, die sich um die Secrets oder Passw├Ârter ÔÇô Datenbank-Passw├Ârter, das ist ein gutes Beispiel ÔÇô gek├╝mmert haben. Das hei├čt, sie haben dann auch eine Datenbank aufgesetzt. Der Admin hat eine Datenbank aufgesetzt, hat ein ÔÇô meistens ÔÇô sicheres Passwort generiert, die Admins an sich haben damals, glaube ich, auch schon h├Ąufig einen Passwortmanager benutzt, bei dem sie die Passw├Ârter abgespeichert haben. Sie haben den Server vorbereitet und haben dort dann Konfigurationsdateien hinterlegt, die dann wiederum Applikationen benutzt haben, um zum Beispiel eine Verbindung zur Datenbank aufzubauen.

J├Ârg M├╝ller: Und warum geht das nicht mehr?

Daniel Bornkessel: Die Architektur hat sich in den letzten Jahren ziemlich ge├Ąndert. Vor zehn Jahren waren die Anforderung noch nicht so hoch. Das hei├čt, mit einem Monolithen konnte man eigentlich noch relativ gut fahren. Wenn man sich heutzutage Gesch├Ąfte anschaut, also auch klassische Gesch├Ąfte wie zum Beispiel Otto, wird einfach der online-Anteil immer h├Âher. Das hei├čt, mit dem Monolithen ist man nicht mehr weitergekommen, die haben irgendwann nicht mehr skaliert. Relativ h├Ąufig ist man auf eine Microservice-Architektur umgechwenkt. Und das bedeutet dann auch, dass man nicht mehr vielleicht f├╝nf Rechner hat, die man pflegen muss, sondern dass man zwanzig oder drei├čig Maschinen hat, weil man zum Beispiel auch f├╝nfzig Microservices hat. Da skaliert die alte Strategie mit ÔÇ×Ich setze einen Server von Hand auf, ich lege dort eine Passwort-Datei hin und ich erzeuge Passw├Ârter f├╝r die Datenbanken von HandÔÇť irgendwann nicht mehr.

J├Ârg M├╝ller: Und dann ist ja auch noch dieses Thema Continuous Delivery irgendwie dazu gekommen. Dass man gesagt hat, man will das Ganze auch noch automatisch ausrollen. Ich kann mir vorstellen, dass das dabei auch ein Problem ist, wenn ich dasÔÇŽ

Daniel Bornkessel: Genau, das auch, vor allem bei Microservices ist man irgendwann auch weg von dem Rechner-zentralisierten Ansatz. Das hei├čt, fr├╝her hatte ich wirklich eine statische Liste und habe gesagt, auf Rechner eins ist Applikation eins deployt und vielleicht auch auch auf Rechner zwei und drei oder von mir aus auch auf einer virtuellen Maschine. Und heute mit Frameworks wie Kubernetes zum Beispiel, wei├č ich gar nicht mehr, wo welche App deployt wird. Das hei├čt, mit der Strategie, ich lege dort eine Passwort-Datei hin, w├╝rde ich hier auch einfach nicht mehr weiterkommen.

J├Ârg M├╝ller: Du hast jetzt schon Passwort-Manager erw├Ąhnt, dass man sich also irgendwo zumindest die Passw├Ârter gemerkt hat, damit auch mal ein Kollege darauf schauen kann oder so, damit man das nicht in seinem eigenen kleinen schwarzen B├╝chlein hat. Gab es daneben noch andere M├Âglichkeiten, wie man sich das schon mal erleichtern konnte oder wie ist man damit umgegangen?

Daniel Bornkessel: Ja, ganz am AnfangÔÇŽ Ich habe das auch gemacht in einem Projekt. Was ich eben schon gesagt hatte, man ist weg von den Rechnern, und irgendwann kam auch die Container-Technologie auf. Das hei├čt, eine Applikation, also ich nehme jezt einmal Java- oder Ruby und Rails-Applikationen, wird in einen Container verpackt und hat somit auch ├╝berhaupt nicht mehr Zugriff auf den Host, auf dem es l├Ąuft. Das hei├čt, die urspr├╝ngliche Strategie, dass jemand eine Konfigurationsdatei mit den Passw├Ârtern auf einen Host legt, wird da nicht mehr funktionieren, weil der Container normalerweise keinen Zugriff hat. Man muss also eine M├Âglichkeit haben, wie man die Passw├Ârter der Applikation zum Deployment ├╝bergibt. Das sind im Wesentlichen zwei M├Âglichkeiten gewesen, die man da durchgef├╝hrt hat. Einmal, wenn man jetzt eine 12-Factor-App hat, hat man die Passw├Ârter per Environment-Variable hineingegeben, also Umgebungsvariablen, oder man hat die Konfigurationsdatei einfach verschl├╝sselt in den Container abgelegt und zur Startzeit wurde die Datei dann entschl├╝sselt und gelesen.

J├Ârg M├╝ller: Ah ja, okay. Gut, jetzt haben wir sehr oft Applikationen, die nicht nur auf lokaler Infrastruktur laufen, bei denen das so gilt, sondern teilweise auch schon in einer Cloud. Ich habe zumindest bei dem einen oder anderen Cloud-Anbieter auch schon L├Âsungen gesehen, die sagen, hier, wir machen Secrets-Management. Bei Kubernetes zum Beispiel gibt es Kubernetes-Secrets und ├Ąhnliche Dinge. Wie sieht es da aus? Hat sich das schon weiter entwickelt, ist es schon besser geeignet, um meine Passw├Ârter zu speichern?

Daniel Bornkessel: Diese Ans├Ątze wie Kubernetes-Secrets, AWS ÔÇô da gibt es einen Secrets-Store, es gibt AWS-KMS ÔÇô die arbeiten im Prinzip ├Ąhnlich wie herk├Âmmliche Passwort-Manager. Das hei├čt, ich habe ein Passwort, das von jemandem, automatisiert oder nicht automatisiert, generiert wird. Jemand nimmt dieses Passwort, speichert es irgendwo verschl├╝sselt ab und dann zur Startzeit hole ich mir das verschl├╝sselte Passwort, entschl├╝ssele es und starte damit meinen Service. Das gr├Â├čte Problem sind aber lang anhaltende Secrets. Das hei├čt, wenn ich eine Datenbank generiere, ein Passwort erzeuge, dann ist das Passwort g├╝ltig. Und wenn man das nicht regelm├Ą├čig tauscht, dann kann jeder, der einmal das Passwort hatte, einfach so lange auf die Datenbank zugreifen, wie das Passwort g├╝ltig ist. Was fr├╝her war oder ich denke, in den meisten Firmen ist es immer noch so: Die Datenbank wird erstellt, ein Passwort wird erstellt und dann ist das Passwort einfach g├╝ltig. In gr├Â├čeren Unternehmen gibt es dann Compliance-Prozesse. Wenn ich eine ISO 27001 habe, dass ich das einmal pro Jahr oder alle halbe Jahr wechseln muss, aber das sind immer noch sehr langlebige Passw├Ârter. Das hei├čt, das Problem von langlebigen Passw├Ârtern l├Âsen diese Systeme eigentlich auch nicht.

J├Ârg M├╝ller: Okay, das hei├čt, du sagst, nach dem, was man heute eigentlich als Best-Practices ÔÇô ich mag ja den Begriff nicht so ÔÇô was man als beste Varianten oder Vorgehensweisen verwendet, um Secrets sicher zu machen, wird dadurch noch nicht hundertprozentig erf├╝llt? Also was sind denn das f├╝r Dinge, auf die man da heutzutage achten m├╝sste?

Daniel Bornkessel: Also das gro├če Problem sind wirklich langlebige Credentials, ob es jetzt Passw├Ârter oder API-Keys oder so etwas sind. Das Problem ist, wenn ich Entwickler bin und eine App deploye und ich m├Âchte wirklich vielleicht einfach b├Âse sein und der Firma etwas B├Âses wollen, an das Passwort zu einer Datenbank, daran komme ich dann immer. Selbst wenn ich nicht auf den Rechner komme, ├╝ber den Code kann ich das aus Versehen ausloggen und kann es mir aufschreiben. Mit dieser Methode sind die Passw├Ârter verschl├╝sselt gesichert, aber man hat immer noch nicht das Problem gel├Âst, dass Passw├Ârter meistens einfach sehr, sehr lange g├╝ltig sind. Ich kenne einfach aus der Praxis kaum eine Firma, die jedes Mal, wenn sie ein Mitarbeiter verl├Ąsst, der potenziell mal das Passwort einer Datenbank h├Ątte lesen k├Ânnen, das Passwort dann wirklich wechselt. Das ist der Idealzustand, das wei├č auch jeder. Ich sage mal so, die Best-Practices von Secrets-Management, die sind eigentlich wenig ├╝berraschend, aber sie sind relativ aufwendig und es ist noch nicht ├╝blich, das so zu automatisieren wie eine Firewall aufzusetzen. Eine Firewall aufsetzen wird jeder machen, HTTPS macht mittlerweile auch fast jeder und das ist bei dem Secrets-Management, w├╝rde ich sagen, noch nicht selbstverst├Ąndlich. Obwohl die Best-Practices, glaube ich, schon eigentlich wenig ├╝berraschend sind.

J├Ârg M├╝ller: Okay. Du hast jetzt, glaube ich, schon an der eim oder anderen Stelle einen Vortrag dar├╝ber gehalten, deswegen werde ich dich dazu jetzt genauer fragen: Und zwar ├╝ber ein Produkt, das nennt sich HashiCorp-Vault. Das scheint ja einen Teil dieser Probleme jetzt irgendwo zu l├Âsen; was ist das und warum sollte man sich das vielleicht anschauen?

Daniel Bornkessel: Genau. Also HashiCorp-Vault reden auch immer ├╝ber Secrets-Management. Also wie gesagt, es ist nicht so eindeutig spezifiziert, was Secrets-Management jetzt alles bedeutet. Von daher ist es bei mir auch ein bisschen so, die Definition von Secrets-Management ist auch von dem abgeleitet, was Vault als Feature-Set hat. Ganz kurz, bevor ich ├╝ber Vault rede: Es gibt noch ein paar andere L├Âsungen, es gibt bei Amazon-AWS ÔÇô f├╝r die, die da zu Hause sind ÔÇô da gibt es auch den AWS-Secrets-Manager seitÔÇŽ Ich wollte erst sagen, das ist relativ neu, in AWS-Zeiten ist etwas ├╝ber ein Jahr ja schon fast alt und etabliert. F├╝r die, die auf Cloud Foundry sind, da gibt es CredHub, das macht auch etwas ├ähnliches, und dann gibt es noch KeyWhiz von Square.

J├Ârg M├╝ller: Die machen alle so etwas ├ähnliches wie Vault, oder?

Daniel Bornkessel: Jein. Also sie machen alle etwas ├ähnliches; Vault ist wirklich mit Abstand die umfangreichste L├Âsung, wenn es um Secrets-Management geht. Denn Vault hat das Problem geknackt, dass man eigentlich immer langlebige Secrets hat. Die anderen haben auch etwas ├ähnliches, die sagen dann nur, dass man Secrets ÔÇ×durchrollierenÔÇť kann oder einfach automatisiert austauschen kann, das muss ich aber von Hand antriggern. Was Vault so besonders macht ist, dass es dynamische Secrets sind. Dar├╝ber k├Ânnen wir gleich noch einmal im Detail reden.

J├Ârg M├╝ller: Ja, genau, das w├Ąre jetzt meine Frage: Also wie hat denn Vault das jetzt geknackt? Du hast gesagt, sie haben das Problem geknackt mit den kurzfristigen Secrets, aber wie?

Daniel Bornkessel: Vault hat etwas einegf├╝hrt, das sind sogenannte dynamische Secrets. Wenn wir jetzt bei dem Beispiel der Datenbank bleiben, ist es ja im Prinzip so, ich habe einen User-Namen und Passwort damit ich mich bei der Datenbank authentifizieren kann. Das ist halt bei allen Systemen im Prinzip das Gleiche. Manchmal habe ich einen API-Key, was dann nur ein langer String ist, oder ich habe ein Token. Und das Problem ist, wie gesagt, wenn dieser User-Name und das Passwort relativ lange g├╝ltig sind. Und was Vault jetzt macht und wie das funktioniert, erkl├Ąre ich gleich. Aber was im Prinzip passiert ist, ich fahre eine Instanz meiner Applikation hoch und sie fragt bei Vault an: Ich m├Âchte mit folgender Datenbank sprechen. Und wenn die Applikation authentifiziert und autorisiert ist, erzeugt Vault im Hintergrund quasi on-the-fly einen User-Namen mit einem Passwort und gibt das der Applikation. Und dieser User-Namen und das Passwort sind dann auch nur f├╝r eine bestimmte Zeit g├╝ltig, das kann ich konfigurieren, normalerweise einen Tag oder so. Im Hintergrund, das h├Ârt sich jetzt ein bisschen wie Magie an, das ist nicht so viel Magie. Was da passiert ist, ich konfiguriere Vault so, dass es quasi einen Super-User hat in der Datenbank oder einen Admin-User, der User on-the-fly erstellen und auch l├Âschen kann. Das hei├čt, was wirklich passiert ist, ich konfiguriere Vault so, Vault hat dann wirklich Zugriff auf meine SQL-Datenbank, wenn eine Applikation ankommt und sagt, ich m├Âchte jetzt Zugriff auf folgende Datenbank haben, dann erstellt Vault bei MySQL jetzt zum Beispiel wirklich Nutzer und Passwort, liefert das meiner Applikation zur├╝ck und wenn die time-to-live, also die G├╝ltigkeit, abgelaufen ist, l├Âscht Vault diesen User wieder auf der MySQL-Datenbank.

J├Ârg M├╝ller: Ah, okay. Und das wahrscheinlich auch nicht nur f├╝r Datenbanken, sondern auch f├╝r AWS-Accounts etc.

Daniel Bornkessel: Genau, es gibt ja ziemlich viele Systeme im Hintergrund. Man muss dann noch beachten, dass zum Beispiel Postgres selbst so etwas implementiert hat. Da kann ich direkt sagen, ich erzeuge jetzt einen User, der ist g├╝ltig bis morgen beispielsweise. Dann macht Vault das nicht, das L├Âschen, sondern dann verl├Ąsst es sich auf das Backend-System, das das macht.

J├Ârg M├╝ller: Okay, das hei├čt also, Vault kann dynamisch Passw├Ârter vergeben, die meine Applikationen dann eben nur kurzzeitig verwendet. Und wenn das jetzt irgendjemand klaut oder wenn ein Mitarbeiter geht, dem n├╝tzt das nicht allzu viel, wenn er dieses Passwort hat, weil er dann am Ende etwas mitnimmt, was wahrscheinlich morgen schon gar nicht mehr g├╝ltig ist.

Daniel Bornkessel: Genau. Je nachdem wie kurz man diese G├╝ltigkeit fasst. Und Vault unterst├╝tzt da halt relativ viele Systeme. Also es unterst├╝tzt Datenbanken, man kann das mit AWS machen, also wenn man AWS-Zugriff haben m├Âchte, kann man dann auch einfach einen Key generieren, der dann nur eine halbe Stunde g├╝ltig ist oder eine Stunde. Ich glaube, RabbitMQ wird zum Beispiel auch unterst├╝tzt, Kassandra-Datenbanken. Es werden relativ viele System unterst├╝tzt.

J├Ârg M├╝ller: Jetzt ist dieses Vault also sehr m├Ąchtig und kann mir quasi f├╝r alle m├Âglichen Sachen in meiner Infrastruktur Passw├Ârter generieren. Das ist dann nat├╝rlich auch wieder so ein zentraler Gefahrenpunkt. Wie stellt es denn sicher, dass nicht jeder, der jetzt auf Vault Zugriff hat, dann wiederum auf alle meine anderen Systeme Zugriff hat? Wie funktioniert das?

Daniel Bornkessel: Ja genau, klar. Es ist nicht so, dass das Vault irgendwo ein System ist und jeder kann einfach bei Vault etwas anfragen. Erst einmal noch ganz kurz, das hatte ich, glaube ich, nicht gesagt, Vault hat eine REST-API. Das hei├čt, ich kann da ganz normal mit mit REST anfragen. Und da kann nat├╝rlich nicht jeder anfragen. Das hei├čt, ich muss mich irgendwie bei Vault erst einmal authentifizieren, dass ich darauf zugreifen darf und dann, wenn ich mich authentifiziert habe, gibt es einen Autorisierung-Mechanismus, bei dem Vault feststellt, was ich lesen darf und was nicht.

J├Ârg M├╝ller: Aha, okay.

Daniel Bornkessel: Und das Sch├Âne an Vault ist, man muss sich das so vorstellen: In der Mitte ist dieses Vault, ich komme von links an, ich authentifiziere mich irgendwo und rechts kommen viele m├Âgliche Arten von Secrets heraus. Wenn ich jetzt mal bei der rechten Seite anfange: Wir hatten eben schon diese dynamischen Secrets, die dann neu erstellt werden. Ich kann dort nat├╝rlich auch statische Secrets speichern, die werden dann einfach verschl├╝sselt abgelegt. Wenn ich zum Beispiel einen API-Key von einem Fremdanbieter habe, steht es nicht in meiner Macht, den dynamisch zu erstellen. Das hei├čt, ich habe auch weiterhin wahrscheinlich einige Secrets, die statisch sind. Und auf der linken Seite von Vault melde ich mich irgendwie an. Da gibt es verschiedene Arten, wie ich mich anmelden kann, zum Beispiel als Benutzer kann ich einfach ein LDAP anh├Ąngen. Ich sage Vault, ich m├Âchte auhentifizieren mit der Methode LDAP, gebe Username und Passwort an Vault. Vault schickt das dann weiter zu dem LDAP-Server und bekommt dann zur├╝ck, das ist zum Beispiel User Daniel f├╝r die Gruppe Entwickler. Und dann gibt es innerhalb von Vault ein Mapping, das sagt, okay, Anmeldung ├╝ber LDAP, Gruppe Entwickler, User Daniel. Dann erstellt Vault ein Token und an dem Token h├Ąngen Berechtigungen dran, was ich lesen darf. Das hei├čt, man meldet sich immer an mit welchen Systemen und bekommt im Austausch, wenn man authentifiziert ist, ein Token und an dem Token h├Ąngen Berechtigung dran, was ich lesen darf.

J├Ârg M├╝ller: Okay, also wenn ich wenn ich der Super-Admin bin, dann kann ich mir quasi jedes Passwort generieren oder auch auslesen, wenn es ein statisches ist, und wenn ich zum Beispiel die Anwendung bin, die wirklich nur einen Datenbank-Passwort braucht, dann gibt es vielleicht f├╝r diese Anwendung eine Rolle Datenbank-Passwort-Owner oder wie auch immer.

Daniel Bornkessel: Genau. Und bei den Authentifizierungsmechanismen gibt es auch zahlreiche Arten, wie ich mich authentifizieren kann. Also das, was ich eben als Beispiel gesagt habe, ist jetzt halt ein Benutzer, der einen Usernamen und ein Passwort hat. Das w├Ąre jetzt f├╝r eine Applikation ziemlicher Quatsch, weil ich dann quasi das Datenbank-Username-Passwort-Paar durch ein Vault-Username-Passwort-Paar ersetze, dadurch h├Ątte nichts gewonnen. Vielleicht wie beim herk├Âmmlichen Passwort-Manager, dass ich statt zehn Passw├Ârtern nur noch eins haben muss, aber das Problem bleibt gleich, ob ich jetzt ein Passwort dahin geben muss oder zehn, ist dann auch nicht mehr der gro├če Unterschied. Das hei├čt, f├╝r Applikationen gibt es dann auch bestimmte Mechanismen, wie die sich authentifizieren k├Ânnen.

J├Ârg M├╝ller: Was w├Ąren das so f├╝r Mechanismen?

Daniel Bornkessel: Zum Beispiel in Kubernetes l├Ąuft jeder Container mit einem Service-Account. Also ein Service-Account, wer das nicht kennt, das ist so etwas wie ein technischer User. Das hei├čt, man kann keinen Container starten, der nicht mit einem Service-Account gestartet ist. Und jeder Service-Account hat wiederum einen Token, der benutzt werden kann, um mit der Kubernetes-API zu sprechen. Und dieser Token ist in jedem Container, der in Kubernetes l├Ąuft, unter einem bestimmten Pfad, ich glaube /var/kubernetes/secrets, gemountet. Und dann kann ich, wenn ich Vault nutzen m├Âchte, diesen Toten nehmen und kann zu Vault sagen: Ich m├Âchte mich authentifizieren mit der Methode Kubernetes und gebe Vault den Token. Vault nimmt den Token, fragt bei der Kubernetes-API an, ob das ein g├╝ltiger Token ist und in der Antwort ÔÇô und das ist wieder ├Ąhnlich zu LDAP ÔÇô steht in Kubernetes jetzt drin, das ist der Service-Account mit diesem Namen und der Container l├Ąuft in diesem Namespace. Und basierend auf der Kombi von Namen und Namenspace erzeugt Vault dann wieder ein Token, an dem bestimmte Berechtigungen h├Ąngen. F├╝r eine Applikation zum Beispiel, dass die Applikation das Datenbank-Passwort f├╝r folgende Datenbank lesen darf.

J├Ârg M├╝ller: Ah, okay.

Daniel Bornkessel: Das hei├čt, das Problem, wer das Secret hat, haben wir jetzt bis zu Kubernetes hin ausgelagert. Das hei├čt, wir m├╝ssen kein initiales Passwort mehr irgendwem geben, sondern Kubernetes legt ein Token in den Container hinein und wir verlassen uns auf die Sicherheitsmechanismen von Kubernetes.

J├Ârg M├╝ller: Okay. Vergleichbares gibt es dann vermutlich auch f├╝r AWS-IAM-Rollen oder ├ähnliches, oder?

Daniel Bornkessel: Genau, bei AWS, Azure und auch bei Google ist es so, dassÔÇŽ Virtuelle Maschinen haben immer so etwas wie Metainformationen, die kann man meistens mit Curl abfragen wie http://169.254.169.254.

J├Ârg M├╝ller: Super. Wir schreiben das in die Shownotes.

Daniel Bornkessel: Darin stehen Metainformationen. Bei AWS steht darin zum Beispiel, das ist die virtuelle Maschine mit folgender ID, die hat die folgenden Rollen, l├Ąuft in folgendem Datenzentrum. Es gibt da relativ viele Informationen. Und dieses Dokument, diese Metainformationen, gibt es auch einmal verschl├╝sselt. Eine verschl├╝sselte Form mit dem Private Key von AWS. Wenn man sich jetzt mit der Methode AWS authentifizieren m├Âchte, nimmt man dieses verschl├╝sselte Dokument und gibt es Vault. Und Vault wiederum kennt die Public Keys von AWS, die sind ja allgemein bekannt. Das hei├čt, Vault entschl├╝sselt das Dokument, wenn das funktioniert, wei├č es, okay, das wurde von Amazon signiert, und kann dann, basierend wiederum auf dem, was in diesem Dokument an Metainformationen drinsteht, Token erzeugen. Das hei├čt, da haben wir wieder so ein Mapping von: Wenn es eine EC2-Instanz ist mit folgender Rolle oder folgendem Profil, dann hat die folgende Rechte.

J├Ârg M├╝ller: Ah ja, okay. Das hei├čt also, wir haben jetzt relativ klar beleuchtet, wie man ├╝berhaupt an das Vault, an die Informationen in Vault herankommt, da gibt es also wahnsinnig viele Mechanismen. Du hast das vorhin die linke Seite genannt, wenn Vault dann sozusagen in der Mitte ist, und auf der rechten Seite haben wir dann ganz viele M├Âglichkeiten, die Passw├Ârter zu erzeugen. Jetzt gibt es ja h├Ąufig in so einem Umfeld, in dem man vielleicht Compliance-Regeln zu beachten hat etc., noch die Anforderung, dass man noch herausfindet, wer hat was gemacht, also Auditing. Wird das von Vault auch unterst├╝tzt oder wie ist das?

Daniel Bornkessel: Also es ist default-m├Ą├čig nicht eingeschaltet, man muss es einschalten. Und dann gibt es zwei oder drei Backends, in die man hinschreiben kann. Das ist einmal einfach ins Dateisystem oder ins Syslog, glaube ich, und ich wei├č nicht, ob es noch eins gibt, einen Unix-Socket, glaube ich. Und das ist so, wenn Vault das Audit-Log nicht schreiben kann, dann beantwortet Vault ├╝berhaupt keine Fragen. Das ist einfach so, wenn es eine Datei w├Ąre, k├Ânnte man sonst einfach als Angreifer die Festplatte so voll schreiben, dass Vault nichts mehr schreiben kann, macht irgendetwas und danach l├Âscht man die Dateien wieder, dann sieht man das im Log nicht. Das hei├čt erst einmal, wenn Audit eingeschaltet ist, funktioniert Vault nur, wenn er schreiben kann, ansonsten beantwortet Vault keine Fragen mehr. Das hei├čt, man muss wirklich aufpassen, dass das funktioniert. Und dann wird jede Operation, die ich mache, geloggt und zwar inklusive der Secrets, die ausgegeben werden, aber in einer gehashten Form. Das hei├čt, das Datenbank-Passwort wird ins Log geschrieben, zum Beispiel J├Ârg hat sich angemeldet mit LDAP und hat das Passwort f├╝r die Datenbank eins gelesen und das Passwort war Folgendes. Dann steht aber der Hashwert da, das hei├čt, ich will nat├╝rlich in den Logs nicht mein Datenbank-Passwort haben.

J├Ârg M├╝ller: Ja, das w├Ąre irgendwieÔÇŽ

Daniel Bornkessel: Genau. Das hei├čt auch wirklich gehasht, nicht encrypted. Und die Idee dahinter ist, wenn es jetzt wirklich einen Angriff gegeben hat und wir wissen, folgendes Passwort wurde benutzt, dann kann ich das Passwort mit demselben Hash-Mechanismus hashen und kann dann in den Audit-Logs danach suchen.

J├Ârg M├╝ller: Und dann kann ich quasi herausfinden, dieses Passwort, das wurde von Vault an den J├Ârg herausgegeben und ich h├Âre schon die Handschellen klicken bei mir. Das hei├čt, ich wei├č ganz genau, dass, was da geleakt ist, kann eigentlich nur auf diesem Weg geleakt worden sein. Okay, das ist nat├╝rlich dann auch ein interessanter Mechanismus, die Sicherheit dann noch einmal zu erh├Âhen. Spannend. Jetzt habe ich im Zusammenhang mit Vault mal irgendwo etwas ganz Spannendes gelesen: Diese Vault-Datenbank, du hast es gerade gesagt, wenn das Audit nicht funktioniert, dann antwortet sie nicht. Aber man kann sie ja auch so komplett zu machen, habe ich mal geh├Ârt. Also man kann sie locken, also die gesamte Datenbank dicht machen, sodass gar niemand darauf kommt, und kann sie dann auch quasi wieder freischalten und da benutzen sie irgendeinen ganz interessanten Mechanismus namens ShamirÔÇÖs Secret Sharing oder so. Was ist das? Ich fand das ganz faszinierend.

Daniel Bornkessel: Da muss man, glaube ich, kurz erkl├Ąren, wieÔÇŽ Also Vault speichert nat├╝rlich alle Daten verschl├╝sselt ab, encryptet at rest. Das hei├čt, es wird nie auf Festplatte irgendetwas geschrieben, was nicht verschl├╝sselt ist, und alle Daten sind mit einem Key verschl├╝sselt. Und dieser Key wiederum liegt auch auf der Festplatte, aber auch wiederum verschl├╝sselt. Also ich habe Daten, die sind verschl├╝sselt mit einem Key, der Key liegt neben den Daten und die sind wiederum mit einem anderen Schl├╝ssel verschl├╝sselt und das ist der sogenannte Master-Key. Und um den Master-Key zu entschl├╝sseln, da wird dieser Algorithmus benutzt, dieses ShamirÔÇÖs Secret Sharing. Das funkioniert folgenderma├čen: Wenn ich das entschl├╝sseln will, brauche ich halt mindestens ÔÇô ich sage mal, ich nehme einfach drei ÔÇô ich brauche mindestens drei andere Keys. Statt Key kann man auch Passwort sagen, wenn man gerne m├Âchte. Also ich brauche drei Keys, um dieses Master-Passwort zu entschl├╝sseln. Und die Keys k├Ânnen in beliebiger Reihenfolge angegeben werden. Das Interessante dabei ist jetzt, dass ich auch insgesamt f├╝nf Keys erzeugen lassen kann. Das hei├čt, ich habe f├╝nf Keys, um dem Master-Key zu entschl├╝sseln, ich brauche aber immer nur drei. Die k├Ânnen in beliebiger Reihenfolge angegeben werden. Die Idee dahinter ist, dass wenn der Vault zum Beispiel neu deployt wird ÔÇô das gilt auch f├╝r jede Instanz von Vault, wenn ich f├╝nf Instanzen von Vault deployt habe, weil ich eine hohe Verf├╝gbarkeit haben m├Âchte ÔÇô muss jede Instanz, wenn sie neu gestartet wird, einmal von Hand ungesealt werden, also entschl├╝sselt werden. Im Prinzip hei├čt das, den Master-Key entschl├╝sseln. Und daf├╝r brauche ich dann drei meiner Keys von den f├╝nf zum Beispiel. Drei von f├╝nf brauche ich, um den Key zu entschl├╝sseln. Dann wird der Master-Key entschl├╝sselt, der Master-Key entschl├╝sselt wiederum den anderen Key, mit dem die Daten verschl├╝sselt sind. Dann kann Vault erst einmal die Daten lesen. Das hei├čt, wenn ich Vault starte, kann ich mich auch authentifizieren, aber das n├╝tzt mir nichts. Ich muss erst einmal den Schl├╝ssel entschl├╝sseln, mit dem die Daten verschl├╝sselt sind. Das sind jetzt sehr viele Schl├╝ssel und Entschl├╝sselungs-Keys.

J├Ârg M├╝ller: Secrets over Secrets over Secrets, sehr sch├Ân.

Daniel Bornkessel: Genau. Und diese f├╝nf Keys, das ist auch noch interessant, die werden erzeugt, wenn ich den Vault initialisiere. Und das Problem ist jetzt nat├╝rlich, man kann sagen, wenn ich sie initialisiere, hat jemand alle f├╝nf Keys und dann sind doch alle f├╝nf Key alle auf einmal sichtbar gewesen. Das Interessante dabei ist, dass man da auch GPG-Keys benutzen kann.

J├Ârg M├╝ller: PGP ist?

Daniel Bornkessel: Pretty good privacy (Anm. eigentlich: GNU Privacy Guard)

J├Ârg M├╝ller: Genau.

Daniel Bornkessel: Ich wei├č nicht, ob ich jetzt hier zu technisch abnerde, aber was man machen kann, wenn man zum Beispiel f├╝nf Keys erzeugen m├Âchte, man kann sich von f├╝nf Kollegen f├╝nf Public GPG-Keys geben lassen, kann sagen, initialisiere Vault und ich bekomme diese Keys zum Entschl├╝sseln, die sind dann jeweils mit den Public Keys verschl├╝sselt, und kann die dann an die Entwickler zur├╝ckgeben. Das hei├čt, jeder bekommt seinen eigenen Key und bekommt den komplett verschl├╝sselt und kann den nur mit seinem Private Key entschl├╝sseln. Das hei├čt, ich kann Vault wirklich aufsetzen von Anfang an, ohne dass irgendeiner alleine den Vault entschl├╝sseln kann mit irgendeinem Master-Passwort.

J├Ârg M├╝ller: Okay, das ist nat├╝rlich durchaus wichtig, gerade auch f├╝r sp├Ąter. Interessant. Das Ganze klingt nat├╝rlich wahnsinnig komplex. Wie komme ich denn an so eine Instanz von Vault? Wie installiert ich das?

Daniel Bornkessel: Ja, das ist gut. Also wenn man Tutorials f├╝r Vault sucht, sieht das immer total super einfach aus; man kann auch relativ schnell mit Vault herumspielen. Es gibt, glaube ich, auch so eine interaktive Sache im Internet, da wird einfach eine Vault-Instanz hochgefahren. Das Problem bei den Tutorials ist immer nur, dass die im Developer-Modus starten. Das hei├čt, ich habe eine Instanz, ich brauche keine Zertifikate und das ist super einfach. Wenn ich das jetzt produktionsreif aufsetzen m├Âchte, muss man erst einmal mindestens mindestens drei Vault-Instanzen am Laufen haben, w├╝rde ich sagen, damit ich die Hoch-Verf├╝gbarkeit habe. Das hei├čt, falls dann eine eine Vault-Instanz umf├Ąllt, ├╝bernimmt die n├Ąchste automatisch. Das Setup ist immer: Eine ist aktiv und zwei sind passiv. Das hei├čt, es antwortet immer dieselbe Instanz, sobald sie nicht da ist, ├╝bernimmt die n├Ąchste Instanz. Das Problem ist, wenn ich die Development-Version aufsetze, ist das relativ einfach. Ich habe eine Instanz und wenn ich produktionsreif aufsetze, findet die Kommunikation nat├╝rlich verschl├╝sselt statt. Das hei├čt, ich muss auch mit Zertifikaten herumhantieren und muss Vault dann aufsetzen. Da ist erst einmal relativ wenig zu finden. Die Lernkurve f├╝r Vault ist auf ziemlich steil, finde ich. Denn dadurch, dass wir viele Arten haben, um uns authentifizieren zu k├Ânnen, und auf der anderen Seite viele verschiedene Arten von Secrets haben, die Vault ausspucken kann, gibt es sehr viele Systeme, mit denen man interagiert und alle haben ├Ąhnliche Begriffe, alle haben Keys und Tokens und times-to-live und alles ist irgendwie so ein bisschen anders. Und man jongliert im Kopf die ganze Zeit mit Keys und Zertifikaten herum. Ich fand es am Anfang sehr verwirrend. Das hei├čt, die Lernkurve f├╝r Vault ist, ehrlich gesagt, ziemlich steil am Anfang. Wenn man das dann einmal geknackt hat, dann geht das, aber es dauert erst. Das hei├čt, ich finde es relativ schwer zu lernen am Anfang.

J├Ârg M├╝ller: Das schreckt jetzt ja potentielle H├Ârer durchaus ab.

Daniel Bornkessel: Das schreckt vielleicht wirklich ab. Aber wir hatten das im Projekt auch mal, dass wir uns entschieden haben, Vault zu nutzen, obwohl es abschreckend war, weil es erst einmal aufw├Ąndig ist. Aber danach konnte jedes Problem mit regulatorischen Anforderungen, die man hat, dann wirklich durch Vault gel├Âst werden. Man hat dieses Auditing darin; man kann garantieren, dass Secrets ÔÇô die Anforderung war, glaube ich, ein halbes Jahr, aber unsere Secrets waren maximal einen Tag g├╝ltig. Man hat automatisch seine Zertifikate, weil das auch Privat Key Infrastructure ist. Darauf m├Âchte ich jetzt vielleicht nicht eingehen, ich m├Âchte nur kurz erw├Ąhnt, dass auf jeden Fall auch automatisierte Privat Key Infrastructure im Vault drin ist. Man hat diese ganzen regulatorischen Probleme dann gel├Âst. Zwei Wochen am Anfang schwirrt einem der Kopf und danach l├Âst Vault einfach super viele Probleme f├╝r einen automatisch, die man hat.

J├Ârg M├╝ller: Gibt denn es etwas, wo man sich, wenn man sich mit dem Thema n├Ąher besch├Ąftigen m├Âchte, ganz gut einarbeiten kann? Irgendwelche Hinweise, die du gehen kannst?

Daniel Bornkessel: Es gibt zahlreiche Tutorials und dann gibt es auf [vaultproject.io], wie gesagt, so ein interaktives Tutorial, da kann man sich schon einmal herantasten. Nur ein Problem ist, das ist vielleicht auch das Problem am Anfang, wenn man Vault nutzen m├Âchte und zwar zum Beispiel auch im Kubernetes- und AWS-Umfeld, dann ist das Problem, dass man das nicht wegmocken kann. Das hei├čt, wenn ich testen m├Âchte, funktioniert das in Kubernetes mit einer MySQL-Datenbank und einer Postgres-Datenbank und einer Cassandra-Datenbank auf AWS, dann muss ich diese ganzen Systeme wirklich haben. Ich kann da nicht herumspielen, sondern ich muss diese Systeme haben. Das hat es auch f├╝r mich auf jeden Fall am Anfang schwer gemacht, mal eben so einen Proof of Concept zu machen. Denn man braucht halt eine Datenbank, die dann l├Ąuft, man braucht einen AWS-Account, der dann irgendwie funktioniert, oder man braucht ein Kubernetes-Cluster. Das finde ich erst einmal relativ schwer. Und noch eine Sache, die man auch bedenken muss: Man muss jede Applikation anpassen, dass sie mit so etwas umgehen kann. Ich sage mal so, die normale Applikation kann jetzt nicht damit umgehen, dass ein Passwort von einer Datenbank nach einem Tag nicht mehr g├╝ltig ist. Also wir hatten da Spring-Applikationen, denen wir das erst beibringen mussten: Wenn das Passwort nicht g├╝ltig ist, dann lies noch einmal die Konfigurationsdatei, versuch es noch einmal, wahrscheinlich funktioniert es dann. Das hei├čt, man muss die Applikation auch so ein bisschen anpassen. Selbst wenn man das wegabstrahiert, indem auch die Secrets ├╝ber ganz normale Property-Dateien hineingegeben werden, dass Secrets verfallen oder dass Passw├Ârter nicht mehr g├╝ltig sind, das m├╝ssen die Applikation halt auch k├Ânnen, darauf sind wenige vorbereitet.

J├Ârg M├╝ller: Okay, klar. Also ich habe schon einen gewissen Aufwand, mich ├╝berhaupt erst einmal in das Vault und in das Setup von dem Vault einzuarbeiten, und ich muss meine Applikationen entsprechend darauf anpassen, dass sie damit arbeiten. Wenn ich das allerdings habe, dann habe ich am Ende ein ziemlich modernes Secrets-Management, womit ich jeden Auditor in irgendeiner Form gl├╝cklich mache, womit ich auch Sicherheitsanforderungen erf├╝lle, die, ich sage mal, ein sehr, sehr hohes Level haben, die eigentlich alle guten Verfahren und Dinge einsetzen, die man so haben m├Âchte an der Stelle. Okay, die Arbeit lohnt sich, aber man muss sich erst einmal doch schon tiefer damit besch├Ąftigen, h├Âre ich da heraus.

Daniel Bornkessel: Ja, also ich w├╝rde sagen, die Arbeit lohnt sich auf jeden Fall. Es sei denn, man hat wirklich quasi nichts zu verstecken. Wenn man jetzt wenig sensible Daten hat, ist es vielleicht overkill, aber es lohnt sich relativ fr├╝h. Und wenn man das einmal verstanden hat, dann kann man viele Probleme einfach damit erschlagen. Es ist eine gute Investition, aber halt eine ein bisschen anstrengende Investition am Anfang.

J├Ârg M├╝ller: Cool. Das war eine sehr spannende Einf├╝hrung. Tats├Ąchlich nur ein Anfang mit ein paar Momenten, einem auch Respekt davor zu verschaffen, was man da machen muss, aber ein sehr spannendes Thema. Vielen Dank, vielen Dank f├╝r das Gespr├Ąch Daniel und bis zum n├Ąchsten Mal.